분할 DNS와 VPN: 도메인 규칙은 IP 경로가 아닙니다

노트북은 터널을 통해 intranet.corp를 확인하는 반면 gitlab.com은 계속 ISP 확인자로 향하며, 이것은 설계대로 동작하는 구성입니다. 두 개의 별개 결정이 이를 만들었습니다. 이름 일치 규칙이 확인자를 골랐고, 경로가 응답을 되가져왔습니다. 어느 하나만 깨져도 브라우저는 밖에서 보면 같은 실패를 보여 줍니다. 분할 DNS 관련 보고서 대부분은 첫 번째에 대한 증거를 인용하면서 두 번째 실패를 설명합니다.

두 반쪽은 서로 다른 곳에 있고 보통 서로 다른 사람이 편집합니다. 하나는 VPN 프로필에 붙은 DNS 정책이고, 다른 하나는 터널이 설치하거나 보류하는 경로입니다. 어느 반쪽이 실제로 움직였는지 아무도 확정하지 않으면 디버깅은 멈춥니다.

한 요청에 숨은 두 가지 결정

이름 반쪽은 경로가 아니라 정책 객체입니다. Windows에서는 VPN 프로필의 이름 확인 정책이고, Apple 플랫폼에서는 DNS 설정 객체의 일치 도메인 집합이며, Linux에서는 라우팅 도메인, 분할 확인자 행 또는 이름 서비스 전환 순서입니다. 경로 반쪽은 터널이나 수작업으로 설치되는 평범한 라우팅이며, 호스트 이름이 무엇인지 전혀 모릅니다. 접미사를 허용하는 프로필은 누가 응답할지만 결정하고, 응답을 도달 가능하게 만들지는 않습니다.

빠른 증상 테스트가 둘을 분리합니다. 이름을 주소로 바꿔 보십시오. 주소가 동작하면 경로는 정상이고 규칙이 틀렸습니다. 주소도 실패하면 규칙은 맞고 경로가 빠졌을 수 있습니다.

각 플랫폼이 같은 이름 규칙을 표현하는 방식

의도는 동일하고 필드 이름은 그렇지 않습니다. 한 클라이언트에서 다른 클라이언트로 복사한 예제는 깔끔하게 파싱되지만 절대 일치하지 않습니다. 세 가지 형태는 다음과 같습니다.

일치 또는 라우팅 도메인은 접미사 테스트이므로 intranet.corp는 git.intranet.corp를 포함하고 corp.intranet는 포함하지 않으며, 이를 뒤집는 것이 전체 설정에서 가장 흔한 실수입니다. Windows는 매핑을 프로필에 붙은 이름 확인 정책으로 가지며, 인터페이스가 이미 가지고 있던 접미사 목록에 대한 자체 우선순위를 둡니다. Apple 플랫폼은 일치 도메인을 네트워크 확장의 DNS 설정 객체에 붙이고, 시스템은 이를 범위가 지정된 확인자마다 적용합니다. 이 형태 중 어느 것도 경로가 아니며, 도달할 수 없는 주소를 도달 가능하게 만들 수 없습니다. Windows 이름 확인 정책 참고 자료는 해당 플랫폼의 필드 이름과 우선순위 규칙을 나열하며, Apple이나 systemd 문서가 쓰는 규칙과 다릅니다.

올바른 응답에도 경로가 필요합니다

확인자의 응답은 주소일 뿐입니다. 애플리케이션은 여전히 그곳에 도달해야 합니다. 분할 터널 설계는 흔히 10.20.0.0/16을 밀어 넣고 기본 경로를 보류하므로, 내부 이름은 확인되지만 연결이 그다음 멈춥니다. 반대 경우도 흔합니다. 경로는 있고 공용 확인자가 사설 이름에 NXDOMAIN으로 응답하며, 실패는 라우팅 문제로 기록됩니다. 경로를 먼저 시험하면 절대 확인되지 않을 이름의 경로를 들여다보게 됩니다.

어느 반쪽도 덮지 않는 세 번째 관문도 있습니다. 게이트웨이의 ACL, 방화벽 규칙 또는 클라이언트 측 정책은 두 결정이 모두 옳은 뒤에도 연결을 떨어뜨릴 수 있습니다. 이름이 확인되고 경로가 있는데도 연결이 계속 시간 초과되면 DNS 시험을 멈추십시오.

이름과 경로를 고정된 순서로 시험하기

순서를 정하고 지키십시오. 그러지 않으면 가장 최근에 실패한 단계를 뒤쫓게 됩니다. 문서화된 전체 내부 이름을 확인하고, 응답이 경로 표가 운반할 수 있는 주소인지 확인한 뒤, 공용 이름으로 반복하여 터널이 모든 것을 잡지는 않았음을 증명하고, systemd 호스트에서는 질의와 확인자의 라우팅 도메인이 명령 하나 차이임을 기억하십시오.

resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10

Windows 클라이언트는 같은 두 질문을 다른 cmdlet으로 하며, 두 번째는 시스템이 실제로 사용할 인터페이스를 보고합니다.

Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10

조회가 주소를 반환하고 경로 점검이 물리 인터페이스를 지목하면 이름 규칙은 동작했고 경로는 그렇지 않았습니다. 짧은 이름이 실패하는데 전체 이름이 확인되면 접미사 목록이 틀린 것이지 확인자가 아닙니다.

비교가 보통 어긋나는 곳

첫 번째 실수는 무관한 공용 확인자에게 사설 이름을 묻고 그 거부를 VPN에 대한 증거로 읽는 것입니다. 두 번째는 동작하는 공용 조회가 터널의 확인자 경로를 증명한다고 가정하는 것입니다. 세 번째는 분할 터널링과 분할 DNS를 하나의 설계 결정으로 취급하는 것인데, 배포는 한쪽에서 옳고 다른 쪽에서 깨질 수 있습니다. 각 실수는 비난받는 부분을 한 번도 시험하지 않은 테스트에서 확신에 찬 결론을 만들어 냅니다.

자체 보안 DNS를 가진 브라우저도 시스템 규칙을 우회할 수 있으므로, 한 브라우저가 실패하고 다른 브라우저가 성공하는 것은 모순이 아닙니다. 응답한 확인자를 비교하십시오. 불평한 브라우저가 아니라.

두 반쪽이 모두 보이면 남는 질문은 기술이 아니라 정책 질문입니다. 어떤 이름 공간이 조직에 속하고, 각 응답의 소유자는 누구이며, 그중 무엇이 기기를 떠나야 하는지를 프로필 옆에 적어 두십시오. 다음에 규칙을 만질 사람이 그것을 필요로 합니다.