Windows에서 OpenConnect DNS 설정을 실제로 적용하는 것은 무엇인가
Windows는 리졸버 상태를 세 곳에 보관합니다. 어댑터 DNS를 직접 편집하거나 네임스페이스 규칙을 추가하기 전에 연결을 소유한 도우미를 찾으세요.
터널을 올리는 것은 그 DNS 값을 설치하는 것과 같지 않습니다. OpenConnect가 협상하고, Windows 쪽 도우미가 적용합니다. 이 두 단계 사이의 간극이 이 클라이언트에서 대부분의 사설 이름 실패를 설명하며, 도우미는 거의 결코 Windows VPN 설정 페이지가 아닙니다.
게이트웨이가 제안한 것과 Windows가 설치한 것을 분리하세요
클라이언트는 연결 데이터를 스크립트 인터페이스에 넘기고, Unix와 Windows 변형은 별도 프로그램입니다. Windows에서 구현은 보통 JavaScript 도우미로, 내부 DNS 서버와 내부 도메인 같은 변수를 읽은 뒤 어떤 어댑터든 건드립니다. 터널 자체에서는 아무것도 리졸버 상태를 쓰지 않습니다.
이 분리가 중요한 이유는 값이 협상에는 존재하면서 어댑터에는 끝내 도달하지 않을 수 있기 때문입니다. 빠져 있거나, 중간에 실패하거나, GUI 래퍼 안에 묶인 오래된 사본인 도우미는 Windows를 있던 그대로 둡니다. 세션은 연결된 것처럼 보이고, 사설 이름은 여전히 로컬 공급자를 통해 해석되며, 클라이언트 창에서는 차이를 암시하는 것이 없습니다. 어느 단계가 끊겼는지 알 수 있는 유일하게 신뢰할 만한 방법은 도우미 자체의 출력을 읽는 것입니다.
| Stage | What exists there | Where you see it |
|---|---|---|
| Negotiated | Internal DNS address and domain pushed by the gateway | Client log or helper input |
| Installed | Adapter DNS entry, connection suffix, or namespace rule | Adapter and policy queries |
| Selected | Resolver Windows uses for one specific query | The failing application |
GUI 래퍼는 클라이언트와 도우미의 자체 사본을 함께 제공할 수 있으므로 디스크의 다른 곳에 있는 두 번째 openconnect.exe는 아무것도 증명하지 못합니다. 구성을 판단하기 전에 세션을 시작한 실행 파일을 찾으세요.
리졸버 상태를 바꾸지 않고 읽으세요
세 가지 읽기 전용 쿼리가 흔한 혼란을 다루며, 각각 다른 질문에 답합니다:
Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix
Get-DnsClientNrptPolicy -Effective어댑터 수준 서버가 대부분 사람이 VPN DNS라고 부르는 것입니다. 연결별 접미사는 짧은 이름이 확장될지 여부를 결정합니다. 네임스페이스 정책 목록은 어댑터 순서와 무관하게 일치하는 이름에 적용되며, 도우미가 만들 의도가 없었다면 그곳의 빈 결과는 결함이 아닙니다. 편집 전에 셋 다 읽는 것이 증상만 다른 곳으로 옮기는 수정을 막습니다.
정규화된 이름부터 시작하세요. FQDN이 해석되고 짧은 이름이 해석되지 않는다면, 간극은 서버 주소가 아니라 접미사나 검색 목록입니다.
두 번째 단계로 이미 설치된 아무 리졸버 도구로 대상 서버에 직접 질의하세요. 직접 응답은 서버에 도달할 수 있고 해당 영역에 권한이 있음을 증명합니다. 애플리케이션이 기본적으로 어느 서버에 묻는지는 아무것도 증명하지 못합니다.
연결을 소유한 구성 요소를 지목하세요
두 가지 배치가 흔합니다. 터미널에서 시작한 클라이언트는 스크립트 경로를 명시적으로 넘기므로 실행된 명령에서 소유자가 보입니다. 패키지된 애플리케이션은 대신 클라이언트를 시작하고 도우미를 자체 디렉터리에 보관하므로, 언제 바뀔지는 공급업체가 결정합니다.
무엇이든 교체하기 전에 설치 간 도우미 버전을 비교하세요. 파일 이름이 익숙해 보인다는 이유로 미러에서 받은 도우미를 상승된 권한으로 실행하면 DNS 간극이 보안 사고가 됩니다.
소유자를 알면 수리 대상이 분명해집니다. 실행기에서 지원되는 스크립트 경로, 패키지 업데이트, 또는 게이트웨이의 수정된 프로필이며, 어느 것도 어댑터 속성을 직접 편집할 필요가 없습니다.
고칠 것은 어댑터가 아니라 소유자입니다
어댑터에 직접 설정한 DNS는 연결 해제 후에도 남는 경우가 많아, 작동하는 것처럼 보이다가 다음 네트워크에서 문제를 일으킵니다. 모든 인터페이스에 고정된 공용 리졸버는 사설 네임스페이스 문제를 해결하지 않고 숨깁니다. 도우미가 DNS 값을 받은 적이 없다면 게이트웨이 프로필이 살펴볼 곳입니다. 값을 받았는데도 어댑터가 여전히 이전 서버를 보여 준다면, 도우미가 연결 중에 실패한 것이며 클라이언트 로그는 보통 터널 설정 줄 근처에 그것을 기록합니다.
지원되는 경로로 상태를 다시 만든 뒤 연결하고, 사설 FQDN을 해석하고, 서비스를 열고, 연결을 끊고, 어댑터가 이전 서버로 돌아왔는지 확인하는 전체 주기를 검증하세요.
실제로 실패하는 애플리케이션을 확인하세요
자체 암호화 DNS 설정이 있는 브라우저는 위의 모든 것을 무시하고 공용 리졸버에서 계속 응답합니다. 터널이 올라오기 전의 부정 응답을 캐시한 애플리케이션도 같은 방식으로 동작합니다. 리졸버 주소를 다시 바꾸기 전에 같은 머신의 단순 시스템 쿼리와 비교하세요.
시스템 쿼리가 맞고 애플리케이션이 틀리다면, 남은 결함은 그 애플리케이션의 DNS 구성 안에 있으며 VPN 경로에 있지 않습니다.