VPN은 연결됐지만 이름이 실패한다: DNS가 실제로 끊기는 곳

터널은 올라가 있고 아이콘은 초록인데, 브라우저의 모든 탭이 이름 확인 실패를 보고한다. 이 그림을 만드는 메커니즘은 세 가지다. 리졸버에 닿을 수 없거나, 예상하지 못한 리졸버에 물어보고 있거나, 사설 이름만 실패할 수 있다. 터널 프로토콜을 바꾸기 전에 이 셋을 갈라 놓아라. 각각 고치는 곳이 다르기 때문이다. 아래 순서는 셋을 구분하는 관찰에서 시작한다.

조회에 실제로 필요한 것

조회에는 세 가지가 필요하다. 리졸버 주소, 그 주소로 가는 경로, 그리고 질문에 맞는 응답이다. 각각 따로 실패할 수 있고, 눈에 보이는 증상은 똑같이 로드되지 않는 페이지다. 그래서 셋 중 무엇이 깨졌는지 알기 전까지 오류 페이지는 거의 아무것도 알려주지 않는다.

클라이언트는 리졸버를 VPN 프로필, 터널의 DHCP, 또는 자체 설정에서 배우며, 어느 출처가 이기는지는 플랫폼에 달려 있다. Windows에서는 ipconfig /all 어댑터별 DNS 서버를 출력하므로, 밀어 넣은 값이 실제로 도착했는지 볼 수 있다. 운영체제에 끝내 도달하지 못한 값은 조용하고 흔한 실패다. 프로필을 건드리기 전에 설정된 값을 읽어라.

Linux와 macOS는 같은 질문에 다른 명령으로 답하며, 그 답은 같은 방식으로 읽을 가치가 있다. resolvectl status 와 scutil --dns 둘 다 인터페이스별 서버를 나열한다. 그 목록을 프로필이 밀어 넣는다고 주장하는 주소와 비교하라. 여기의 불일치는 하류의 모든 것을 설명하므로, 이름을 시험하기 전에 정리하라.

공용 이름 하나와 사설 이름 하나를 시험하라

같은 머신에서 평범한 공용 호스트 이름과 문서화된 사설 호스트 이름을 질의하고, 어느 서버가 각각에 답했는지 기록하라. 둘 다 실패하면 리졸버나 그 경로가 깨진 것이다. 사설 이름만 실패하면 리졸버는 답한 것이고 질문은 영역이나 라우팅으로 바뀐다. 경로 변경이 차이를 설명하지 못하도록 두 질의를 일 분 안에 실행하라.

사내 이름은 공개 스크린샷과 공용 리졸버 밖에 두어라. 타임아웃과 존재하지 않는 도메인 응답은 다른 관찰이다. 전자는 아무것도 돌아오지 않았다는 뜻이고, 후자는 권한이 그 이름이 없다고 답했다는 뜻이다. 둘을 하나의 오류로 다루면 잘못된 계층으로 가게 되고, 인증서 경고는 또 다른 세 번째 문제이지 DNS 실패가 아니다.

nslookup 은 질의한 서버와 받은 응답을 모두 출력하며, 바로 그것이 필요한 쌍이다. 같은 셸에서 두 번 실행하고 각 응답 옆에 응답한 주소를 적어라.

nslookup example.com
nslookup host.corp.example 10.20.30.53

클라이언트가 그 서버에 실제로 닿을 수 있는지 확인하라

프로필이 밀어 넣은 사설 리졸버는 터널이 올라가 있는 동안 클라이언트가 닿을 수 있을 때만 쓸모가 있다. 올바르게 보이는 주소라도 경로가 없으면 타임아웃이 나고, 터널의 연결 상태는 그 경로에 대해 아무것도 말해주지 않는다. 확인은 VPN 종단이 아니라 리졸버 자체를 향한 경로 조회다.

각 플랫폼은 한 줄로 답하며, 출력에 나온 인터페이스가 답의 전부다. 리졸버가 터널 뒤에 있는데 물리 어댑터를 가리킨다면, 프로필은 그것을 덮는 프리픽스를 밀어 넣지 않는 것이다.

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

분할 터널 프로필에서는 리졸버가 밀어 넣은 경로 밖에 있을 수 있고, 이는 서버가 아니라 프로필의 문제다. 리졸버 주소를 밀어 넣은 프리픽스와 비교하고 그중 하나가 그것을 덮는지 확인하라. 같은 불일치가 왜 한 네트워크에서는 DNS가 되고 동일한 프로필의 다른 네트워크에서는 실패하는지 설명한다.

브라우저가 시스템 리졸버를 우회할 수 있음을 기억하라

보안 DNS를 켠 브라우저는 HTTPS로 자신이 고른 제공자에게 질의를 보내고 운영체제의 리졸버를 완전히 무시할 수 있다. 그러면 시스템은 멀쩡해 보이는데 브라우저가 실패하거나 그 반대가 된다. 이는 터널이 아니라 브라우저의 정책 문제다.

브라우저의 보안 DNS 설정과 이를 제어하는 관리 정책을 확인하고, 터널을 그대로 둔 채 두 번째 애플리케이션이나 브라우저를 시험하라. 한 애플리케이션만 실패하면 수정은 그 애플리케이션에 속한다. 시크릿 창은 깨끗한 비교가 아니다. 한 브라우저에서는 기본으로 확장을 끄고 다른 브라우저에서는 끄지 않을 수 있으며, 관리 정책을 결코 우회하지 않는다. 대신 두 번째 브라우저 프로필이나 다른 애플리케이션을 써라.

캐시를 비우고 실제 작업을 다시 시험하라

설정을 고친 뒤 로컬 리졸버 캐시를 비워 오래된 응답이 수정보다 오래 살지 않게 하라. 잠깐 회복된 뒤 다시 실패하면 원인이 아직 있다는 뜻이지 캐시 비우기가 실패했다는 뜻이 아니다. 세 캐시는 별개이므로 지금 쓰는 머신에 맞는 줄을 골라라.

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

그다음 합성 조회가 아니라 원래 작업을 반복하라. 사용자에게 중요한 것은 작업 그 자체이기 때문이다. 한 번은 다시 연결해서, 재시험이 사용자가 실제로 놓일 상태를 덮게 하라. Microsoft의 nslookup 참조 는 질의 인자를 위해 남겨 둘 페이지다.

연결을 끊은 뒤에만 이름이 실패한다면, 클라이언트가 이전 구성을 복원하지 않은 것이다. 이는 보고해야 할 수명 주기 버그이지 교체해야 할 DNS 서버가 아니다. 조회가 된다고 해서 유출 테스트가 되는 것도 아니며, 출구 국가는 어느 리졸버가 답했는지 알려주지 않는다.