VPN은 집에서 연결되지만 호텔 Wi-Fi에서는 시간 초과된다

노트북이 집 Wi-Fi에 접속하고, 클라이언트는 세 초 만에 연결되며, 같은 프로필이 한 시간 뒤 호텔에서는 실패한다. 그 사이에 갱신된 것은 없다. 고객을 앞에 두고 이 일을 훑는 것은 주로 어떤 오류가 어느 단계에 속하는지 아는 일이다. 쓸모 있는 정보는 클라이언트가 출력하는 코드에 있고, 실패했다는 사실에 있지 않다. 아래 네 단계를 차례로 실행하면 이름, 패킷, 포트, 정책 중 무엇이 당신을 거부했는지 알게 된다.

오류 코드를 판정이 아니라 단계로 읽으세요

터널이 존재하기 전에 클라이언트는 세 개의 별개 이정표에 도달한다. 서버 이름을 해석하고, 네트워크의 무언가로부터 응답을 받고, 보안 연관을 협상한다. 각 이정표에는 고유한 실패 메시지가 있으며, 특히 Windows는 어느 단계에 속하는지 알면 다양한 코드를 아낌없이 내놓는다.

그 코드 중 둘은 네트워크에 잘못이 없다는 뜻이다. 789는 패킷이 흐르고 있었고 양 끝이 암호화에 합의하지 못했다는 뜻이며, 이는 집에서 고칠 수 있는 설정 문제다. 868은 어떤 패킷도 나갈 필요가 없었다는 뜻이므로, 이름이 해석되기 전까지 터널 설계는 무관하다. 코드를 올바른 단계로 분류하는 것은 어떤 캡처보다 시간을 아낀다. 다음 세 단계 중 무엇을 건너뛸지 알려주기 때문이다.

클라이언트가 Windows가 아니면 적절히 조심하라. 서드파티 클라이언트는 이 대부분을 "연결 실패"로 뭉뚱그리므로, 다음 두 단계는 메시지에 전혀 의존하지 않는다.

터널을 탓하기 전에 이름을 확인하세요

호텔과 공항 네트워크는 DNS를 끊임없이 가로채며, 포털 주소로 응답하는 확인자는 죽은 서버와 똑같아 보이는 실패를 만든다. 로컬 확인자가 말하는 것과 공용 확인자가 말하는 것을 비교하라:

Resolve-DnsName vpn.example.net -Type A
nslookup vpn.example.net 1.1.1.1
ipconfig /all | findstr /i "DNS Servers"

두 응답이 다르면 당신은 유도되고 있는 것이며, 그것이 해결될 때까지 나머지 진단은 허사다. 특히 포털 주소는 TCP 연결을 기꺼이 받아들인 뒤 멈추므로, 브라우저로 시험할 때 방화벽 차단처럼 보일 수 있다.

이제 도달하려는 주소가 실제로 쓰이는 주소인지 확인하라. 일부 클라이언트는 이전 해석 결과를 프로필 수명 내내 캐시하므로, DNS 변경 후 재연결도 옛 주소로 간다. 다시 시험하기 전에 클라이언트를 완전히 닫아라. 같은 창에서 연결 끊기와 연결을 누르지 말고.

어떤 바깥 패킷이 사라지는지 알아내세요

터널에는 당신과 서버 사이 경로에 전적으로 속하는 바깥 흐름이 있고, 중간 장비가 분류하고 버리는 것이 바로 그 흐름이다. 클라이언트에서 그것을 캡처한 뒤, 동작하는 네트워크와 실패하는 네트워크를 비교하라. Windows에서는 내장 캡처로 첫눈에 보기에 충분하다:

pktmon filter remove
pktmon filter add -p 500 -t UDP
pktmon start --capture --pkt-size 128
pktmon stop
pktmon etl2txt PktMon.etl

보고 싶은 것은 패킷이 애초에 나가는지, 그리고 무언가 돌아오는지다. 나가기만 하고 돌아오는 것이 없으면 경로나 먼 쪽이 버리는 것이다. 아예 나가지 않으면 클라이언트가 전송까지 이르지 못한 것이며, 이는 이름 해석이나 로컬 방화벽 정책을 가리킨다.

같은 시험을 휴대폰 핫스팟에서 반복하라. 이것이 당신에게 가능한 가장 정보량이 많은 비교다. 노트북, 클라이언트, 자격 증명을 그대로 둔 채 호텔의 모든 장비를 경로에서 제거하기 때문이다. 핫스팟에서 터널이 올라오면 서버를 보는 것을 그만두라. 거기서도 실패하면 네트워크가 일으킨 적 없는 클라이언트나 계정 문제가 있다.

전송 방식을 하나 바꿔 다시 시험하세요

바깥 흐름이 버려진다는 것을 알았다면, 실무적인 질문은 네트워크가 어떤 흐름을 허용하느냐다. 대부분의 제한 네트워크는 나가는 TCP 443을 허용한다. 그렇지 않으면 동작할 수 없기 때문이며, 그래서 리스너를 그리로 옮기는 것이 흔한 답이고,OpenVPN에서는 서버가 바뀔 때까지 클라이언트 측 스위치다:

openvpn --config corp.ovpn --proto tcp-client --remote vpn.example.net 443 --verb 4

IPsec 클라이언트에는 자체 설정 패널에 대응하는 스위치가 있으며, 보통 TCP 상의 IPsec 또는 NAT 통과로 설명된다. 그것을 바꾸는 것도 진단이다. TCP로 터널이 올라오고 UDP로 죽는다면 네트워크가 UDP를 필터링한다는 것을 증명한 것이고, 그 사이트를 방문할 때마다 필요한 설정도 찾은 것이다.

첫 시도에 라우터 기능을 끄고 싶은 유혹을 물리쳐라. 호텔 네트워크에서 상태 저장 검사나 플러드 보호를 끄는 것은 어차피 당신에게 허용되지 않으며, 자기 장비에서는 노트북 한 대를 위해 실제 보호를 맞바꾸는 일이다. 어떤 설정이 결과를 바꿨는지 기록한 뒤 되돌리고, 네트워크가 이미 허용하는 전송 방식을 찾아라.

두 번째 네트워크에서 같은 프로필을 검증하세요

티켓을 닫기 전에 그 변경이 건물을 떠난 뒤에도 살아남았음을 증명하라. 원래 네트워크에서 원래 설정으로 다시 연결하고, 처음 서른 초를 캡처하고, 클라이언트가 핫스팟에서 도달한 것과 같은 상태에 도달하는지 확인하라:

pktmon filter add -p 443 -t TCP
pktmon start --capture
Get-VpnConnection -Name "Corp" | Select-Object ConnectionStatus, TunnelType, ServerAddress

마지막 명령이 드러내는 구분은 남겨 둘 가치가 있다. 프로필은 연결된 터널을 보고하면서도 그 안의 라우팅이 틀릴 수 있고, 그것은 "VPN은 켜져 있지만 아무것도 동작하지 않는다"는 다른 글을 만든다. 편집 후 터널 유형이 바뀌었다면, 그 프로필은 당신이 시험한 것이 아니다.

그런 다음 발견한 내용을 다음 사람이 볼 곳에 적어라. "이 사이트에서 회사 프로필은 TCP 443이 필요하고, UDP 500은 호텔이 필터링한다"는 동료가 행동할 수 있는 문장이다. "호텔에서 VPN이 불안정하다"는 그렇지 않으며, 다음 달에 같은 한 시간이 다시 쓰인다는 것을 보장한다.