Windows에서 OpenVPN 연결 후 DNS가 작동을 멈추는 이유

사무실 확인자에 대한 ping은 "OpenVPN" 연결 후에도 응답이 오지만, 이름 조회는 모두 실패한다. 주소는 닿는데 포트는 닿지 않으며, Windows가 어댑터별로 DNS를 필터링할 수 있다는 점을 알면 이 조합은 납득이 간다. 프로필에 block-outside-dns가 있다면 그 필터가 첫 용의자이고 라우팅 테이블은 볼 곳이 아니다. 아래 두 테스트는 몇 초 만에 계층을 분리한다.

닿는 주소, 죽은 포트

성공한 ping은 호스트가 살아 있고 경로가 있음을 증명한다. 포트 53에 닿을 권한에 대해서는 아무 말도 하지 않는다. 문제의 필터가 다른 계층에서 동작하고 어댑터에 묶여 있기 때문에, 같은 머신이 ICMP에는 응답하면서 같은 주소로 보낸 모든 질의를 거부할 수 있다. 어떤 설정이든 바꾸기 전에 두 테스트를 같은 세션에서 실행하라.

ping <resolver-ip>
nslookup <name> <resolver-ip>

그 짝이 곧 진단이다. 서브넷으로 가는 일반 트래픽은 계속 흐르는데 이름 해석만 죽으니, 사람들은 서버가 고장 났거나 DNS가 한 번도 전달되지 않았다고 결론짓는다. 두 설명 모두 추적 비용이 크고, 증거는 더 좁은 곳을 가리킨다. 설정을 건드리기 전에 그 짝을 확인하라.

이 옵션은 필터링 플랫폼의 규칙이다

OpenVPN 참조 문서는 block-outside-dns를 Windows Filtering Platform의 제한으로 설명한다. 터널 밖 어댑터에서 응용 프로그램이 DNS에 닿지 못하게 하는 제한이며 TCP와 UDP 포트 53을 포함한다. 필터는 일반 방화벽 규칙 목록이 아니라 WFP 안에 살기 때문에, 다른 곳에 허용 규칙을 추가해도 결과가 반드시 바뀌지는 않는다. 그래서 DNS를 허용하라는 흔한 조언이 계속 실패한다.

이 설정은 가져온 프로필에서도 서버에서도 올 수 있고, 마지막으로 편집한 파일은 "클라이언트가 무엇을 읽어 들였는지의 증거가 아니다". 유효한 구성과 연결 로그를 함께 읽어라. 이 옵션은 Windows 전용이기도 해서, 이식 가능한 것으로 다루면 적용되지 않는 조언이 나온다.

규칙을 더 넣는 대신 그 제한을 소유한 클라이언트 구성 요소를 찾아라. 소유자야말로 실제로 그것을 제거할 수 있는 대상이다.

필터는 확인자가 아니다

터널 밖 트래픽을 막는다고 그 안에 동작하는 확인자가 설치되지는 않는다. 이 옵션은 경로 하나를 없애고 터널의 DNS 구성을 프로필을 만든 사람에게 맡긴다. 확인자를 한 번도 보낸 적 없는 프로필에는 이제 하나도 없다.

세 가지 점검을 순서대로 하라. 첫째, 실패하는 응용 프로그램이 실제로 어느 확인자를 쓰는지. 둘째, 클라이언트가 VPN DNS 설정을 적용했는지. 셋째, 어느 인터페이스가 그 확인자로 트래픽을 실어 나르는지.

1. 사용 중인 확인자: Resolve-DnsName -Server <resolver-ip> <name>을 ipconfig /all가 나열하는 DNS 서버와 비교하라.
2. VPN DNS 적용됨: 같은 ipconfig /all 출력에서 터널 어댑터의 DNS 항목을 살펴라.
3. 사용된 인터페이스: Find-NetRoute -RemoteIPAddress <resolver-ip>가 해당 목적지의 나가는 인터페이스를 알려 준다.

이 정책 아래에서 LAN 확인자는 설계상 닿을 수 없게 된다. 다른 LAN 트래픽이 동작하는 중에도 마찬가지이며, 그것이 옵션이 제 일을 하는 모습이다. 설계에 VPN DNS가 필요하면 확인자 등록과 터널 경로를 고치고, 로컬 예외를 둔 split DNS가 필요하면 구성 소유자가 그 예외를 지원되는 방식으로 표현해야 한다.

이 옵션이 다루지 않는 것

포트 53이 이름 해석의 전부는 아니다. DNS over HTTPS와 DNS over TLS는 다른 전송을 쓰고, 일부 응용 프로그램은 시스템 설정과 무관하게 자체 확인자 로직을 돌린다. 그래서 브라우저는 이름을 해석하는데 명령줄은 못 하는 경우가 있다.

그 차이는 모순이 아니라 진단으로 다뤄라. 시스템 확인자가 고장 났다고 판단하기 전에 둘을 비교하라.

적을 때는 결론을 좁게 유지하라. 이 옵션은 한 플랫폼에서 한 전송을 제한할 뿐이고, 해석 경로의 나머지는 소유자가 따로 있는 별개의 설계 문제다.

연결 해제 전후의 상태를 확인하라

연결 중에 같은 조회를 실행하고, 소유 클라이언트가 끊긴 뒤에 다시 실행하라. 터널이 올라와 있는 동안 첫 번째는 외부 확인자에 대해 실패해야 하고, 필터가 제거되면 두 번째는 성공해야 한다. 끊긴 뒤에도 실패한다면 필터가 정리되지 않은 것이다.

ipconfig /displaydns
nslookup <name> <resolver-ip>

클라이언트 서비스나 머신을 다시 시작하면 보통 오래된 필터가 지워지지만, 이는 진단을 확인해 주는 것일 뿐 영구적인 수정을 증명하지는 않는다. 본 것을 기록하라. 연결 해제를 견디는 필터는 다시 같은 일을 하고, 그 기록이 버그 보고를 정당화한다.

이런 점검을 거친 뒤에야 확인자를 바꾸거나 방화벽 정책을 다시 세우는 것이 의미가 있다. 둘 다 증거가 뒷받침하는 것보다 큰 변경이다.