VPN 연결 시간 초과: DNS, 전송, 협상 또는 로그인

“연결 시간이 초과되었습니다”는 VPN 클라이언트가 출력할 수 있는 가장 모호한 오류입니다. 한 작업이 기한을 놓쳤다는 뜻이며, 이름 확인부터 로그인 응답까지 모든 단계에 기한이 있습니다. 마지막 메시지만 보여 주는 클라이언트는 단계들을 똑같아 보이게 하므로, 사람들은 시간 제한을 늘리고 포트를 바꾸고 프로필을 다시 설치합니다. 그 순서대로, 아무것도 배우지 않은 채로요. 단계를 비교하는 편이 더 빠릅니다. 각 단계는 다른 지점에서 실패하고, 각 실패는 다른 종류의 증거를 남깁니다.

네 단계, 네 가지 다른 실패

클라이언트가 감춰도 순서는 정해져 있습니다. 이름을 확인하고, 그 결과 주소로 전송을 수립하고, 프로토콜이 매개변수와 키를 협상하고, 계정이 인증되어야 합니다. OpenVPN의 연결 문제 해결 안내서 도 자사 클라이언트에서 같은 순서를 따르며, 다른 클라이언트도 이를 가깝게 따릅니다. 두 번째 단계의 시간 초과와 네 번째 단계의 시간 초과는 화면의 단어 말고는 공통점이 없습니다.

로그에서는 오류 직전 줄이 아니라 진행을 보여 주는 마지막 줄을 읽으십시오. 대부분의 클라이언트는 확인된 주소, 수립된 소켓, 시작된 핸드셰이크 또는 인증 요청 같은 것을 출력하며, 그 줄 다음 단계가 시간 초과된 단계입니다.

이름 확인은 무엇이든 접촉하기 전에 실패한다

엔드포인트가 끝내 확인되지 않으면 클라이언트는 연결할 대상이 없고 전송 작업도 일어나지 않았습니다. 그 실패는 보통 완전한 시간 초과가 아니라 즉시 일어나며, 나머지와 구분하는 가장 값싼 방법입니다. 이름을 시스템 리졸버와 두 번째 리졸버로 시험하고, 서버가 죽었다고 결론 내리기 전에 두 응답을 비교하십시오.

포럼 게시물에서 복사한 오래된 주소는 서버 문제처럼 보이는 시간 초과의 흔한 원인입니다. 그 주소는 이제 다른 것 또는 아무것에도 속하지 않기 때문입니다. 예전에 동작하던 주소를 대신 넣지 말고 운영자의 현재 프로필을 사용하십시오. ping 응답이 없는 것은 어느 쪽의 증거도 아닙니다. 많은 엔드포인트가 ICMP를 버리면서도 아주 잘 서비스합니다.

전송 설정은 오지 않을 패킷을 기다린다

DNS가 정상인데도 클라이언트가 시간 제한을 다 써 버리면 전송 계층이 의심 대상입니다. TCP에서는 포트를 직접 시험할 수 있습니다.Test-NetConnection Windows에서는 nc -vz Linux에서는 무엇인가 연결을 받아 주는지 알려 주며, ping보다 유용합니다. UDP에서는 같은 방식으로 시험할 수 없습니다. 그 계층에는 완료할 핸드셰이크가 없고, 이 비대칭이 많은 잘못된 결론을 낳습니다.

TCP 시험이 증명하는 것은 제한적입니다. 443 포트를 받아 주는 서비스가 VPN 리스너라고 단정할 수 없고, UDP만 쓰는 엔드포인트에는 무엇인가를 받을 TCP 포트가 없습니다. 프로필을 UDP에서 TCP로 다시 쓰는 것은 반대편에 리스너를 만들지 않습니다. 클라이언트가 기다리는 대상만 바뀝니다. 네트워크가 프로토콜을 걸러 내면 그 변경은 같은 단계에서 다른 시간 초과를 만들어 냅니다.

캡티브 포털은 이 단계에서 별도의 확인이 필요합니다. 포털이 기기를 허용하기 전까지 외부로 나가는 트래픽은 포털로 가고 터널 시도는 그저 매달려 있습니다. 먼저 브라우저에서 포털을 완료한 뒤 다시 시도하고, 포털이 보류 중인 동안 프로필을 바꾸지 마십시오.

협상과 로그인은 서버가 응답했다는 뜻

터널이 서버에 도달하면 클라이언트는 핸드셰이크를 시작하고 오류의 성격이 달라집니다. 여기서 멈추는 것은 도달 가능성이 아니라 호환성 문제입니다. 프로토콜 버전 불일치, 상대가 받아들이지 않는 암호나 데이터 채널 설정, 또는 서버가 제공하지 않는 기능을 기대하는 프로필입니다.OpenVPN 은 주요 버전 사이에서 협상 기본값을 여러 번 옮겼기 때문에, 한 세대를 위해 작성된 프로필이 서버에 도달하고도 올라오지 못할 수 있습니다.

인증은 마지막 단계이며 가장 잘못 읽기 쉽습니다.명시적인 거부는 응답입니다. 경로가 동작하고 문제는 신원, 인증서 또는 계정 상태에 있다는 뜻입니다. 브라우저 기반 싱글 사인온 흐름은 세 번째 경우입니다. 클라이언트는 아직 하지 않은 동작이나 실행할 수 없는 브라우저를 기다리고 있으며, 그 단계를 마치기 전에는 아무것도 오지 않습니다.

재시도를 바꾸기 전에 증거를 비교하라

기기와 프로필을 고정하고 네트워크부터 시작해 한 번에 하나씩 바꾸십시오. 같은 프로필이 휴대폰 핫스폿에서는 연결되고 호텔 Wi-Fi에서 시간 초과된다면 변수는 서버가 아니라 경로입니다. 어디서나 실패하면 변수는 프로필이나 엔드포인트입니다. 하루 중 특정 시간에만 실패하면 타임스탬프를 기록하고, 부하에 대해 무엇이든 가정하기 전에 서버 쪽 이벤트와 비교하십시오.

직접 관리하는 서비스라면 결정적인 비교는 시도가 애초에 도착하는지입니다. 리스너에 도달한 뒤 멈추는 연결은 협상 단계에 속합니다. 리스너의 시야에 결코 나타나지 않는 것은 전송이나 확인 문제이며, 재시도 조정으로는 움직이지 않습니다. 서버 로그는 거부된 로그인과 조용한 끊김도 구분해 주며, 이는 신원 수정과 방화벽 수정의 차이입니다.

클라이언트 버전, 프로필 이름, 시간대를 포함한 시도 시각, 그리고 마지막 연결 끊김 줄 대신 첫 번째 쓸모 있는 오류를 기록하십시오. 발췌를 공유하기 전에 키와 자격 증명이 담긴 자료를 제거하십시오. 그다음 의미 있는 수정을 하나 하고 다시 시도하십시오. 더 긴 기한은 문서화된 느린 작업에만 도움이 되고, 잘못된 주소나 막힌 포트에는 아무 소용이 없습니다.