dnsmasq의 VPN 도메인은 영역 전송이 아닙니다

클라이언트의 dnsmasq 구성에서 회사 영역을 찾지만 없고, VPN이 도메인을 푸시하지 못했다고 결론 내립니다. 푸시된 것은 라우팅 힌트이지 영역이 아닙니다. 클라이언트는 도메인과 그에 응답해야 할 리졸버를 기록하고, 관리되는 backend는 이를 조건부 전달로 바꿉니다. 잘못된 곳을 보면 확신에 차 있고 완전히 틀린 진단이 나옵니다.

클라이언트가 수락한 것은 게이트웨이가 제안한 것과 다릅니다

게이트웨이는 리졸버, 도메인, 그리고 그 리졸버에 도달하는 데 필요한 경로를 제안할 수 있으며 클라이언트는 셋 다 또는 어느 것도 수락하지 않을 수 있습니다. 가져온 프로필, 도우미 스크립트 또는 푸시된 옵션을 무시하는 정책은 서버 쪽이 올바르게 보이는 동안 수락된 집합을 비워 둘 수 있습니다. 서버 구성이 아니라 클라이언트의 기록된 상태에서 시작하세요. 리졸버가 실제로 받는 것이 그 상태이기 때문입니다. 수락된 도메인이 없으면 그 이후는 아무것도 중요하지 않습니다. 캐시를 조사하기 전에 연결의 DNS 속성을 확인하세요.

그 차이가 도착하지 않은 도메인에 관한 대부분의 보고를 설명합니다. 제안되었지만 적용되지 않았습니다.

두 가지 도메인 항목

연결은 일반 검색 도메인과 경로 전용 도메인을 실을 수 있고, 두 번째 종류는 물결표로 시작합니다. 검색 도메인은 쿼리를 라우팅하고 짧은 이름이 확장되도록 허용합니다. 이는 워크스테이션에서는 편리하고 서버에서는 의외입니다. 경로 전용 도메인은 해당 접미사에 대한 쿼리가 짧은 이름 해석 방식을 바꾸지 않고 특정 서버로 가야 한다고 명시합니다. 같은 도메인을 두 방식으로 쓰는 것은 중복이 아닙니다. 두 항목은 서로 다른 일을 합니다.

사설 네임스페이스에는 보통 경로 전용 형식이 필요합니다. 회사 접미사를 회사 리졸버로 유지하고 나머지는 그대로 둡니다.

resolv.conf의 localhost는 버그가 아닙니다

로컬 캐싱 리졸버를 사용할 때 시스템 파일은 루프백 주소만 가리키고 다른 것은 가리키지 않습니다. 그 항목은 로컬 리스너를 식별하며 관리자가 넘겨준 업스트림 서버가 아닙니다. 회사 주소는 파일에 정당하게 없을 것입니다.

그 항목을 공용 리졸버로 바꾸는 것은 전형적인 잘못된 수정입니다. 공용 이름 해석을 복원하면서 같은 편집에서 조건부 정책을 버립니다.

backend를 혼동하지 마세요

관리되는 dnsmasq 인스턴스와 시스템 리졸버는 서로 다른 구성과 다른 상태 보기를 가진 다른 프로그램입니다. 하나에 대한 상태 명령은 다른 하나에 대해 유용한 것을 말하지 않습니다.

관리자가 어떤 backend를 사용하도록 구성되어 있는지 확인한 다음, 해당 backend의 생성된 구성을 읽으세요. 우연히 존재하는 배포 전체 파일이 아닙니다. 관리자는 자체 인스턴스 구성을 작성하고 그 인스턴스에 대한 사용자 지정 옵션을 지원하므로 관련 없는 전역 파일을 편집하면 아무것도 바뀌지 않고 효과 없는 변경처럼 보입니다. 포트 53에서 두 번째 데몬을 시작하는 것은 쓸모없는 것보다 나쁩니다. 이제 두 프로그램이 포트 소유권에 동의하지 않기 때문입니다. 먼저 소유자를 확립한 다음 그 소유자가 읽는 곳을 편집하세요.

네임스페이스를 테스트하세요, 답만이 아니라

애플리케이션의 일반 경로로 허용된 사설 이름 하나와 공용 제어 이름 하나를 쿼리하세요. 회사 서버에 대한 직접 쿼리는 레코드가 존재함을 증명하지만 클라이언트가 그 서버를 선택했음을 증명하지는 않습니다. 두 번째 쿼리가 정책을 테스트합니다.

그런 다음 재연결 후와 연결 해제 후에 반복하세요. 연결은 연결의 수명 주기를 따라야 하고, 사설 이름은 터널이 없을 때 확인이 중단되어야 하며 같은 접미사에 응답하는 공용 리졸버로 폴백해서는 안 됩니다. 폴백한다면 누출을 발견한 것이며 이는 깨진 조회와 다른 결함입니다. 어떤 backend가 실행되었는지, 어떤 도메인이 적용되었는지, 각 쿼리가 무엇을 반환했는지 기록하세요.