Mihomo OpenVPN tls-auth 핸드셰이크 시간 초과는 어떻게 해결하나요?

Mihomo issue #2992에는 매우 제한적인 조합이 기록되어 있습니다. OpenVPN 아웃바운드에서 tls-auth를 사용하고 auth를 SHA512로 설정한 경우입니다.

설정은 로드되고 DNS 조회와 PROCESS-NAME 규칙도 일치하지만 제어 채널은 4회 재전송 후 시간 초과되며, 클라이언트 로그에는 make OpenVPN handshake: read hard reset response after 4 retransmits: context deadline exceeded가 나타납니다.

보고된 환경은 Windows 11과 Mihomo v1.19.29입니다. HTTP 요청은 502를 반환할 수 있고 HTTPS는 프록시가 CONNECT를 수락한 뒤에도 TLS 데이터를 더 이상 받지 못했습니다. 같은 Mihomo 환경에서 tls-auth를 사용하지 않는 다른 OpenVPN 설정은 작동했습니다.

이 대조 결과는 문제를 DNS, 규칙 또는 전체 프록시 진입점 탓으로 돌리기보다 tls-auth와 auth를 계속 확인해야 함을 뒷받침합니다.

PR #3189에서 구버전 구현이 tls-auth 제어 패킷의 HMAC을 SHA1로 고정했음을 확인했습니다. 서버가 SHA256, SHA384, SHA512 등 다른 auth 다이제스트로 검증하면 태그 길이가 달라 첫 번째 제어 패킷을 폐기합니다.

서버 로그를 확인할 권한이 있다면 TLS Error: cannot locate HMAC in incoming packet이 보일 수 있습니다. SHA1을 사용하는 서버는 이 특정 결함의 영향을 받지 않으며, 일반 TLS, 인증서, 포트 또는 네트워크 오류도 이 글의 결론에 포함되지 않습니다.

문제 해결 전용 설정 사본을 먼저 만들고 현재 실행 중인 원본 파일을 직접 수정하지 마세요. 프록시 항목이 실제로 type: openvpn인지 확인하고 auth, tls-auth 존재 여부, key-direction, proto, 포트, 서버 도메인을 기록합니다.

공식 문서에 따르면 tls-auth는 tls-crypt 및 tls-crypt-v2와 함께 사용할 수 없으며, tls-auth 사용 시 key-direction은 0 또는 1을 지원합니다. auth는 MD5, SHA1, SHA256, SHA384, SHA512를 지원하고 기본값은 SHA256입니다.

tls-auth 정적 키, username, password, 클라이언트 개인 키, 인증서 전체 내용 또는 실제 서버 주소를 공개 이슈에 올리지 마세요. 공개 자료에는 필드 이름, 다이제스트 알고리즘, 가린 주소, 오류 시각, 최초 관련 로그만 남기고 원본 설정은 비공개 위치에 보관해야 합니다.

테스트를 위해 tls-auth를 삭제하거나 key-direction을 추측하거나 서버의 auth를 SHA1로 낮추지 마세요. 그렇게 하면 인증 경계가 달라져 업그레이드가 원래 문제를 해결했는지 입증할 수 없고 클라이언트 설정과 서버 설정이 일치하지 않을 수도 있습니다.

핸드셰이크 오류는 OpenVPN 제어 채널이 완료되지 않았다는 뜻일 뿐 원인을 단독으로 입증하지는 못합니다. 먼저 서버 도메인이 조회되는지, 대상 UDP 또는 TCP 포트에 접근할 수 있는지, 요청이 실제로 이 OpenVPN 아웃바운드와 일치하는지 확인하고 정상 작동이 확인된 아웃바운드 하나를 비교 대상으로 남겨 두세요.

로그에서 조회, 다이얼, 인증서 읽기 또는 설정 검증 단계에 더 이른 오류가 이미 나타났다면 그 오류부터 처리하세요. DNS와 규칙이 모두 성공하고 연결이 OpenVPN 핸드셰이크에 진입한 뒤 4회의 hard reset 재전송 시간 초과가 발생해야 issue #2992의 진단 순서와 일치합니다.

업그레이드 전후에 동일한 서버, 동일한 민감 정보 제거 설정, 동일한 HTTPS 대상을 사용해야 합니다. 테스트 중에 노드, 프로토콜, 포트, 인증서, auth를 동시에 바꾸면 연결이 복구되더라도 결과가 v1.19.31 때문이라고 판단할 수 없습니다.

v1.19.31은 PR #3189 수정이 포함된 안정 버전입니다. 업그레이드하기 전에 현재 바이너리의 전체 버전 출력, 운영체제, CPU 아키텍처, 이를 관리하는 클라이언트 또는 서비스 관리자, 현재 코어 파일의 실제 위치를 기록하세요.

설정, 인증서 참조 파일, 기존 코어 바이너리를 모두 백업하되 백업은 비공개로 유지하세요. GUI 클라이언트를 사용한다면 코어 업데이트 메뉴와 자동 업데이트 정책도 기록해야 합니다. 애플리케이션 버전과 실제 실행 중인 Mihomo 버전이 항상 같은 것은 아닙니다.

원격 장치, 라우터 또는 무인 호스트에서는 먼저 해당 OpenVPN 아웃바운드를 통하지 않는 관리 경로가 있는지 확인해야 합니다. 예비 접속 경로가 없다면 유일한 연결 창에서 코어를 바로 교체하지 마세요.

