호텔 Wi-Fi: VPN이 서버에 닿기도 전에 실패한다

VPN 클라이언트가 돌다가 서버에 닿을 수 없다고 보고하고, 모두 호텔이 VPN을 차단한다고 결론짓습니다. 보통 그렇게 극적인 일은 일어나지 않았고, 네트워크가 아직 당신을 내보내지 않은 것입니다. 캡티브 포털은 로그인할 때까지 모든 연결을 붙잡고, 로그인 페이지가 패킷을 가로채는 동안 터널은 완성될 수 없습니다. 터널을 탓하기 전에 로그인을 끝내세요.

신화: 호텔이 VPN을 차단한다

대부분의 호텔 네트워크는 터널을 특별히 필터링하지 않습니다. 투숙객이 인증할 때까지 웹 트래픽을 가로채고, 기기 수를 제한하거나 세션을 만료시키거나 속도를 줄이기도 합니다. 각각은 VPN 클라이언트 안에서 차단처럼 보이는 장애를 만듭니다.

포털이 승인되지 않은 동안 반드시 실패하는 유일한 애플리케이션이므로 여기서 터널은 나쁜 진단 도구입니다. 일반 웹 접속이 더 나은 지표이며, 로그인 페이지 자체를 보여줄 수 있습니다.

킬 스위치나 항상 켜짐 모드의 클라이언트는 포털 로드를 거부하고 사용자는 설정이 아니라 네트워크가 고장 났다고 결론짓기 때문에 이 순서가 중요한 이유는 또 있습니다. 두 사실은 동시에 참이고, 호텔에서 바꿀 수 있는 것은 하나뿐입니다. 클라이언트 자체 제어로 보호를 끄고 로그인한 뒤 다시 켜세요. 그 밖의 방법은 실제 순서를 감추는 우회입니다.

먼저 포털을 끝내고, 그다음 일반 HTTPS를 시험하세요

직원에게 공식 네트워크 이름과 로그인 방법을 물으세요. 그럴듯한 SSID는 소유의 증거가 아니며, 비슷한 이름의 두 번째 네트워크는 공공장소에서 흔한 수법입니다. 운영체제 자체 로그인 안내가 있으면 그것을, 없으면 호텔의 안내 페이지를 사용하세요.

curl -sS -o /dev/null -w '%{http_code} %{redirect_url}\n' http://captive.apple.com/hotspot-detect.html
curl -sS -o /dev/null -w '%{http_code}\n' https://www.example.com/

첫 요청은 잘 알려진 캡티브 포털 탐지 엔드포인트를 평문 HTTP로 묻고, 리디렉션이나 예상 밖의 본문이면 아직 포털 뒤에 있다는 뜻입니다. 두 번째는 일반 HTTPS 사이트를 시험합니다. 첫 번째가 가로채기를 보이고 두 번째가 실패하면 로그인이 미완료이며 VPN과는 무관합니다.

개인 기기에서는 포털이 로드되도록 클라이언트의 지원되는 제어로 킬 스위치나 항상 켜짐 VPN을 꺼야 할 수 있습니다. 그동안 민감한 앱을 닫고 곧바로 보호를 다시 켜세요. 관리 기기에서는 스스로 정책을 제거하지 말고 관리자가 승인한 절차를 따르세요.

온라인이 되기 위해 인증서 경고를 절대 우회하지 말고, 알 수 없는 인증서나 보조 앱을 설치하지 마세요. 포털이 예상 밖의 것을 요구하면 직원에게, 기기가 회사 소유라면 관리자에게 확인하세요.

원래 프로필과 그 오류를 남기세요

일반 접속이 되면 원래 프로필을 연결하고 정확한 오류를 기록하세요. 인증 거부는 계정 문제, 협상 중 시간 초과는 경로 문제, 연결되지만 아무것도 나르지 않는 터널은 라우팅이나 정책 문제입니다.

이 셋은 다음 단계가 다르고, 오류 스크린샷은 설명보다 값집니다. 호텔 세션 한도가 한 시간 안에 만료되어 무작위로 보이는 장애를 만들 수 있으므로 시각도 적어 두세요. 클라이언트가 로그를 제공하면 파일 전체가 아니라 첫 장애 주변 부분만 남기세요. 그 발췌만으로도 프로필 소유자가 단계를 식별하기에 충분합니다.

일반 접속이 되는데 협상이 계속 시간 초과되면 호텔에 그 트래픽을 지원하는지 물어보고, 기기와 프로필을 고정한 채 신뢰할 수 있는 핫스폿과 비교하세요. 핫스폿에서 해 보면 프로필에 대해 아무것도 증명하지 않고도 관심을 호텔 경로로 좁힐 수 있습니다.

운영자가 제공하는 대안만 사용하세요

맞는 TCP 프로필은 제시된 UDP 경로가 안 되는 곳에서 성공할 수 있지만, 서버가 실제로 그 전송과 포트에서 수신할 때만 그렇습니다. TCP 포트 443은 자동으로 일반 HTTPS로 취급되지 않고, 제한적인 네트워크를 통과한다는 보장도 아닙니다.

sudo openvpn --config /etc/openvpn/client/office-tcp.conf --verb 4

제공된 프로필을 더 높은 상세 수준으로 실행하면 첫 번째 유용한 오류가 일반 실패 대화상자에 묻히지 않고 보입니다. 로컬 변경은 반대편에 맞는 리스너를 만들 수 없으므로 운영자가 준 파일을 쓰고 포트나 프로토콜을 직접 고치지 마세요.

터널이 반복해서 재설정되면 포털이 다시 나타나는지, 로컬 신호가 떨어지는지 적고, 여러 프로토콜을 한꺼번에 바꾸지 말고 안정성 점검을 따르세요. 그런 다음 정말 필요한 앱을 시험하고 평소의 개인정보 보호 제어를 되돌리세요. 한 사이트는 되고 다른 사이트는 안 되는 연결은 포털이 아니라 라우팅이나 정책의 문제입니다.

마지막으로 노트북이 잠든 뒤의 복구를 확인하세요. 포털 승인은 터널과 별개로 만료될 수 있어서 자동으로 다시 연결되는 기기가 이미 잊어버린 네트워크로 돌아갈 수 있습니다. 포털 페이지를 다시 여는 것은 정상 단계이며 VPN 고장의 신호가 아닙니다.