VPN이 내 DNS를 바꿨을까? 연결 전후를 비교하세요

터널에 연결하고 비공개 대시보드를 열면, 이름이 한 번도 본 적 없는 주소로 해석됩니다. 아니면 반대의 일이 벌어집니다. 브라우저는 계속 작동하는데 명령줄 도구는 갑자기 아무것도 해석하지 못합니다. 두 결과 모두 같은 변경에서 나오지만, 사람들은 보통 VPN이 "자체 DNS를 쓴다"는 한 문장으로 설명하는데, 이는 문제를 좁히거나 검증하기에 충분히 정확하지 않습니다. 그 문장에는 두 가지 질문이 숨어 있습니다. 이 프로필이 어떤 조회를 맡아야 하는가, 그리고 기기가 실제로 그 조회를 부여받은 리졸버로 보냈는가. 둘을 분리해 다루는 것이 방법 전체이며, 둘을 섞은 시험은 양방향 모두에서 자신만만한 오답을 냅니다.

프로필이 리졸버를 제공하는 이유

터널 안에서는 원격 끝 너머의 이름이 보통 그 네트워크에만 존재하는 주소로 해석됩니다. corp.internal 같은 사설 영역에는 공개 위임이 없으므로, 이를 응답하는 리졸버는 터널 안에서 도달 가능해야 합니다. 같은 메커니즘은 두 번째 목적도 수행합니다. 조회가 그렇지 않으면 ISP를 통해 나갈 상황에서, 원격 쪽 리졸버가 질의를 암호화된 경로 안에 붙잡아 둡니다. DNS 서버 주소가 기기에 한 번 선택하는 전역 설정이 아니라 연결 정책의 일부로 도착하는 이유입니다.

주소만으로는 아무것도 결정되지 않습니다. 리졸버는 그곳으로 가는 경로가 있을 때만 응답할 수 있고, 가장 흔한 고장은 터널이 올라와 있는 동안에만 도달 가능한 리졸버입니다. 터널이 끊기고 정책이 남으면 조회는 경로가 없는 주소로 가고, 증상은 깔끔한 오류가 아니라 시간 초과입니다. 이 차이는 다음 시험 결과를 읽을 때 중요합니다. 시간 초과는 사람들을 전혀 관계없는 전송 설정으로 밀어 넣기 때문입니다.

응답을 비교하기 전에 두 설계를 비교하세요

전체 터널과 분할 DNS는 상반된 기대를 낳고, 둘 다 오작동이 아닙니다. 전체 터널에서는 모든 조회가 제공자나 기업 리졸버로 옮겨질 수 있으므로 연결 후 공개 이름이 다르게 응답하는 것은 예상된 일입니다. 분할 DNS에서는 목록에 있는 도메인만 사설 리졸버로 가고 나머지는 로컬에 남습니다. Windows에서는 도메인 목록이 Name Resolution Policy Table에, macOS에서는 DNS 설정의 일치 도메인에, systemd-resolved 호스트에서는 링크별 라우팅 도메인에 있습니다.

이 비교를 먼저 해야 합니다. 무엇을 결함으로 볼지 결정하기 때문입니다. 분할 DNS에서는 새 리졸버에서 응답하는 공개 이름이 조사할 가치가 있는 대상이고, 올바르게 응답하는 내부 이름은 시스템이 제 일을 하는 것입니다. 전체 터널에서는 여전히 ISP 리졸버에서 응답하는 공개 이름이 이상입니다. Microsoft의 VPN 이름 확인 문서는 이러한 규칙의 Windows 순서를 설명하며, 일치하는 정책 항목이 어댑터 자체 서버보다 먼저 참조되는 방식도 다룹니다.

방에는 잊기 쉬운 세 번째 리졸버도 있습니다. 브라우저의 보안 DNS는 스스로 이름을 해석하며 터널이 운영 체제 정책을 바꾼 뒤에도 응답을 계속할 수 있습니다. 그래서 페이지가 로드된다는 것은 브라우저 리졸버가 작동했다는 증거이지 프로필이 적용되었다는 증거가 아닙니다. 브라우저가 보여 주는 것만 비교하면 절반은 잘못된 계층을 시험하는 셈입니다.

변수 하나로 기준선을 기록하세요