Mihomo v1.19.31은 2026년 9월 14일에 출시되었으며, Release에는 OpenVPN tls-auth의 HMAC 다이제스트가 SHA1로 고정되지 않고 auth를 따르도록 한 커밋 6d179a1c가 명시되어 있습니다.

최소 목표는 실제로 v1.19.31을 실행하는 것입니다. 후속 안정 버전을 사용한다면 6d179a1c 수정이 포함되었는지 확인해야 합니다. GUI 클라이언트 화면이나 구독만 업데이트하는 것으로는 코어 업그레이드를 대신할 수 없습니다.

Mihomo를 직접 실행한다면 MetaCubeX/mihomo 공식 v1.19.31 Release에서 운영체제, CPU 아키텍처, 빌드 변형과 일치하는 파일을 선택하고 Release 페이지에 표시된 해당 파일의 SHA256을 확인하세요.

Clash Verge Rev, OpenClash 또는 다른 프런트엔드가 코어를 관리한다면 해당 프로젝트의 기존 공식 코어 업데이트 메뉴를 사용하고 업데이트 후 실제 실행 버전을 다시 확인합니다.

기존 코어를 중지한 뒤 파일을 교체하고 기존 권한, 시작 매개변수, 서비스 설정을 유지하세요. 버전이 다른 개별 라이브러리 파일을 섞지 말고 검색 광고, 웹 드라이브 또는 출처를 알 수 없는 미러에서 같은 이름의 코어를 받지 마세요.

업그레이드 후 중요한 것은 화면에 성공이 표시되는지가 아니라 동일한 서버, 동일한 Profile, 동일한 auth, 동일한 tls-auth로 제어 채널 핸드셰이크를 완료할 수 있는지입니다. 먼저 정책 그룹 선택을 고정해 요청 하나가 해당 OpenVPN 아웃바운드와 명확히 일치하게 한 다음 업그레이드 전 사용했던 동일한 HTTPS 대상에 접속하세요.

로그에 read hard reset response after 4 retransmits가 더 이상 나타나지 않는지 확인하고 요청이 실제 HTTPS 응답을 받는지 확인합니다. 코어 업그레이드가 다른 경로를 손상하지 않았는지 일반 아웃바운드도 하나 검증해야 합니다. UDP가 필요하면 실제 UDP 서비스를 별도로 한 번 검증하고 지연 시간 수치로 대신하지 마세요.

tls-auth를 끄거나 SHA1로 변경하거나 다른 서버로 바꾼 뒤 성공한 결과를 수정 검증으로 간주하지 마세요. 그런 변경은 다른 설정이 작동한다는 사실만 보여 줄 뿐 v1.19.31이 원래 조합을 수정했음을 입증하지 못합니다.

실제 실행 버전이 이미 v1.19.31이거나 해당 수정이 포함되었다고 확인된 후속 안정 버전인데도 핸드셰이크가 실패한다면 모든 오류를 구버전의 SHA1 고정 탓으로 계속 돌리지 마세요. 오류가 여전히 같은지, 요청이 여전히 동일한 아웃바운드와 일치하는지, 서버에도 HMAC, 인증서, 키 방향 또는 인증 실패가 기록되는지 먼저 비교합니다.

ca, cert, key, tls-auth, key-direction, auth, proto, 포트, 시스템 시간을 다시 확인하고 tls-auth가 tls-crypt 또는 tls-crypt-v2와 함께 사용되지 않았는지 확인합니다. 서버 설정이나 키가 최근 변경되었다면 오래된 클라이언트 파일로 추측하지 말고 현재 서버 설정을 기준으로 삼으세요.

원래 오류가 사라지고 다른 명확한 오류로 바뀐 경우에만 새로 나타난 첫 오류에 따라 계속 점검합니다. 다이제스트, 키 방향, 인증서를 반복해서 바꾸면 버전 비교가 무의미해지고 서버의 실패 방지 기능이 작동할 수도 있습니다.

v1.19.31이 현재 장치에서 다른 시작 또는 호환성 문제를 일으켰다면 새 코어를 중지하고 업그레이드 전에 보관한 기존 바이너리 전체와 원래 설정을 복원한 뒤 동일한 관리 경로에서 시작할 수 있습니다. 되돌린 후에는 먼저 버전과 설정 로드를 확인하고 일반 아웃바운드와 장치 관리 경로를 검증하세요.

기존 코어로 되돌리면 이 글에서 설명한 SHA1이 아닌 tls-auth 핸드셰이크 문제도 다시 생깁니다. 따라서 이 OpenVPN Profile의 장기적인 해결책은 아닙니다. 서비스를 즉시 복구해야 한다면 이미 검증된 다른 노드나 프로토콜로 전환하거나 해당 Profile을 일시적으로 비활성화하세요. tls-auth를 삭제하거나 key-direction을 추측하거나 구버전 클라이언트와 맞추기 위해 서버 auth를 낮추지 마세요.

나중에 다시 업그레이드할 때도 동일한 민감 정보 제거 기준 상태, 공식 파일, 실제 요청을 사용하세요. 업스트림에 제보할 때는 시스템, 아키텍처, 전체 버전 출력, 필드 조합, 업그레이드 전후의 첫 관련 로그, 최소 재현 절차를 포함하되 정적 키, 계정, 개인 키 또는 실제 서버 주소는 절대 포함하지 마세요.