OpenVPN TLS 핸드셰이크 실패: 어느 갈래에 있습니까?

TLS 핸드셰이크가 실패했다고 알리는 줄은 이야기의 끝이지 시작이 아닙니다. 중요한 것은 바로 그 앞의 이벤트이며, 그 이벤트가 네 가지 전혀 다른 결함 중 어느 것인지 알려 줍니다. 시간 초과, 제어 채널 불일치, 인증서 거부, 협상 이후의 실패는 모두 같은 제목을 만듭니다. 증거를 보고 갈래를 고르면 해결은 더 이상 추측이 아닙니다.

실패 직전의 마지막 이벤트를 읽으십시오

마지막 줄을 읽는 대신 위로 스크롤하십시오. 연결이 끊기기 전의 이벤트는 보통 단계를 알려 줍니다: 응답이 전혀 없음, 제어 패킷 교환 중 오류, 검증 결과, 또는 협상이 성공한 뒤 이어지는 인증 결과입니다. 각각은 서로 다른 담당자에게 속합니다. 그 한 줄이 아래 어느 절이 적용되는지를 결정합니다.

오류 텍스트를 클라이언트 버전, 엔드포인트, 전송 방식과 함께 저장하십시오. 키, 비밀번호, 편집하지 않은 프로필은 공개적으로 붙여 넣는 어떤 것에도 넣지 마십시오.

정확한 첫 오류는 긴 로그 발췌보다 가치가 있습니다. 단계를 알려 주고, 단계가 담당자를 알려 줍니다.

갈래 하나: 아무것도 돌아오지 않음

클라이언트가 첫 패킷을 보냈는데 쓸 만한 응답을 받지 못했다면 문제는 경로나 수신 측에 있습니다. 프로필이 운영자가 실제로 제공하는 옵션과 맞는지 확인하십시오: 주소, 포트, UDP 또는 TCP입니다. 그다음 이 네트워크에서 엔드포인트에 아예 도달할 수 있는지 확인하십시오. 계속하기 전에 두 확인 중 어느 것이 실패했는지 적어 두십시오.

같은 호스트 이름의 페이지를 불러오는 브라우저는 웹 서비스가 응답했다는 것만 증명합니다. TCP 연결이 수락되었다 해도 OpenVPN 이 협상을 마쳤는지는 아무것도 말해 주지 않습니다.

프로필이 다른 신뢰할 수 있는 네트워크에서 작동한다면 그 비교를 남겨 두십시오. 제한이 경로나 중간자에 있다는 것을 좁혀 줍니다.

갈래 둘: 제어 채널이 맞지 않음

교환이 시작되었다가 멈추면 제어 채널 설정이 첫 번째 용의자입니다. tls-auth 과 tls-crypt 은 배포와 맞아야 하며, 다른 서버의 자료로는 쓸 만한 교환이 되지 않습니다. 이 실패는 어떤 계정 로그인보다도 먼저 일어납니다. 오래된 서버에서 복사한 프로필이 흔한 원인입니다.

비밀번호 재설정은 그 설정을 대체하지 않으며, 다른 서비스의 키를 빌리는 것은 호환성 해결이 아닙니다. 운영자의 검증된 경로로 프로필을 받고 그것이 기대하는 클라이언트 버전을 적어 두십시오.

무엇이 버티는지 보려고 오래된 알고리즘을 잔뜩 켜는 대신 구체적인 협상 오류를 기록하십시오. 포착한 오류 텍스트가 운영자가 자기 쪽을 확인하게 해 줍니다.

갈래 셋: 인증서가 거부됨

명시적인 검증 실패는 마음에 들지 않는 인증서를 지목합니다. 먼저 기기 시계를 확인하고, 그다음 어느 객체가 실패했는지 읽으십시오: 서버 인증서, 클라이언트 인증서, 또는 체인의 발급자입니다. 만료, 신뢰할 수 없는 발급자, 예상치 못한 신원은 서로 다른 세 가지 메시지입니다.

수정된 자료를 구하는 동안 검증은 켜 둔 채로 두십시오. 관계없는 인증서를 받아들이면 오류는 사라지지만 의도한 서버에 도달했다는 증거는 되지 않습니다.

실패가 네트워크를 따르는지 프로필을 따르는지 적어 두십시오. 어디서나 나타나는 인증서 오류는 경로 문제가 아닙니다.

갈래 넷: 협상이 끝났는데 다른 것이 실패함

신원 교환이 성공한 뒤 남은 실패는 인증이나 라우팅에 속합니다. 계정의 명시적 거부는 인증 문제이고, 도달할 수 없는 사이트가 있는 연결된 터널은 라우팅 또는 DNS 문제입니다. 그 시점에서 TLS 옵션을 계속 바꾸면 이미 작동하던 단계를 손상시킵니다.

문제를 보고할 때 모든 네트워크가 실패하는지, 다른 프로필이 작동하는지, 서버가 시도를 기록했는지 말하십시오. 서버 측의 침묵과 서버의 거부는 서로 다른 경계에 있습니다.