스플릿 터널은 앱에 도달하지만 그 DNS 서버에는 도달하지 못합니다

앱의 서브넷을 라우팅하는 것은 스플릿 터널의 뻔한 부분이며 전부가 아닙니다. 리졸버는 흔히 자신이 서비스하는 앱과 다른 주소에 있으므로, 작동하는 터널도 조회를 그 밖에 남겨둘 수 있습니다. 10.80.0.0/16만 전달하는 프로필은 10.90.0.53에 대한 쿼리를 로컬 인터페이스로 내보내며, 그곳에는 프라이빗 영역이 없습니다. 리졸버 경로를 추가한 다음 문제의 나머지 절반을 보세요: 클라이언트가 실제로 어떤 서버를 선택하는지.

신화: 하나의 경로가 서비스 전체를 덮는다

스플릿 터널은 연결을 통과하는 목적지의 목록이며 서비스에 대한 설명이 아닙니다. 앱의 서브넷과 리졸버 주소는 두 개의 목적지이고, 프로필은 하나를 다른 하나 없이 전달할 수 있습니다. 그렇게 되면 앱은 주소로는 도달할 수 있지만 이름은 실패하며, 이는 라우팅 공백보다 DNS 결함처럼 보입니다.

리졸버 주변의 서브넷도 자동으로 덮이지 않습니다. 단일 주소에 대한 호스트 경로는 그 리졸버에 충분하며 이웃을 열지 않습니다. 이것이 호스트 경로의 요점이며, 설계상 좁고, 다음 서비스가 같은 서브넷에 나타나면 잊히기 쉽습니다.

조회가 작동하려면 클라이언트가 리졸버 주소를 터널을 통해 라우팅하고, 게이트웨이가 그 요청을 받아 전달하며, 리졸버가 받은 출처를 수용하는 세 가지가 성립해야 합니다. 응답도 합의된 경로로 돌아와야 합니다. 하나라도 빠지면 증상은 동일하므로 구성을 건드리기 전에 주소 표를 적어 두는 것이 좋습니다.

프로필이 전달해야 할 주소를 결정하세요

목적지는 앱 네트워크, 리졸버 주소, 그리고 터널 자체를 종료하는 공개 엔드포인트 순서로 나열하세요. 세 번째는 외부 연결에 터널보다 먼저 존재하는 경로가 필요하므로 절대 터널 안으로 라우팅해서는 안 됩니다.

구현이 UDP와 함께 TCP도 지원할 것으로 기대되고 차단된 TCP 경로가 깔끔한 실패가 아니라 느리고 부분적인 실패를 만들기 때문에, DNS에는 UDP와 TCP를 모두 포함하세요. 프라이빗 영역이 IPv6으로도 제공된다면 동등한 호스트 예외는 IPv6 주소와 접두사를 사용하며 별도 항목입니다.

무언가를 추가하기 전에 프로필이 이미 무엇을 덮는지 기록하세요. 중복 경로는 무해하지만, 예상치 못한 기존 경로는 프로필이 받은 주소 계획과 다른 계획을 위해 설계되었다는 것을 알려줍니다.

연결 소유자를 통해 호스트 경로를 추가하세요

로컬에서 관리되는 네이티브 Windows 프로필에서 경로는 머신의 전역 라우팅 테이블이 아니라 연결에 속합니다. 먼저 추가를 미리 보고, 그 다음 프로필이 사용하는 것과 같은 범위로 적용하세요.

Add-VpnConnectionRoute -ConnectionName 'Office VPN' -DestinationPrefix '10.90.0.53/32' -WhatIf
Get-VpnConnection -Name 'Office VPN' | Select-Object -ExpandProperty Routes

첫 번째 명령은 아무것도 설치하지 않고 변경을 미리 보여 주며, 두 번째는 프로필이 현재 전달하는 경로를 나열합니다. Microsoft의 Add-VpnConnectionRoute 참조 문서는 사용자별 범위와 모든 사용자 범위를 설명하며, 모든 사용자 프로필에는 고유한 범위 매개변수가 필요하고, 모든 사용자 프로필에 대한 사용자별 명령은 실패하거나 잘못된 위치에 놓입니다.

프로필이 관리되거나 공급업체 클라이언트에서 온 경우 변경은 그 소유자에게 속합니다. 영구 시스템 경로를 연결 정책 위에 쌓는 것은 정책이 다시 적용되어 경로가 사라질 때까지 작동하며, 이는 보통 테스트 중이 아니라 지원 통화 중에 발생합니다. 그 실패는 조용해서 경로가 사라지고 이름이 더 이상 해석되지 않으며, 아무도 두 사건을 연결하지 않습니다. 변경을 소유자 자신의 기록에 넣어 다음 재적용이 지우는 대신 전달하게 하세요.

적용한 뒤에는 경로가 효력을 냈다고 가정하지 말고 프로필을 다시 연결하세요. 활성 연결에서 경로 변경이 항상 반영되는 것은 아니며, 다시 연결하면 사용자가 실제로 겪을 상태도 재현됩니다.

클라이언트가 실제로 어떤 리졸버를 사용했는지 확인하세요

경로는 리졸버로 주소 지정된 패킷을 제어합니다. 어떤 이름을 그곳으로 보내야 하는지는 결정하지 않으며, 그 선택은 별도의 메커니즘입니다. Windows에서는 유효한 네임스페이스 규칙이 도메인별로 리졸버를 선택할 수 있고, 프로필의 DNS 설정은 기본값을 제공합니다. 이 두 계층은 아무 오류도 내지 않고 어긋날 수 있으므로 직접 쿼리는 증거의 절반에 불과합니다.

Get-DnsClientNrptPolicy
Resolve-DnsName app.svc.example -Server 10.90.0.53 -Type A

첫 번째 명령은 시행 중인 네임스페이스 정책을 출력하고, 두 번째는 프라이빗 리졸버에 앱의 이름을 직접 묻습니다. 직접 응답은 경로와 리졸버가 작동함을 증명하지만, 앱 자체의 조회가 그 서버를 선택했음을 증명하지는 않습니다. 같은 이름의 일반 조회와 앱이 받는 응답과 비교하세요.

사용자가 입력한 이름에 대해 시스템 리졸버를 완전히 우회할 수 있는 캐시와 브라우저 수준의 보안 DNS를 고려하세요. 검색 접미사도 짧은 이름을 정규화된 이름으로 확장할 뿐이며 어느 서버가 응답하는지와는 무관한 또 다른 잘못된 단서입니다.

마지막으로 다시 연결하고 일반 조회를 반복한 다음, 일반 브라우징이 여전히 승인된 정책을 따르는지 확인하세요. 관련 없는 이름이 해석되도록 프라이빗 리졸버를 공용 리졸버로 바꾸는 것은 수정이 아니며, 프라이빗 쿼리를 원래 가면 안 되는 곳으로 조용히 옮깁니다.