캡티브 포털과 VPN의 교착: 어느 쪽이 먼저 움직이는가
호텔 포털은 터널이 생기기 전에 트래픽을 요구하고, VPN은 터널이 올라오기 전까지 트래픽을 막는다. 두 가지 순서와 그 틈에서 각각 무엇이 드러나는지 비교한다.
호텔 포털은 어떤 트래픽도 통과시키기 전에 브라우저를 요구한다. 당신의 VPN은 터널이 올라오기 전에는 트래픽을 통과시키지 않는다. 양쪽이 서로를 기다리고 있고, 둘 다 설정된 대로 정확히 동작한다. 이 교착을 깨는 순서는 두 가지뿐이며, 틈이 열려 있는 동안 무엇을 노출하는지가 다르다. 브라우저가 열리게 만드는 설정을 이리저리 바꾸는 대신, 둘 중 하나를 의도적으로 고르라.
두 가지 순서, 그중 하나는 통한다
네트워크가 먼저 당신을 받아들이고 터널이 나중에 오거나, 포털을 위해 좁은 예외를 열고 나중에 차단을 되돌리거나. 둘 다 정당하다. 정당하지 않은 것은 차단을 꺼 두고 되돌리는 것을 잊는 일이다.
| Order | What it costs | When it fails |
|---|---|---|
| Admit, then connect | Nothing extra; the block stays on | The client cannot reach the portal with the tunnel down |
| Exception, then restore | A timed window of direct access | The window is left open, or scoped too broadly |
두 순서가 모든 상황에서 똑같이 좋은 것은 아니다. 입장 절차가 의무인 관리 기기에는 한 가지 답이 있고, 호텔 Wi-Fi에 연결한 개인 노트북에는 다른 답이 있다. 비교의 핵심은 각 선택이 무엇을 포기하는가이다.
먼저 당신의 클라이언트와 기기 정책이 실제로 어느 쪽을 지원하는지 아는 것에서 시작하라.
선택지 A: 네트워크를 먼저 허용하고, 그다음 터널을 연결한다
예상되는 네트워크 이름을 확인한 뒤 운영체제의 로그인 요청이나 클라이언트가 지원하는 캡티브 포털 흐름을 사용하라. iPhone과 iPad에서는 로그인 시트를 닫을 때 연결이 끊길 수도 있고, 인터넷이 없다는 경고와 함께 유지될 수도 있으며, 이 둘은 서로 다른 출발점이다. 먼저 입장 단계를 마치고, 그다음 터널을 올려라. 이 순서는 터널이 내려가 있는 동안 내내 차단을 그대로 유지한다.
함정은 인터넷 접속을 허가하는 포털이 당신의 VPN 계정을 인증한 것은 아니라는 점이다. 터널은 그 뒤에도 연결되어야 하며, 그 자체의 이유로 실패할 수 있다. 입장과 인증은 사람들이 하나로 합쳐 버리는 별개의 사건이다.
입장이 계속 만료된다면 포털이 다시 요구하는지, 네트워크가 끊기는지, 아니면 VPN만 실패하는지 기록하라.
선택지 B: 좁은 로그인 예외를 열고, 그다음 차단을 되돌린다
다른 방법은 차단을 나머지 부분에서는 그대로 둔 채 포털의 트래픽만 허용하고, 로그인한 뒤 예외를 제거하는 것이다. 예외는 좁아야 한다. 목적지 하나 또는 주소 범위 하나를, 로그인하는 동안만, 직후에 차단을 되돌리는 조건으로. 넓은 임시 창은 이 분짜리 로그인이 오후 내내 무방비 트래픽이 되는 경로다.
당신의 클라이언트가 실제로 무엇을 구현하는지 알아라. macOS의 OpenVPN Connect는 VPN이 일시중지되거나 다시 연결되는 동안 인터넷 접속을 차단하는 옵션과 별도로 캡티브 포털 감지를 문서화한다. 포털을 감지하는 것과 그 트래픽을 허용하는 것은 관련된 작업이지 서로 바꿀 수 있는 약속이 아니다.
관리 기기에서는 예외를 만들어 내지 말고 설정된 입장 절차를 따르라.
그 틈이 무엇을, 누구에게 드러내는가
이 교착에서 흥미로운 것은 눈앞의 브라우저 탭이 아니다. 연결이 나타나는 순간 네트워크를 쓰기 시작하는 나머지 모든 것이다. 메일, 사진 동기화, 업데이트 확인, 다시 연결되는 채팅 클라이언트, 재개되는 백업 에이전트.
조용한 브라우저 창은 그런 것들에 대해 아무것도 알려주지 않는다. 허용된 직접 접속 구간 전에 민감한 작업을 닫거나 멈추고, 로그인 시 무엇이 실행되는지 확인하라. Android에서는, VPN 외부 연결 차단과 결합한 상시 연결 VPN 이 해당 제어이며, 임의의 경로 예외는 그것을 이해하는 일을 대신하지 못한다.
임시 접속 창에 대한 옛 조언이 여전히 유효한 곳은 여기 하나뿐이다. 방식이 틀렸더라도 걱정은 옳았다.
어떻게 고르고 어떻게 확인할까
기기나 클라이언트가 진짜 포털 흐름을 지원하면 선택지 A를 골라라. 차단이 내내 유지되기 때문이다. 포털에 다른 방법으로 닿을 수 없다면 선택지 B를 고르고, 예외는 담당자가 있는 기한부 변경으로 다뤄라.
그다음 결과가 아니라 순서를 확인하라.
curl -sS --max-time 8 https://example.com -o /dev/null -w '%{http_code}\n'입장을 마치고, 의도한 프로필을 세우고, 임시로 바꾼 차단 제어를 되돌린 뒤, 새롭고 무해한 요청을 보내 그것이 터널을 따르는지 확인하라. 차단이 아직 꺼져 있어서 성공하는 요청은 터널에 대해 아무것도 증명하지 않는다.
VPN 출구를 바꿔도 만료된 호텔 세션이 갱신되지는 않는다. 그것은 별개의 사건이고, 혼동하면 엉뚱한 곳을 찾게 된다.