VPN의 DNS가 정말 쓰이고 있을까? 포트 53을 잡아 확인하기

VPN 클라이언트가 DNS로 무엇을 하는지 대부분의 사람에게 물으면 리졸버를 설정하기 때문에 질의가 터널 안으로 흐른다고 답합니다. 푸시는 사실이지만 그것이 질의가 된다는 가정은 사실이 아닙니다. 푸시된 옵션과 회선 위의 패킷 사이에는 세 단계가 있고, 각 단계는 독립적으로 실패하며 그 모습은 모두 고장 난 DNS 서버처럼 보입니다. 그래서 누출 테스트 페이지와 정상 동작하는 브라우저가 같은 순간 같은 기계에 대해 서로 다른 말을 할 수 있습니다.

푸시된 옵션은 질의가 아니다

첫 단계는 서버가 설정을 제안하는 것으로, 예를 들어 터널 안의 리졸버를 지목하는 푸시된 DNS 옵션입니다. 두 번째 단계는 클라이언트가 그 설정을 인터페이스에 적용하는 것입니다. 세 번째 단계는 애플리케이션이 실제로 그 주소로 질의를 보내는 것입니다. 두 번째 단계에서 실패하면 리졸버 목록은 그대로인데 옵션만 연결 로그에 남고, 세 번째 단계에서 실패하면 완전히 올바른 리졸버 목록이 쓰이지 않은 채 남습니다.

대부분의 문제 해결은 이 셋을 하나로 뭉쳐 VPN 서버를 탓합니다, 그러나 보통 자기 몫을 했다고 증명할 수 있는 쪽은 그쪽뿐입니다. 대신 클라이언트의 실제 리졸버 상태를 읽고, 다음으로 질의 하나가 나가는 것을 관찰하세요. 이 두 관찰이 설정과 라우팅과 정책을 갈라내며, 드는 시간은 약 오 분입니다. 캡처는 보관하세요, 다음 엔지니어가 설명이 아니라 전과 후를 원하기 때문입니다.

인터페이스가 실제로 무엇을 들고 있는지 확인하기

Linux에서 시스템 리졸버는 평범한 파일, NetworkManager, systemd-resolved 중 하나일 수 있고, 그중 무엇이 그것을 소유하는지가 푸시된 서버가 어디에 내려앉는지를 결정합니다. 명령줄 OpenVPN 프로세스는 시스템 리졸버를 스스로 갱신하지 않으므로 문서화된 통합은 up/down 스크립트이거나 설정 적용 방법을 이미 아는 연결 관리자입니다. 둘을 함께 돌리는 것은 경쟁 상태를 만드는 효율적인 방법입니다.

resolvectl status
cat /etc/resolv.conf

Windows에서는 목록이 어댑터마다 따로이므로 터널 어댑터가 내부 서버를 들고 있는 동안 물리 어댑터가 로컬 서버를 유지하며 일부 이름에서는 이깁니다. 활성이라고 가정한 어댑터가 아니라 두 어댑터를 비교하세요.

질의 하나를 기계 밖까지 따라가기

두 인터페이스를 동시에 캡처한 다음 내부 리졸버를 써야 할 이름 하나를 해석하세요. 그 한 쌍의 캡처가 어떤 설정 출력도 답할 수 없는 것을 답합니다.

sudo tcpdump -ni tun0 port 53
sudo tcpdump -ni any port 53

물리 인터페이스에는 나타나고 터널에는 결코 나타나지 않는 질의는 클라이언트가 잘못된 리졸버를 골랐다는 뜻입니다. 둘 다에 나타나지 않는 질의는 애플리케이션이 캐시에서 답했거나, loopback에서 듣는 스텁에 물었거나, 트래픽이 포트 53으로 전혀 나타나지 않는 암호화된 리졸버를 썼다는 뜻입니다. 질의만이 아니라 응답도 캡처하세요, 터널을 통해 나간 질의에 공인 주소에서 온 응답이 붙는 것은 응답이 아예 오지 않는 것과 다른 고장입니다.

자기 DNS만 받아들이는 방화벽

상용 클라이언트는 때때로 자체 필터 체인을 설치합니다. 문서화된 한 패턴은 클라이언트 자신의 리졸버로 가는 DNS를 허용하고, non-loopback 인터페이스를 떠나려는 나머지 모든 UDP 포트 53 트래픽을 사용자가 일부러 다른 곳으로 라우팅한 것까지 포함해 버립니다. 데몬의 질의는 흔적 없이 사라지고, 그것은 필터가 아니라 리졸버 고장으로 읽힙니다.

sudo iptables -S OUTPUT
sudo iptables -S | grep -i -E 'dns|53'

버리는 규칙이 당신의 예외보다 먼저 평가되면 뒤에 추가한 규칙에는 결코 닿지 않으므로, 첫 번째 위치에 넣고 목적지를 정말 의도한 리졸버로 한정하세요.

sudo iptables -I OUTPUT 1 -p udp --dport 53 -d 172.20.8.1 -j ACCEPT

그 예외는 정책이 아니라 진단입니다. 벤더 규칙이 의도된 것이라면, 지원되는 수리는 클라이언트가 그 리졸버를 허용하도록 설정하고 그 결정을 기록하는 것입니다, 삽입한 규칙은 다음 클라이언트 업그레이드를 견디지 못하기 때문입니다.

누출 페이지가 보이는 것보다 적게 증명하는 이유

누출 테스트 페이지가 보여 주는 것은 테스트 운영자와 대화한 리졸버이지 당신의 기계가 참조한 리졸버가 아닙니다. 바깥으로 재귀하는 로컬 포워더는 자기 출구 주소를 그 페이지에 올리고, 암호화된 질의는 페이지를 완전히 비워 둘 수 있습니다. 두 결과 모두 잘못 읽히며, 하나는 누출로 다른 하나는 보장으로 읽히지만 어느 읽기도 관찰에서 나오지 않습니다.

변호할 수 있는 증거는 인터페이스와 목적지 주소, 응답, 타임스탬프가 담긴 캡처입니다. 터널이 올라오기 전에 하나, 올라온 뒤에 하나를 떠서 다음에 이름이 실패할 때 비교하세요. 그 한 쌍은 다음 사람에게 고장이 해석, 라우팅, 리졸버 자체의 접근 정책 중 어디였는지도 알려 줍니다.