캡티브 포털이 VPN을 막는 이유와 다시 로그인하는 방법
공용 Wi-Fi는 패킷이 하나도 나가기 전에 기기를 승인합니다. 포털이 무엇을 버리는지, VPN이 왜 그것을 잘못 보고하는지, 그리고 다시 연결하는 순서.
개방형 네트워크에서 액세스 포인트는 패킷을 그냥 인터넷으로 넘기지 않습니다. 상류의 정책 지점이 기기가 아직 승인되었는지 확인하고, 승인될 때까지 거의 모든 것이 버려집니다. VPN 클라이언트는 그 침묵을 죽은 서버로 읽습니다. 그러나 그렇게 말하는 경우는 드물고, WireGuard는 허공으로 핸드셰이크를 재시도하고, OpenVPN은 연결 시간 초과를 보고하며, IKEv2는 응답하지 않는 원격 서버에 대한 오류 809로 돌아옵니다.
포털이 실제로 제어하는 것
캡티브 포털은 정책 결정 지점과 리디렉터라는 두 가지가 붙어 있는 것입니다. 기기가 연결되고 DHCP 임대를 받으면, 네트워크는 당신을 승인 전 상태에 둡니다.
그 상태는 방화벽 규칙 집합입니다. 보통 DNS를 허용하고 짧은 포털 호스트 목록으로의 HTTP 또는 HTTPS를 허용하며, 나머지는 모두 버립니다. 허용 목록은 담장으로 둘러싸인 정원이고, VPN 엔드포인트는 거의 포함되지 않습니다.
이 버림은 어느 것도 예의 바르지 않습니다. VPN 서버로 향한 패킷은 거부되지 않고 버려지므로, 클라이언트는 ICMP unreachable도 TCP reset도 받지 못하고 응답이 없을 뿐입니다. 벤더에 따라 리디렉터가 포트 80에는 로그인 페이지로의 리디렉션으로 응답하고, 포트 443은 버리거나 가로챕니다. 리디렉션은 평문 HTTP 응답을 실어 나르므로 쉽게 알아볼 수 있고, 443의 가로채기에는 브라우저가 신뢰를 거부할 인증서가 필요합니다.
승인 자체는 보통 기기의 MAC 주소에 묶이고, 때로는 임대된 IP에 묶이며, 타이머가 있는 세션 테이블에 존재합니다. 로그인하면 항목이 생깁니다. 당신의 트래픽을 통과시키는 방화벽 규칙은 그 항목이 있는 동안에만 존재하므로, 당신 쪽에서 아무것도 바뀌지 않았는데도 문제 전체가 나중에 다시 나타납니다.
VPN 핸드셰이크가 시작되기도 전에 죽는 이유
프로토콜마다 전송 방식이 다르고, 승인 전 방화벽은 각각을 다르게 부숩니다. Windows와 iOS의 IKEv2는 UDP 500과 UDP 4500을 사용하며, 이 포트에서의 버림은 809로 나타나거나 단계를 따로 보고하는 클라이언트에서는 이름 해석 같은 실패로 나타납니다. UDP 1194의 OpenVPN은 시간 초과가 끝날 때까지 연결 중 상태에 머뭅니다. TCP 443의 OpenVPN은 흥미로운 경우인데, 포털이 TCP 핸드셰이크를 끝낸 뒤 리디렉션 페이지로 응답할 수 있어서 시간 초과 대신 TLS 오류가 보입니다.
WireGuard는 이 메커니즘을 가장 명확히 보여 줍니다. 설계상 UDP 전용이고 TCP 대체가 없으므로, 알 수 없는 UDP를 버리는 방화벽은 전송을 완전히 제거합니다. 클라이언트는 간격을 늘려 가며 핸드셰이크 시작을 계속 보내고, 결코 완료되지 않는 핸드셰이크를 보고합니다. 그 메시지에는 Wi-Fi 언급도 없고, 브라우저를 열어야 한다는 암시도 없습니다.
플랫폼은 VPN보다 먼저 상태를 알아차리려 합니다. Windows는 알려진 URL을 가져와 로그인 알림을 표시할지 결정하고, Android는 204 No Content로 응답해야 하는 엔드포인트를 요청하며, Apple 기기는 작은 캡티브 네트워크 창을 엽니다. 이런 프로브가 작동하는 이유는 포털이 기대한 본문 대신 리디렉션으로 응답하기 때문입니다. 같은 동작이 터널은 죽었는데 포털은 완벽히 건강해 보이는 이유를 설명하는데, 프로브와 터널은 서로 다른 규칙으로 판정됩니다.
세션 만료가 실제로 초기화하는 것
업소는 유휴 시간 초과, 최대 세션 길이, 새 DHCP 임대, 또는 다른 액세스 포인트로의 재연결 같은 VPN 계정과 무관한 이유로 세션을 만료시킵니다. 타이머가 작동하면 세션 테이블 항목이 사라지고, 승인 전 규칙 집합이 체크인 때와 똑같은 상태로 돌아옵니다.
이미 수립된 터널은 건강해 보일 만큼 오래 살아남는 경우가 많습니다. 킵얼라이브는 계속 나가고, 클라이언트가 그것을 알아차릴지는 응답 없는 트래픽을 어떻게 다루느냐에 달려 있으므로, 경로가 사라진 뒤에도 상태 표시등이 한동안 초록색일 수 있습니다. 그러다 터널이 떨어지고, 재연결 시도는 매번 같은 차단된 포트에서 실패합니다.
그 시점에 클라이언트 오류는, 주의 깊게 읽으면, 당신이 어느 단계에 있는지 알려 줍니다:
| Symptom | What it means | Next check |
|---|---|---|
| Handshake times out with no reply | Pre-authorization drop on UDP | Load any HTTP page and see whether the portal appears |
| Immediate TLS error on 443 | The portal answered your TCP connection | Authorize, then retry the same profile |
| Authentication rejected | Your credentials reached the server | The network is fine, so treat this as an account problem |
| Connects, then drops repeatedly | Session or lease churn | Watch the portal timer and the lease time |
사람들을 헷갈리게 하는 점이 하나 있는데, 세션이 MAC 주소에 묶여 있으면 로그인 페이지를 새로 고쳐도 도움이 되지 않을 수 있습니다. 연결을 끊고 다시 가입해야, 포털이 만료된 시도 대신 새로운 승인 시도를 봅니다.
먼저 로그인하고, 그다음 터널을 올립니다
작동하는 순서는 기기를 승인하고, 경로를 증명하고, VPN을 시작하고, 터널을 증명한 다음, 평소의 차단을 복원하는 것입니다. 마지막 단계가 중요한 이유는, 포털에 도달하기 위해 필요한 임시 상태가 바로 킬 스위치가 막기 위해 존재하는 상태이기 때문입니다.
터널 밖 차단 옵션이 있는 데스크톱 클라이언트는 포털 페이지가 로드되도록 일시 중지해야 하고, 그 터널 밖 구간에는 로컬 트래픽이 보호 없이 나가는 유일한 구간이므로 민감한 앱을 닫아 두어야 합니다. 관리되는 상시 연결 기기는 당신이 정책을 제거하는 대신 소유자가 공개한 절차를 사용해야 합니다. 포털이 인증서 경고를 표시하면, 받아들이는 순간 세션이 업소의 가로채기 프록시를 거치고 그 프록시가 보내는 모든 것을 읽을 수 있으므로 멈추십시오. Android에서는 상시 연결 VPN 아래의 잠금이 터널이 올라오기 전에 트래픽을 차단하고, 일부 빌드는 포털 흐름을 예외로 두지 못하므로, 당신의 빌드가 그렇다면 잠금을 꺼 둔 채로 두지 말고 업소의 대체 접속이나 다른 기기를 사용하십시오. Apple의 온디맨드 규칙은 프로브가 성공할 때까지 터널을 거부하도록 쓸 수 있으며, 이것이 호텔 네트워크에서 원하는 동작입니다.
이미 가진 도구로 순서대로 확인하십시오. 터널 전에 헤더와 본문이 모두 보이도록 프로브를 실행하고, VPN 전송이 응답을 조금이라도 받는지 보십시오:
curl -sS -D - http://captive.apple.com/hotspot-detect.html -o -
sudo tcpdump -ni any 'udp port 500 or udp port 4500 or udp port 1194'승인 전에 정상적인 포털은 두 가지 중 하나를 돌려줍니다: Location이 로그인 페이지를 가리키는 302이거나, 포털 페이지인 HTML 본문을 가진 200입니다. 어느 것을 받았는지 기록하십시오. 로그인 전의 리디렉션은 실패가 아니라, 포털이 어디로 가야 하는지 알려 주는 것입니다. 포털이 성공을 보고하면 명령을 다시 실행하고, 본문이 문자 그대로 Success라는 단어인 200을 기대하십시오. 그 문자열이 프로브를 의미 있게 만듭니다. 로그인하기 전에 호스트가 정상적으로 응답한다면, 이 네트워크에는 가로채는 포털이 없습니다. 캡처에서 승인 전 버림은 아무것도 돌아오지 않는 나가는 패킷이고, 작동하는 경로는 같은 흐름에 약 일 초 안에 응답을 보여 줍니다. 연결한 다음 캡처를 반복하십시오.
포털이 예라고 한 뒤에도 터널이 실패하면
로그인 성공은 허용된 전송과 같지 않습니다. 많은 업소가 포털과 일반 브라우징은 허용하면서 UDP를 완전히 차단하며, 그러면 WireGuard와 UDP OpenVPN은 깨지고 TCP 443은 작동합니다. TCP 443은 통과하는데 UDP가 통과하지 않는다면, 그것은 잘못 구성한 클라이언트가 아니라 업소의 정책이므로 전송을 바꾸거나 한계를 받아들이고 넘어가십시오. 그 뒤에도 재연결이 실패하면, 어느 단계에서 막혔는지 알려 주는 정확한 오류를 보관하십시오.
다른 실패는 기기 쪽에 있습니다. 옛 MAC에 묶인 채인 세션, 자체 임대를 가진 두 번째 Wi-Fi 어댑터, 포털의 인증서 예외를 캐시한 클라이언트는 모두 깨끗하게 재승인한 뒤에도 계속 실패할 수 있습니다. 연결을 끊고 다시 승인한 다음, 클라이언트 설정을 건드리기 전에 한 번만 시도하십시오. 관찰 중인 구성 요소 뒤의 아키텍처를 알고 싶다면 RFC 8952를 읽을 가치가 있습니다.
포털 자체가 승인을 거부한다면, 문제는 계정이나 기기 할당에 있고 어떤 VPN 설정도 그것을 고치지 못합니다. VPN의 출구 국가를 바꿔도 업소의 로컬 접속 상태는 초기화되지 않으며, 그 테이블은 당신의 기기에 묶여 있고 선택한 서버에 묶여 있지 않습니다. 업소 운영자에게, 운영자가 볼 것은 세션 테이블이므로, 시간을 달라고 요청하십시오.
다음 여행 전에 영 단계로서의 포털 페이지, 가지고 가는 기기마다의 차단 중지 단계, 그리고 실제로 시험해 본 대체 전송 하나, 이 세 가지를 적어 두십시오. 십 분 전에 작동하던 터널이 다시 멈추면 만료된 승인으로 보고, VPN 프로필을 건드리기 전에 포털을 다시 확인하십시오.