nslookup은 VPN에서 확인되는데 브라우저는 안 되는 이유

nslookup은 지정한 서버로 질의를 보내고 답을 출력하므로, 브라우저의 모든 탭이 실패하는 동안에도 성공할 수 있습니다. 브라우저는 운영체제에 확인을 요청하고, 운영체제는 인터페이스별 확인자, 이름 확인 정책 규칙, 어댑터의 네트워크 위치를 저울질합니다. 그다음 브라우저가 자체 암호화 DNS를 위에 더할 수 있습니다. 세 가지 다른 경로, 하나의 증상, 그리고 터널은 보통 고장 난 부분이 아닙니다.

아래 점검은 그 경로를 시스템에서 바깥으로 따라갑니다. 어느 경로가 응답했고 어느 것이 실패했는지 알기 전에는 VPN 프로필을 편집하지 마십시오.

세 가지 정책이 답을 결정한다

각 인터페이스는 자체 확인자 목록과 검색 접미사를 가집니다. VPN 어댑터는 서버를 추가하고 물리 어댑터는 자기 것을 유지하며, 시스템은 먼저 응답한 것을 택할 수 있으므로 아무도 선택하지 않았는데 조회가 터널 밖에서 처리될 수 있습니다. 이름 확인 정책 테이블 규칙은 선택한 도메인을 선택한 서버로 보낼 수 있으며, Windows에서 분할 DNS를 표현하는 일반적인 방법입니다. 그리고 VPN 클라이언트나 게이트웨이가 사설망 내부에만 존재하는 확인자 주소를 밀어 넣을 수 있습니다.

이 셋은 브라우저에서 보면 임의로 보이는 방식으로 상호작용합니다. 분할 터널을 통한 경로가 없는 사설 주소의 확인자가 밀려 들어오면 모든 조회가 멈췄다가 실패합니다. 내부 접미사를 덮고 꺼진 서버를 가리키는 정책 규칙은 경로 누락과 같은 눈에 보이는 오류를 냅니다. VPN 어댑터에서 빠진 검색 접미사는 짧은 이름을 잘못된 도메인에 대한 공개 질의로 바꿉니다. 각각 다른 수리가 필요합니다.

브라우저가 다른 질문을 하는 이유

nslookup은 자신이 고른 서버로 자체 질의를 내보내며 이름 공간 정책도 브라우저의 암호화 DNS 설정도 따르지 않습니다. 그래서 공개 확인자에 대한 수동 질의는 응답하는데 브라우저는 사이트가 없다고 보고합니다. 당신은 하나의 프로그램의 두 상태가 아니라 두 프로그램을 비교하고 있습니다.

주소 패밀리 선호는 지연을 설명할 뿐 실패를 설명하지 않습니다. IPv4만 전달하는 터널에서 먼저 IPv6 레코드를 묻는 브라우저는 물러나기 전에 시간 초과를 기다립니다. Firefox는 바로 이 때문에 선호 설정을 두었고, 그것을 끄는 것은 수리가 아니라 진단 단계입니다.

확인자 목록과 규칙을 읽는다

Windows에서는 이론을 세우기 전에 시스템이 가진 것을 출력하십시오. Get-DnsClientServerAddress는 인터페이스별 서버를 보여 주고, Get-DnsClientNrptRule은 이름 공간 규칙을 나열하며, Resolve-DnsName은 시스템 경로로 정확한 이름에 답합니다. 그 답을 VPN 서버에 주소로 직접 질의한 결과와 비교하십시오. Resolve-DnsName이 실패하고 직접 질의가 성공하면 확인자 목록이나 이름 공간 규칙이 용의자입니다.

이름 자체도 확인하십시오. 내부 짧은 이름은 VPN 어댑터만 제공하는 사설 접미사가 필요할 수 있고, 정규화된 이름은 잘 확인됩니다. 확인에 성공한 뒤의 인증서 경고는 다른 문제에 속합니다.

닿을 수 없는 밀어 넣은 확인자

게이트웨이나 클라이언트는 확인자 주소를 밀어 넣을 수 있고, 그 주소는 터널을 통해 닿을 수 있어야 합니다. 분할 터널에서는 확인자를 담은 사설 범위가 포함된 경로에 없을 수 있어, 결코 답을 받지 못하는 조회가 생깁니다. 경로가 있는지 확인한 다음, 그 주소를 터널을 통해 직접 질의하십시오. 공개 확인자가 여전히 응답하는데 브라우저에서 도메인 오류가 나는 배후의 실패가 이것입니다.

확인자에 닿을 수 없다면 수리는 경로나 포함된 서브넷이지 다른 DNS 서버가 아닙니다.

암호화 DNS는 경로 전체를 우회한다

DNS-over-HTTPS를 쓰는 브라우저는 선택한 공급자와의 HTTPS 연결로 스스로 이름을 확인합니다. 이것이 켜져 있으면 그 조회들에서는 시스템 확인자와 분할 DNS 규칙이 완전히 우회되어, 운영체제는 올바르게 확인하는데 브라우저에서는 내부 이름이 실패합니다. 반대도 일어납니다. 내부 이름이 절대 보아서는 안 될 공급자를 통해 브라우저에서 성공하는데, 이는 연결이 아니라 정책 문제입니다.

관리되는 장치에서 암호화 DNS를 허용할지 의식적으로 결정하고, 선택이 보이도록 브라우저의 관리 화면에서 구성하십시오. 개인의 선호에 맡기면 같은 VPN이 노트북마다 다르게 동작하는 함대가 됩니다.

실패에 맞는 수리

VPN이 자기 확인자를 밀어 넣는다면 터널이 그쪽으로 트래픽을 나르게 하고 같은 설정이 확인에 참여하는 어댑터에 보이게 하십시오. 연결 중에 로컬 사이트가 확인되지 않으면 확인자를 통째로 바꾸는 대신 명시적인 이름 공간 예외나 조건부 전달자를 추가하십시오. 브라우저의 암호화 DNS가 정책을 우회한다면 그것이 바꿔야 할 설정입니다. 내부 이름을 고치려고 공개 확인자를 추가하지 마십시오. 사설 질의가 새고 이름도 확인되지 않습니다.

그다음 조회와 연결을 분리하십시오. 올바른 주소로 확인되지만 연결을 거부하는 이름은 서비스, 방화벽, 인증서 문제이며 DNS 변경으로는 고쳐지지 않습니다.

어느 경로가 응답했고 어느 것이 실패했으며 무엇을 바꿨는지 기록하십시오. 그러면 같은 증상의 다음 보고는 반나절이 아니라 명령 하나로 끝납니다.