VPN의 DNS와 브라우저 DoH: 유출 테스트가 알려주지 못하는 것

유출 테스트 페이지는 DNS가 괜찮다고 하고, 브라우저 배지는 안전하다고 하며, 사내 위키는 여전히 열리지 않는다. 세 가지는 동시에 사실일 수 있다. 리졸버의 주소는 그것을 선택한 정책이나 질의가 지나간 경로와 같은 것이 아니기 때문이다. 사람들이 DNS 유출이라고 부르는 것은 사실 하나의 질문이다. 어느 리졸버가 이름을 받았는지, 그리고 그 선택은 의도된 것이었는지. 이것을 정리하려면 세 가지 확인이 필요하고, 설정을 바꾸는 것은 마지막 하나뿐이다.

첫 번째 신화: 배지가 리졸버를 알려 준다

유출 테스트는 프로브 이름을 확인하고 응답한 주소를 보고한다. 그것은 그 리졸버를 선택한 정책을 보고하지 않으며, 질의가 DNS over HTTPS로 감싸여 있으면 경로상의 중간 장치는 이름을 전혀 볼 수 없다. 아주 다른 두 기계가 같은 안심 배지를 만든다. 하나는 VPN이 10.8.0.1을 밀어 넣고 브라우저가 그것을 쓰는 경우이고, 다른 하나는 브라우저가 시스템 목록을 무시하고 이름을 터널을 통해 자체 암호화 공급자에게 보낸 경우이다.

이 차이는 사설 이름이 실패하는 순간 중요해진다. 첫 번째 구성에서는 VPN 리졸버가 기업 영역에 응답한다. 두 번째에서는 브라우저가 한 번도 물어보지 않았으므로 짧은 호스트 이름이 확인되지 않고, 실패는 고장 난 VPN처럼 보인다. 이 확인은 또 다른 유출 테스트가 아니라, 오직 한 리졸버만 아는 이름에 대한 조회이다.

두 번째 신화: 브라우저가 터널을 벗어난다

DNS는 주소를 고르고, 라우팅은 연결을 나른다. 이 둘은 별개의 계층이다. 공개 DoH 공급자에게 보낸 질의도 여전히 라우팅 가능한 주소로 가는 TCP 포트 443이다. 라우트 테이블이 기본 경로를 터널로 보내면 그 질의도 터널을 지난다. 리졸버의 브랜드가 경로를 결정하지 않는다.

브라우저 DoH가 바꾸는 것은 이름의 수신자이다. 그것은 진짜 프라이버시 결정이자 진짜 정책 결정이지만, 라우팅 우회는 아니다. 이름이 VPN 운영자에게 남아야 한다는 것이 요구 사항이라면, 다른 누군가에게 보내는 암호화된 질의는 그 요구를 충족하지 못한다. 다만 실제 연결에는 여전히 터널을 쓴다.

세 번째 신화: 모든 VPN이 모든 브라우저를 덮어쓴다

브라우저의 보안 DNS에는 스위치가 아니라 모드가 있다. 끔, 대체가 있는 기본 공급자, 사용자 지정 템플릿, 또는 운영 체제나 조직이 강제하는 정책이다. 간헐적 보고를 만드는 것은 바로 대체 모드이다. 암호화된 엔드포인트에 닿을 수 없으면 브라우저가 시스템 리졸버로 되돌아갈 수 있다. 그래서 같은 노트북이 월요일에는 사설 이름을 올바르게 확인하고 화요일에는 확인하지 못한다.

동시에 대부분의 VPN 클라이언트는 연결이 올라올 때 시스템 리졸버를 설정하고, 연결이 끊기면 이전 것으로 되돌린다. 사용자 지정 암호화 리졸버를 쥐고 있는 브라우저는 그 복원을 전혀 관찰하지 않는다. 그래서 같은 프로필이 두 노트북에서 다르게 동작하고, 그래서 브라우저가 여전히 다른 누군가에게 묻는데도 resolv.conf은 올바르게 보인다.

resolvectl status                 # per-link DNS servers and split-DNS domains
scutil --dns | head -30           # macOS resolver order for each domain
nslookup intranet.corp 10.8.0.1   # ask the VPN resolver directly

연결된 상태에서 이것들을 실행하고, 각 리졸버가 어떤 도메인을 주장하는지 기록하고, 브라우저가 자기 모드에 대해 보고하는 것과 비교한다. Mozilla의 DoH 문서는 브라우저의 기본 및 대체 동작이 어떻게 작동해야 하는지에 대한 합리적인 설명이다.

결정에는 세 가지 입력이 있다, 하나가 아니라

사설 이름, 운영자에 대한 신뢰, 도달 가능성이 올바른 배치를 결정한다. VPN 리졸버만 아는 이름은 분할 DNS를 강제한다. 사설 접미사는 밀어 넣은 리졸버로 가고, 나머지는 공개 이름에 대해 고른 정책을 따른다. 운영자에 대한 신뢰는 공개 이름도 그 리졸버로 갈지 별도 서비스로 갈지를 결정한다. 도달 가능성은 고른 암호화 리졸버가 이 네트워크에서 애초에 쓸 수 있는지를 결정한다.

이 행들 중 어느 것도 보편적 권고가 아니다. VPN이 운영하는 리졸버는 관찰을 그 운영자에게 집중시킨다. 별도 서비스는 질의된 이름의 수신자를 하나 더 늘린다. 어느 배치도 정책을 읽지 않으면 보관에 대해 아무것도 증명하지 못한다.

프로필마다 결정을 적어 두어라. 이 설정들은 흘러가기 때문이다. 지난달 리졸버를 밀어 넣은 프로필이 오늘은 아무것도 밀어 넣지 않을 수 있고, 브라우저는 여전히 응답하는 옛 사용자 지정 엔드포인트를 기꺼이 유지한다. 메모에는 리졸버 주소, 그것이 소유한 접미사, 브라우저 모드가 들어가야 하며, 서비스 브랜드가 아니다.

설정했다고 생각하는 정책을 시험하라

배지가 아니라 이름으로 시험하라. 시스템 리졸버를 통해 공개 이름과 사설 이름을 확인한 뒤, 사용하려는 모드에서 브라우저 자체의 보안 DNS 설정으로 반복하라. 사설 이름이 브라우저에서만 실패한다면, VPN 설정을 하나도 건드리지 않고 수신자 불일치를 찾은 것이다.

그다음 다시 연결해 복원을 확인하라. 인계 버그가 바로 거기에 사니, 연결을 끊고 이전 리졸버가 돌아왔는지 확인하고 다시 연결해 밀어 넣은 리졸버가 돌아왔는지 확인하라. 마지막으로 관리 정책이 있는 브라우저가 있다면 시험하라. 그 모드는 변경을 완전히 거부하고 조용히 이전 리졸버를 유지할 수 있다.

이름 공간 질문부터 시작하면 이것의 대부분을 피할 수 있다. 기계가 내부 이름에 도달해야 한다면, 브라우저의 암호화 리졸버는 공개 절반에 대한 결정일 뿐이고, 사설 절반은 VPN이 밀어 넣은 것에 맡겨진다.