VPN이 연결되기 전에 핫스팟이 DNS를 리디렉션하는 이유는 무엇일까?
핫스팟은 자기 네트워크에서 조회를 다시 쓰고, 호스트 이름 엔드포인트는 어떤 터널도 존재하기 전에 확인된다. 각 질의에 어느 리졸버가 답했는지 추적해 보자.
호텔 네트워크에 접속하면 서로 다른 시점에 두 가지 DNS 결정이 앞에 놓인다. 로그인하는 동안 기기가 하는 조회와 터널이 올라온 뒤에 이루어지는 조회다. 핫스팟은 자기가 제어하는 네트워크를 통해 첫 번째에 영향을 줄 수 있다. 두 번째는 클라이언트 자체의 정책에 달려 있으며, 이는 따로 점검할 사안이다.
연결 과정을 첫 DHCP 임대에서 사설 이름을 확인한 질의까지 순서대로 살펴보자. 그러면 지원 티켓에서 똑같아 보이는 두 장애가 깔끔하게 갈린다. 하나는 터널이 생기기 전에 일어났고, 다른 하나는 그 안에서 일어났다.
핫스팟이 건드릴 수 있는 것과 없는 것
액세스 네트워크는 DHCP로 리졸버 주소를 주고 그 주소로 가는 포트 53을 가로챌 수 있다. 그것만으로 보호되지 않는 모든 조회에 포털 주소나 차단 페이지로 답할 수 있다. 엔드포인트가 호스트 이름으로 적힌 VPN 클라이언트를 깨뜨리기에도 충분하다.
핫스팟이 할 수 없는 것은 질의가 이미 성립된 터널 안을 지난 뒤 그것을 읽거나 고쳐 쓰는 일이다. 물론 터널이 실제로 그 질의를 실어 나를 때 이야기다. 가로채기는 평문 질문을 보는 데 달려 있다.
질의는 핫스팟과 무관한 이유로도 터널을 떠난다. 브라우저의 보안 DNS 설정, 기업 접미사를 로컬 리졸버에 남기는 split-DNS 규칙, DNS를 터널에서 빼도록 설정된 클라이언트가 그렇다. 각각 클라이언트 쪽 선택이며, 밖에서 보면 모두 핫스팟의 간섭처럼 보인다.
| Path | Who answers | What a failure looks like |
|---|---|---|
| Lookup before the tunnel is up | The network's resolver | The client never reaches its endpoint |
| Lookup inside the tunnel | The resolver pushed by the client | Local policy or tunnel DNS is misconfigured |
| Browser secure DNS | A DoH provider over port 443 | Both the hotspot and the tunnel policy are bypassed |
최초 조회는 터널이 생기기 전에 일어난다
호스트 이름을 받은 클라이언트는 먼저 그것을 확인해야 하고, 그 순간 어떤 터널도 질의를 보호하지 않는다. 핫스팟이 포털 주소로 답하면 협상이 실패하거나 멈춘다. 아무것도 답하지 않으면 클라이언트는 이름 오류를 보고하고 터널은 시작되지 않는다. 두 결과 모두 그렇지 않으면 순진해 보이는 빈 터널 로그를 설명해 준다.
운영체제도 자체 연결 검사와 포털 검색을 수행하며, 이는 RFC 8910과 RFC 8952에 기술되어 있다. 그 요청들은 어떤 VPN도 올라오기 전에 나간다. 프록시 로그에서 그것들을 보는 것은 유출의 증거가 아니라 예상된 동작이다.
실용적인 해법은 조회가 필요 없는 엔드포인트를 클라이언트에 주는 것이다. 그것이 불가능하면 먼저 로그인을 마치고 그다음에 연결한다.
어느 리졸버가 답했는지 알아내기
브라우저가 아니라 시스템에 물어보고, 질의를 두 번, 즉 한 번은 기기가 지금 쓰는 리졸버를 통해, 한 번은 고정 주소를 상대로 실행한다.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
첫 명령의 답이 세 번째와 다르면 로컬 리졸버가 다른 것을 돌려주고 있다는 뜻이며, 리디렉션하는 핫스팟이 바로 그렇게 한다. 세 번째의 실패가 첫 번째의 성공과 함께 나타나면 포털을 가리킨다. 로컬 리졸버가 로그인 주소를 내주는 동안 나가는 포트 53이 버려진 것이다. 둘 다 시간 초과라면 인증이 끝날 때까지 네트워크가 DNS를 버린다는 뜻이다.
연결한 뒤 다시 반복해 비교하자. 캐시된 답은 전환을 견디므로 캐시를 비우거나 두 번째 관찰에는 새 이름을 질의하자.
이후 조회를 의도한 경로에 두기
DNS까지 잡는 전체 터널 프로필이 가장 단순한 구성이다. 모든 앱의 모든 질의가 터널이 밀어 넣는 리졸버로 가고, 로컬 네트워크는 암호화된 트래픽만 본다. 연결한 뒤 내부 이름과 공개 이름을 확인하고, 두 답을 터널 리졸버가 혼자 돌려주는 것과 비교하면 증명된다.
split-DNS에는 기업 접미사는 터널로, 나머지는 로컬로, 둘 사이에 겹침은 없어야 한다는 의도를 담아 쓴 도메인 목록이 필요하다.
브라우저의 보안 DNS는 그 정책 밖에 있다. 그래서 프로필이 예측 가능하게 동작하려면 꺼 두어야 할 경우, 기계 전체가 아니라 그 프로필에 대해 끄자. 시스템 리졸버를 편집하는 대신 브라우저 설정에서 해야 다음에 변경이 보인다. 시험마다 답, 리졸버, 연결 단계를 한 줄로 기록하자. 호텔 Wi-Fi에서 DNS가 실패했다는 보고서는 적어도 세 가지 다른 원인이 있는 증상을 설명할 뿐이다.