VPN 호스트 이름은 실패하고 IP 주소는 작동할 때: 어디를 볼까

IP 접속은 되는데 이름이 실패한다면 원인은 경로가 아니라 접미사와 밀어 넣은 확인자에 있습니다. 주소, FQDN, 짧은 이름, 레거시 경로 순으로 살펴봅니다.

주소로 공유 폴더를 열 수 있는데 같은 폴더가 이름으로는 실패한다면, 터널이 패킷은 나르지만 이름 계층은 나르지 않는다는 뜻입니다. 이 한 가지 관찰만으로 방화벽과 경로 변경이라는 우회로를 줄일 수 있습니다. 이름에는 접미사, 확인자, 질의를 위한 경로가 필요하며, VPN 클라이언트는 그중 어느 것도 설치하지 않고 경로만 설치할 수 있습니다. 아래 네 가지 점검을 순서대로 하고 처음 깨지는 곳에서 멈추십시오.

이름은 주소가 묻지 않는 질문을 합니다

주소는 스택이 즉시 사용할 수 있는 목적지입니다. 짧은 이름은 접미사로 확장하고 확인자에게 보내고 그 영역을 아는 무언가가 답해야 하는 질문입니다. 경로만 설치하고 확인자를 설치하지 않는 터널은 첫째는 작동하게 두고 둘째는 깨진 채로 둡니다. 그래서 아주 다른 VPN 제품에서도 증상이 이렇게 일관되게 보입니다.

주소에서 바깥으로 작업하며, 먼저 전체 이름, 다음으로 맨 호스트 이름, 그리고 셋 중 무엇이 작동하는지 적어 두십시오. 패턴을 보면 설정 화면을 하나 열기 전에 어느 계층을 살펴야 하는지 알 수 있습니다. FQDN이 해석되는데 경로를 추측하는 것은 헛수고입니다.

터널이 실제로 설치한 확인자를 읽으십시오

운영체제에 내부 영역의 질의를 어느 확인자가 처리하는지 묻되, VPN 클라이언트 인터페이스가 광고하는 확인자를 묻는 것이 아닙니다. 내부 영역 없이 공용 확인자를 밀어 넣는 서버는 정확히 이 실패를 만들며, 그것은 라우팅 결함이 아니라 설정 오류입니다.

resolvectl status
nslookup fileserver.corp.example
nslookup fileserver

도메인에 가입된 Windows 클라이언트에서는 이름 공간 라우팅 정책이 어느 질의가 어느 확인자로 가는지 결정하고, VPN 어댑터 자체의 DNS 설정은 어댑터 세부 정보에 나타납니다. 캐시된 정책은 그것을 설치한 연결보다 오래 살 수 있으므로 프로필이 아니라 유효한 정책을 읽으십시오. 확인자가 전체 이름에는 답하고 짧은 이름에는 답하지 않는다면 문제는 이미 접미사 목록으로 옮겨 간 것입니다.

Get-DnsClientNrptPolicy
ipconfig /all

내부 영역이 올바른 서버를 통해 해석되면 멈추십시오. 확인자는 당신의 문제가 아닙니다.

접미사는 실패하는 짧은 이름을 설명합니다

단일 레이블 이름은 질의를 보내기 전에 연결의 접미사 목록으로 확장됩니다. VPN이 내부 접미사를 전달하지 않으면 fileserver는 결코 fileserver.corp.example이 되지 않고, 질의는 어떤 공용 확인자도 모르는 이름으로 나갑니다. 접미사를 밀어 넣거나 전체 이름을 입력하면 서버에서 아무것도 바꾸지 않고 가설을 시험할 수 있습니다.

nslookup fileserver.corp.example
ping -a 192.168.50.20

Linux에서는 확인자 서비스가 DNS 서버를 링크와 라우팅 도메인 집합에 묶으므로, 터널의 링크와 연결되지 않은 밀어 넣은 서버는 없는 것처럼 동작합니다. 로컬 확인자만 가리킬 수 있는 stub 파일이 아니라 링크별 상태를 확인하십시오. 같은 분열이 반대 방향에서도 나타나, 존재하지만 터널 인터페이스에 적용되지 않은 검색 도메인은 무작위로 보이는 짧은 이름 실패를 만듭니다.

접미사를 더하면 해결된다면, 남은 일은 모든 사용자에게 입력을 요구하는 대신 그 접미사를 VPN 프로필을 통해 전달하는 것입니다.

NetBIOS와 WINS는 다른 메커니즘

레거시 SMB는 여전히 NetBIOS 이름 서비스로 맨 이름을 찾을 수 있으며, 이것은 브로드캐스트나 WINS 서버를 통해 응답합니다. 브로드캐스트는 하나의 브로드캐스트 도메인 안에 머물고 첫 라우터에서 멈추므로 터널을 넘을 수 없고, WINS가 작동하는 것은 클라이언트가 등록하고 질의할 유니캐스트 주소를 갖기 때문입니다. 그래서 IP만 나르는 VPN도 WINS가 설정되어 도달 가능하면 레거시 이름을 지원할 수 있습니다.

nbtstat -n
nbtstat -R

현대 SMB에서는 DNS와 전체 이름에 의존하고 레거시 경로는 은퇴시키십시오. 정말 레거시라면 WINS를 제공하거나 응용 프로그램을 교체하며, 중간 지대란 결코 비지 않는 지원 대기열입니다.

어느 계층이 실패했는지 말할 수 있을 때 이 여정은 끝납니다: 확인자, 접미사, 레거시 탐색 중 하나입니다. 다음 사람이 같은 증상에서 시작하므로 응답한 확인자와 작동한 이름 형태를 기록하십시오.

관련 글