라우터 자체의 DNS가 VPN 터널을 우회하는 이유

클라이언트 조회는 터널을 따르지만 라우터 자체의 조회는 WAN으로 나가며, 한쪽을 규율하는 방화벽 규칙은 다른 쪽에 아무런 영향을 주지 않습니다. 이유는 버그가 아니라, 전달된 요청과 라우터가 스스로 만든 요청이 두 개의 별개 흐름이며 각각 구성의 다른 부분과 대조되기 때문입니다. 클라이언트 쪽 절반만 캡처하면 나머지 절반이 결코 쓰지 않는 경로에 대해 자신만만한 답을 얻게 됩니다. 해결책은 라우터의 리졸버를 의도적으로 지정한 뒤 두 경로를 따로 시험하는 것입니다.

패킷 캡처는 실제로 어느 흐름에 속하는가

한 번의 조회에는 두 번의 교환이 포함됩니다. LAN 클라이언트가 라우터의 리졸버로 질의를 보내고, 그것은 LAN 인터페이스에서 전달 트래픽으로 도착하므로 전달 패킷용으로 작성된 정책 경로나 NAT 규칙이 일치할 수 있습니다. 그다음 라우터는 캐시에서 응답하거나, 없으면 업스트림 서버로 자체 질의를 엽니다.

그 두 번째 질의는 라우터 자신이 출발지이자 목적지이며, 플랫폼은 다른 구성 블록에서 그 경로를 고릅니다. 두 교환은 같은 이름을 지니고 어느 쪽도 다른 쪽의 복사본이 아닙니다. 따라서 LAN 쪽에서 잡은 캡처는 클라이언트 패킷이 어디로 갔는지를 증명할 뿐 나가는 패킷에 대해서는 아무것도 말하지 않습니다.

실무 확인은 양쪽을 동시에 관찰하는 것입니다. 라우터에서 리졸버 소켓을 나열하고, 로컬로 질의하고, WAN 인터페이스를 캡처하십시오:

sockstat -4 -l | grep :53
dig +short @127.0.0.1 example.com
tcpdump -ni igb0 udp port 53

소켓 목록이 loopback 또는 LAN 주소에 묶인 리스너를 보여 준다면 라우터는 다른 호스트로 전달하지 않고 로컬에서 응답하는 것입니다. 그다음 캡처는 그 결과 생긴 업스트림 질의가 터널 인터페이스로 나가는지 WAN으로 나가는지를 보여 주며, 그것이 정책 경로 규칙이 결코 주지 못했을 답입니다.

정책 경로가 두 번째 질의를 결코 보지 못하는 이유

방화벽 규칙은 인터페이스, 출발지, 목적지, 포트에 대해 작성되며 장치를 통과하는 패킷에 대해 평가됩니다. 라우터가 만든 질의는 로컬 프로세스가 그것을 라우팅 테이블에 곧바로 넘기기 때문에 아무것도 통과하지 않습니다. 정책 라우팅과 NAT 따라서 전달 경로에만 적용되며, 규칙 집합이 완전해 보이면서도 라우터의 DNS를 터널 밖에 남기는 이유가 바로 여기에 있습니다.

이 구분은 기능이 아니라 패킷 경로에서 비롯되므로 펌웨어를 다시 쓰더라도 유지됩니다. 장치가 스스로 만드는 모든 것, 곧 리졸버 질의, 시간 동기화, 업데이트 확인, 패키지 미러 접근은 모두 로컬에서 생겨 같은 사각지대에 떨어집니다. 노트북에서 한 시험이 라우터에 대해 아무것도 증명하지 못하는 이유도 같습니다.

pfSense 리졸버가 자체 업스트림 경로를 정하는 곳

pfSense는 그 분리를 드러냅니다. 클라이언트 트래픽은 정책으로 VPN 게이트웨이를 지날 수 있지만, 방화벽 자체의 트래픽은 LAN 규칙이 아니라 리졸버의 외향 설정을 따릅니다. 웹 인터페이스에서 그 설정은 Services > DNS Resolver > Outgoing Network Interfaces 아래에 있으며, 그 값은 리졸버가 업스트림 질의에 사용할 수 있는 인터페이스 목록입니다.

