DNS를 자체 VPN 리졸버로만 통과시키기: 단계별 점검
브라우저에서 응답까지 이름 조회 하나를 따라갑니다. 리졸버가 어디에서 선택되고, 방화벽이 어디에서 강제하며, 포트 53 규칙이 결코 다루지 못하는 것이 무엇인지 확인하십시오.
이름을 입력한 순간부터 이름 조회 하나를 따라가 보십시오. 브라우저는 운영체제에 묻고, 운영체제는 정책이 고른 리졸버에 묻고, 질의는 어딘가의 인터페이스와 어딘가의 전송 방식을 거쳐 장치를 떠납니다. VPN 설계는 응답이 특정 리졸버에서 특정 경로로 와야 한다고 말합니다. 이 두 문장 사이의 틈이 바로 여러분이 설정하고 그다음 강제하는 부분입니다.
1단계: 리졸버와 경로에 이름 붙이기
방화벽을 건드리기 전에 세 가지를 적으십시오. 리졸버 주소, 기대하는 프로토콜과 포트, 그리고 질의가 나가야 할 인터페이스입니다. 이 목록이 없으면 규칙은 트래픽에 대한 추측일 뿐 결정의 집행이 아닙니다. VPN이 애플리케이션 데이터를 실어 나르는 동안 DNS가 별도의 방식을 따를 수 있고, 그것 자체가 잘못은 아닙니다. 아무도 클라이언트에 다른 말을 하지 않았을 때 벌어지는 일입니다.
경로를 분명히 이름 붙이는 것이 설계와 우연의 차이입니다. 나중에 시험할 거리도 줍니다. 모든 관측을 글로 적은 기대와 비교할 수 있기 때문입니다. 그 목록은 변경 티켓에 두고 누군가의 머릿속에 두지 마십시오.
2단계: 정책이 실제로 사는 곳에 두기
리졸버 선택은 클라이언트의 몫입니다. 운영체제의 네트워크 설정, VPN 클라이언트 자체 설정, 또는 관리되는 브라우저 정책입니다. 먼저 그곳에서 플랫폼이 지원하는 방식으로 설정하십시오. 방화벽은 한 번도 들은 적 없는 리졸버를 클라이언트가 고르도록 만들 수 없습니다. 분할 터널 클라이언트에서는 어떤 도메인이 내부 리졸버로 가는지 분명히 밝히십시오. 관리되는 조직에서는 브라우저 정책이 DoH를 다룰 유일한 지렛대인 경우가 많습니다. 브라우저는 시스템 설정과 무관하게 자체 암호화 리졸버를 고를 수 있기 때문입니다.
이 단계를 건너뛰고 곧장 방화벽으로 가면 올바른 리졸버를 허용하는 규칙과 그 리졸버를 결코 쓰지 않는 클라이언트를 함께 얻습니다. 규칙은 맞아 보이는데 리졸버 로그는 비어 있어, 문제를 찾을 때 혼란스러운 조합입니다. 선택을 먼저 설정하고 그다음 강제하십시오.
3단계: 경로를 좁게 강제하기
이제 허용된 경로에 대한 네트워크 권한을 추가하십시오. 리졸버 주소, 프로토콜과 포트, 그리고 나가야 할 인터페이스입니다. 모든 외부 DNS를 허용하는 대신 규칙을 그 리졸버로 한정하십시오. 아래 세 경로는 현대적인 클라이언트가 택할 수 있는 것이며, 포트 53 규칙이 덮는 것은 첫 번째뿐입니다.
| Path | Port | Who controls it |
|---|---|---|
| Classic DNS | UDP and TCP 53 | System resolver settings |
| DNS over TLS | TCP 853 | Resolver or stub configuration |
| DNS over HTTPS | TCP 443 | Browser or application policy |
DoH와 DoT를 차단하는 것은 정당합니다. 포트 53 규칙이 이미 그것들을 차단했다고 가정하는 것은 정당하지 않습니다. DoH를 쓰는 브라우저는 여러분의 규칙이 한 번도 설명한 적 없는 경로로 이름을 해석하고, 자체 리졸버를 품은 애플리케이션도 같은 일을 합니다. 허용하려는 모든 경로와 거부하려는 모든 경로를 적으십시오. 경로를 이름 붙이지 않은 규칙은 그 경로에 대해 결정하지 않은 것입니다.
4단계: 사설 이름과 공개 이름 따라가기
분할 DNS는 의도적으로 사설 이름 공간만 내부 리졸버로 보내고 공개 이름은 다른 곳으로 보냅니다. 그래서 설계에 리졸버가 둘 이상 있는 것은 유출이 아닙니다. 유출은 여러분의 리졸버로 가야 할 질의가 다른 곳에 도착하는 경우, 또는 의도한 경로에 닿지 못해 클라이언트가 조용히 되돌아가는 경우입니다. 찾아야 할 것은 이 두 가지입니다. 의도한 정책 아래에서 내부 이름과 공개 이름을 하나씩 따라가고 각각 어느 리졸버가 답했는지 기록하십시오.
여러분의 리졸버를 알려 주는 시험 사이트는 단서이지 증거가 아닙니다. 그곳에 도달한 질의만 보기 때문입니다. 질의가 실제로 어느 경로를 탔는지 알아야 할 때는 클라이언트 쪽에서 질의를 잡고, 그다음 두 관측을 비교하십시오. 둘이 어긋나면 아무도 기록하지 않은 되돌아감을 찾은 것입니다.
리졸버 주소가 맞는데 닿을 수 없다면 문제는 정책이 아니라 경로 제어나 필터링에 있습니다. 질의를 그 주소까지 추적하고, 리졸버 설정을 바꾸기 전에 응답이 기대한 인터페이스로 돌아오는지 확인하십시오.
5단계: 돌아올 길 남겨 두기
게이트웨이의 DNS 접근을 조이기 전에 이름 해석에 의존하지 않는 복구 수단을 확인하십시오. 리졸버가 깨지면 모든 수리 도구에 닿기 어려워지고, 변경을 되돌릴 도구도 마찬가지입니다. 새 정책이 증명될 때까지 로컬 콘솔이나 대역 밖 경로를 열어 두십시오. 정책이 재접속을 견딘 뒤에만 그것을 제거하십시오.
재접속이나 브라우저 정책 갱신 뒤에는 실제 상태를 다시 살피십시오. 둘 다 여러분의 규칙을 바꾸지 않고 리졸버를 바꿀 수 있습니다. 요구 사항은 질의에 대한 알려진 수신자와 보호된 경로이며, 스크린샷 한 장의 안심시키는 리졸버 표시가 아닙니다. RFC 8484 DNS over HTTPS 명세가 포트 규칙이 보지 못하는 암호화 경로의 참고 자료입니다.