터널을 바꾸세요. 같은 단계에서 이름, 도구, 검색 접미사까지 함께 바꾸지 마세요. 조회가 허용된 이름을 고르고, 어떤 응용 프로그램을 썼는지 적고, 돌아온 주소나 정확한 오류를 기록하세요. Windows에서는 Get-DnsClientServerAddress -AddressFamily IPv4이 어댑터별 서버를, Get-DnsClientNrptPolicy가 정책 항목을 출력합니다. systemd-resolved를 쓰는 Linux에서는 resolvectl status이 링크별 DNS 서버와 라우팅 도메인을 보여 줍니다. macOS에서는 scutil --dns가 시스템이 실제로 따를 리졸버 순서를 출력합니다.

그다음 클라이언트의 평소 제어 수단으로 연결하고 똑같은 명령을 반복하세요. 첫 출력은 기억이 아니라 저장해 두세요. 비교가 핵심이며, 캐시를 비운 뒤의 두 번째 읽기는 이미 다른 측정이기 때문입니다. 기준선을 브라우저를 앞에 두고 잡았는데 연결 후 실행은 터미널에서 했다면, 비교하는 것은 두 리졸버이지 한 리졸버의 두 상태가 아닙니다.

명시적 질의와 응용 프로그램 조회는 다른 시험입니다

특정 서버 하나에 nslookup name 10.20.0.1나 dig @10.20.0.1 name으로 질의하면 한 가지만 증명됩니다. 지목한 서버에 도달할 수 있을 때 그 서버가 응답한다는 것입니다. 선택 논리를 완전히 우회하므로 시스템이 이 이름에 그 서버를 골랐을지는 알 수 없습니다. 할당된 리졸버에 도달 가능한지 시험할 때 쓰고, 정책을 시험할 때는 쓰지 마세요.

로컬 리졸버를 통한 조회는 선택을 실제로 행사합니다. resolvectl query name은 같은 라우팅 도메인 규칙을 지나며 어떤 프로토콜이 응답했는지 보고하고, Windows의 Resolve-DnsName은 정책 테이블과 클라이언트 캐시를 거치며, scutil --dns은 조회가 따를 순서를 보여 줍니다. 두 종류를 모두 실행하고 메모의 별도 열에 나누어 두세요. 명시적 질의가 성공했는데 응용 프로그램 조회가 실패한다면 이는 경로나 선택의 문제이지, 작동을 거부하는 리졸버가 아닙니다.

캐시는 당신과 응답 사이에 서 있습니다. 운영 체제, 로컬 스텁 리졸버, 브라우저, 부정 캐시가 모두 결과를 보관하므로 패킷 하나도 기기를 떠나지 않고 조회가 성공할 수 있습니다. 무엇이든 비우기 전에 결과를 기록하세요. ipconfig /flushdns, resolvectl flush-caches, macOS라면 sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder입니다. 이 단계에서 광범위한 네트워크 초기화는 건너뛰세요. 아직 모으고 있는 증거를 파괴합니다.

그 차이가 뜻하는 것

기록한 두 행을 비교하고, 설정을 하나도 건드리기 전에 변화를 분류하세요.

한 행은 강조할 가치가 있습니다. 해석되는 이름은 작동하는 서비스가 아니며, DNS의 성공은 주소를 찾았다는 것만 말합니다. 전달, 방화벽 규칙, 계정이 그 서비스를 쓸 수 있는지에 대해서는 아무것도 말하지 않습니다. 실패가 저절로 물러났다고 가정하지 말고 실제 응용 프로그램을 시험하며 마무리하세요.

기준선을 복원하고 검증하세요

프로세스를 죽이는 대신 클라이언트 자체 제어로 연결을 끊고, 같은 세 명령을 다시 읽으세요. 링크별 서버, 정책 항목, 시험 이름의 응답은 앞서 적은 기준선으로 돌아가야 합니다. 깨끗하게 끊은 뒤 남는 정책 항목은 기록할 가치가 있는 실제 결함이며, 생성된 리졸버 파일을 손으로 편집하는 것이 나쁜 습관인 이유도 같습니다. 파일이 다시 쓰여 편집이 사라지거나, 편집이 살아남아 더는 경로가 없는 리졸버를 고정합니다.

이 목록을 한 번, 순서대로 훑으세요. 결과를 판단하기 전에 프로필이 어떤 설계를 구현하는지 정하세요. 두 번의 실행에서 이름, 도구, 접미사를 고정하세요. 명시적 질의를 응용 프로그램 조회와 분리하세요. 응답만이 아니라 유효한 정책을 읽으세요. 비교를 적은 뒤 캐시는 마지막에 비우세요. 실제 응용 프로그램으로 검증하고, 그다음 한 번 재부팅해 연결 해제 상태가 여전히 깨끗한지 확인하세요.