VPN에서 LAN 호스트 이름이 실패하는 이유: 접미사, mDNS, 아니면 영역?

장치 옆에서는 프린터가 짧은 이름에 응답하고 파일 서버가 별명에 응답합니다. 터널을 통해서는 주소는 여전히 작동하는데 두 이름 모두 시간 초과됩니다. 경로는 제 역할을 하고 있으며, 그 짧은 이름을 작동하게 만든 이름 경로가 터널을 건너간 적이 없습니다. 이 동작을 만드는 메커니즘은 세 가지이며 각각 다른 수정이 필요합니다.

먼저 이름이 어떤 메커니즘에 의존하는지 파악하십시오.

다르게 동작하는 세 가지 이름

fileserver 같은 단일 레이블 이름은 보통 리졸버가 붙이는 DNS 검색 접미사에 의존합니다. 그 접미사는 흔히 로컬 DHCP 임대와 함께 오므로, VPN에서 주소를 받는 원격 클라이언트가 그것을 알 이유가 없습니다. 경로를 추가해도 접미사는 전달되지 않습니다. 짧은 이름은 뒤의 주소에 도달할 수 있음에도 이름으로서 존재하기를 그칩니다.

RFC 6762가 설명하는 대로, .local 로 끝나는 이름은 보통 로컬 링크의 멀티캐스트 DNS로 확인됩니다. 멀티캐스트는 무언가 의도적으로 브리지하거나 프록시하지 않는 한 라우팅된 터널을 넘지 않으므로, 세그먼트를 떠나는 순간 이름 확인이 중단됩니다.

완전히 정규화된 회사 이름은 조직의 리졸버가 서비스하는 내부 영역에 속합니다. VPN이 그 리졸버를 푸시하고 클라이언트가 이를 사용하도록 구성되면 원격에서도 작동합니다. 그리고 localhost 는 RFC 6761에 따라 특수 용도로, 눈앞의 기계를 가리키며 원격 서비스를 가리키는 일은 없습니다.

경로를 바꾸기 전에 리졸버를 읽으십시오

어떤 이름 서버가 응답했고 어떤 접미사가 붙었는지 물어보십시오. 같은 질의라도 리졸버가 다르면 답이 달라지며, 그 차이가 바로 필요한 증거입니다.

getent hosts fileserver
getent hosts fileserver.corp.example.com
nslookup fileserver.corp.example.com
dig +search fileserver A
resolvectl query fileserver.corp.example.com
scutil --dns | head -30

완전 정규화 질의는 확인되는데 짧은 질의는 안 된다면 실패는 서버가 아니라 접미사에 있습니다. 둘 다 확인되지 않고 주소가 작동한다면 클라이언트는 내부 리졸버를 전혀 사용하지 않는 것입니다. 모든 질의에 로컬 리졸버를 유지하는 클라이언트는 내부 영역을 결코 보지 못하므로, 리졸버 목록을 VPN이 푸시해야 하는 것과 비교하십시오.

올바른 이름을 클라이언트로 가져오기

관리자에게 문서화된 원격 접속 이름을 전체로 요청하고, 접미사를 추측하는 대신 프로필에서 그것을 사용하십시오. 배포가 split DNS를 지원하면 내부 도메인을 내부 서버가 확인하도록 구성하고 나머지는 로컬 리졸버를 유지하십시오. 클라이언트가 지원하는 곳에서는 VPN 구성으로 검색 도메인을 푸시하십시오.

결과는 게이트웨이가 아니라 클라이언트에서 확인하십시오. 서버에 적용되었지만 클라이언트에 도달하지 않는 설정은 아무것도 바꾸지 않습니다.

인증서 신원을 온전하게 유지하십시오

인증서 오류를 무시하는 주소 기반 테스트는 소켓이 열렸다는 것만 증명합니다. 서비스 인증서는 이름에 발급되며, 클라이언트는 정당한 이유로 불일치를 계속 거부할 것입니다. 인증서가 내부 이름만 나열한다면 그 이름을 사용하고 확인 문제를 고치거나, 사용하려는 주소를 포함하는 인증서를 받으십시오.

성공적인 연결을 만든 이름, 리졸버, 접미사를 기록하십시오. 그 기록은 실제 문제를 숨기는 주소 기반 우회를 다음 사람이 반복하지 않게 해 줍니다.