분할 터널은 브라우저를 제외하지 DNS 질의를 제외하지 않는다

브라우저는 터널에서 제외되었고, 공용 IP 페이지는 그 트래픽이 집 연결로 나간다고 확인해 주는데도 내부 위키는 여전히 열리지 않는다. 이름 해석은 다른 곳으로 갔고, 그 다른 곳은 보통 VPN이 설정한 리졸버다. 데이터 경로와 리졸버 경로는 대부분의 분할 터널 설계에서 별개의 결정이다. 제외가 고장 났다고 부르기 전에 브라우저가 실제로 어느 쪽을 썼는지 확인하라.

데이터 경로와 리졸버 경로가 갈라진다

제외는 애플리케이션의 패킷을 터널에서 빼는 것이며, 데이터 경로에서의 라우팅과 방화벽 결정이다. 이름 해석은 다른 조회로, 프로세스가 시스템 리졸버에 묻고 그 리졸버가 어느 서버가 질문을 받을지 정한다.

둘 다 의도적이고 다를 수 있다. 업무 배포는 내부 이름이 다른 어디에서도 해석되지 않기 때문에 내부 네임스페이스를 기업 리졸버에 두면서 선택된 공용 브라우징을 터널 밖으로 보낼 수 있다. 혼란스러운 경우는 반대로, 공용 사이트가 실패하는데 브라우저가 배포가 기대한 리졸버에 한 번도 묻지 않았기 때문이다. 경로와 리졸버를 따로 기록하면 논쟁의 절반이 사라진다.

어느 프로세스가 질문하는지 찾아라

브라우저는 시스템 리졸버, 자체 암호화 DNS 서비스, 또는 운영체제가 네트워크마다 지정하는 리졸버를 쓸 수 있다. 첫째는 플랫폼 정책을 따르고, 둘째는 그 정책을 완전히 우회하며, 셋째는 질의가 어느 링크로 라우팅되는지에 달려 있다.

resolvectl status
resolvectl query intranet.example.net
dig +short +time=2 intranet.example.net @10.52.0.2
scutil --dns | head -n 40

시험하기 전에, 어느 링크가 DNS 서버를 갖는지, 어떤 네임스페이스를 주장하는지, 이름별 정책이 기본값을 덮어쓰는지 등 유효한 구성을 읽어라. 리눅스에서는 분할 DNS가 라우팅 도메인을 쓰고, 윈도우에서는 이름 해석 정책 표가 네임스페이스에 같은 역할을 한다. 둘 다 누출 시험 페이지에서는 보이지 않는다.

어느 리졸버가 어느 이름을 볼지 정하라

무엇이든 바꾸기 전에, 내부 이름은 기업 리졸버로, 공용 이름은 정책이 허용하는 서비스로, 예외는 담당자와 함께라는 의도한 매핑을 적어라. 그 목록이 없으면 누출 시험의 모든 라벨이 아무도 끝낼 수 없는 정책 논쟁이 된다.

그다음 브라우저 자체 설정을 확인하라. 브라우저의 암호화 DNS는 운영체제가 질의를 받기 전에 적용되기 때문이다. 캡티브 포털을 피하려고 이를 켠 사용자는 배포가 고른 리졸버를 조용히 덮어썼으며, 그것은 누출이 아니라 구성 결정이므로 차단 목록이 아니라 결정을 받을 자격이 있다.

시험 라벨 하나를 초록으로 만들려고 모든 DNS 필드를 다시 쓰지 마라. 라벨은 한 순간에 한 프로세스가 보낸 한 질의를 설명한다.

질의와 연결을 따로 검증하라

두 경로를 따로 시험하라. 연결 시험은 데이터 경로를 보여 주고, 리졸버 시험은 누가 이름을 받았는지 보여 준다.

curl -sS --max-time 8 https://api.ipify.org
resolvectl query example.net
dig +short example.net

리졸버에도 명시적으로 물어 실패를 경로가 아니라 서버로 돌려라. 그다음 브라우저를 다시 시작해 반복하는데, 애플리케이션이 부정 응답을 캐시하고 오래된 실패는 지속되는 것처럼 보이기 때문이다.

승인된 변경 뒤에 데이터 경로와 리졸버의 수신자를 두 개의 별도 줄로 날짜와 함께 기록하라. 다음 재연결에서 동작이 돌아오면 고쳐야 할 것은 그것을 제공하는 프로필이지 브라우저가 아니다.