거기서 터널 인터페이스를, 오직 그 인터페이스만 지명하는 것이 라우터 자체의 조회를 터널로 따르게 하는 원인입니다. 기본값으로 두면 리졸버는 라우팅 테이블에서 출구를 고르며, 이중 WAN이나 VPN 호스트에서는 그것이 흔히 WAN입니다.

다른 펌웨어는 같은 결정을 출발지 주소에 묶인 업스트림 서버 목록, 전달 전용 모드, 문서화된 경로 정책 같은 다른 이름으로 노출합니다. 찾아야 할 설정은 항상 로컬에서 생성된 질의의 출구나 출발지를 고르는 것입니다. 리졸버 구성 참조 는 pfSense의 그 옵션을 문서화하며 변경 전에 읽을 가치가 있습니다.

설정보다 먼저 장애 시 동작을 고르십시오

터널이 끊길 때는 아무것도 새지 않도록 업스트림 질의를 멈추는 것과 알려진 경로의 승인된 리졸버로 물러나는 두 가지 동작을 변호할 수 있습니다. 둘 다 정책이며 기본값으로 얻어지는 것은 아닙니다. 인터페이스 목록을 건드리기 전에 네트워크에 어느 쪽이 필요한지 정하십시오.

장애 시 닫는 편이 변호하기 쉽지만, 터널 중단을 라우터 뒤의 모든 장치에 대한 이름 해석 중단으로 바꿉니다. 대체는 사무실을 쓸 수 있게 유지하지만, 터널 밖 업스트림 교환이라는 대가를 치르며 그것은 우연이 아니라 의도적으로 수용 가능해야 합니다. VPN 밖의 리졸버 주소를 본 다음 사람은 메모가 달리 말하지 않는 한 그것을 유출로 읽을 것이므로 선택을 적어 두십시오. 그 메모가 문서화된 대체와 다음 분기 검토에서의 설명 없는 발견을 가르는 기준입니다.

두 사례가 결정을 어렵게 만듭니다. 사설 이름에는 터널이 닿을 수 있는 내부 리졸버가 필요할 수 있고, 자체 암호화 DNS를 가진 브라우저나 앱은 라우터를 완전히 우회할 수 있으므로 구성한 리졸버가 항상 특정 앱이 쓰는 것은 아닙니다.

두 경로를 시험하고 결과를 따로 보관하십시오

브라우저 기반 DNS 시험은 그 시험의 조건에서 그 브라우저가 어떤 리졸버를 썼는가라는 좁은 질문에 답합니다. 네트워크의 장치를 조사하지 않으며 라우터가 스스로 만든 질의를 볼 수도 없습니다. 그 출력은 감사가 아니라 하나의 데이터 점으로 다루십시오.

LAN 클라이언트에서 라우터에 먼저 공개 이름을, 다음으로 내부 영역만 응답해야 하는 사설 이름을 물으십시오. 두 번째 질의에서만 실패하면 터널이 아니라 이름 전달을 가리킵니다:

dig @192.168.1.1 example.com
dig @192.168.1.1 intranet.example.lan

그런 다음 터널을 내리고 두 질의를 반복하십시오. 거부된 응답은 리졸버가 장애 시 닫힌다는 뜻이고, 성공한 응답은 대체 리졸버와 그것이 쓴 경로를 가리킵니다. 그것을 적어 둔 메모와 같은 분에 WAN 인터페이스에서 잡은 캡처와 비교하십시오.

기록에서는 클라이언트와 라우터의 교환, 라우터와 업스트림의 교환, 그리고 두 번째를 결정한 구성으로 관찰을 따로 보관하십시오. 나중의 라우팅 변경은 그 두 번째 교환을 경고 없이 행사합니다. VPN 종단점이 아닌 곳에서 오는 응답은 그 자체로 유출이 아니며, 구성이 그 경로를 우연히 골랐을 때만 유출이 됩니다.