VPN 내부의 mDNS: .local 이름이 확인되지 않는 이유

사무실 프린터가 책상의 모든 애플리케이션에 나타나지만 VPN에서는 사라지는데, 프린터에 있다고 아는 주소로 ping은 됩니다. 터널 안에서 고장 난 것은 없습니다: 검색과 도달 가능성은 별개의 서비스이고, 기본적으로 둘 중 하나만 라우팅된 터널을 통과합니다. 아래 점검은 경로를 추가하기 전에 둘을 분리합니다. 링크를 떠난 적 없는 쿼리를 경로로 고칠 수는 없습니다.

오늘 무엇이 확인되고 무엇이 확인된 것처럼 보일 뿐인지 점검하세요

먼저 두 질문을 분리하세요: 호스트 이름에 대한 유니캐스트 쿼리는 리졸버에 묻고, _ipp._tcp 검색은 로컬 링크에 묻습니다. Linux에서는 avahi-browse -a이 멀티캐스트 DNS가 볼 수 있는 것을 보여 주고, resolvectl query name.local가 리졸버 스택이 그 이름으로 무엇을 하는지 보여 줍니다. macOS에서는 dns-sd -B _ipp._tcp이 먼저 주소가 필요 없이 발견된 서비스를 나열합니다.

주소는 응답하는데 이름이 응답하지 않으면 라우팅은 작동하고 검색은 작동하지 않습니다. .local 이름은 avahi-browse가 설치되어 있지 않아도 nss-mdns를 통해 호스트 자체에서 응답될 수 있으므로, 그 이름에 대한 getent나 ping 성공은 검색이 터널을 넘었다는 증거가 아닙니다: 검색 결과와 리졸버 결과는 서로 다른 증거입니다. 애플리케이션은 발견한 것을 캐시하므로, 장애는 연결 시점이 아니라 연결 후 몇 시간 뒤에 나타나는 경우가 많습니다. 애플리케이션을 종료했다가 다시 열고, 캐시된 항목이 이름을 담고 있는지 주소를 담고 있는지 확인하세요, 검색이 멈춘 뒤에도 주소는 오래 작동하기 때문입니다.

쿼리가 터널을 넘지 못하는 이유

멀티캐스트 DNS는 로컬 네트워크 제어 블록 안의 224.0.0.251로, UDP 포트 5353을 통해 쿼리를 보냅니다. 라우터는 그 블록의 주소를 전달하지 않으므로 쿼리는 보낸 링크에 그대로 남습니다. 송신 측이 IP TTL 또는 IPv6 홉 제한을 255로 설정하는 것은 수신 측이 이미 라우터를 지난 패킷을 거부할 수 있게 하기 위한 것이며, 프로토콜이 링크 밖 스푸핑을 탐지하는 방식이 이것이고, 로컬에 머무는 이유도 여기에 있습니다. 로컬성은 목적지 주소에서 오며, 한 홉 TTL에서 오지 않습니다.

터널 유형도 중요합니다. tun 스타일 인터페이스는 IP 패킷만 전달하고 그 밖의 것은 전달하지 않으므로 어떤 멀티캐스트 그룹도 통과하지 못합니다. tap 스타일 브리지는 브로드캐스트 도메인 자체를 확장하므로, 일부 오래된 설계는 라우팅 대신 브리지를 했고 브리지가 가져오는 모든 문제를 물려받았습니다.

신뢰할 수 있는 LAN 예외는 터널에 멀티캐스트 전달을 가르치는 대신 어떤 트래픽이 터널을 쓸 수 있는지 결정하기 때문에 이 중 아무것도 바꾸지 않습니다. 패킷에는 여전히 들을 수 있는 공유 세그먼트가 없습니다.

감당할 수 있는 이름 설계를 고르세요

기업 리소스에는 VPN이 밀어 넣는 리졸버가 제공하는 라우팅된 호스트 이름이 지속적인 답이며, 내부 이름은 내부 서버로 가고 나머지는 가지 않도록 분할 DNS와 함께 씁니다. Windows는 이를 이름 확인 정책 테이블로 노출하고, macOS는 인터페이스별 범위 리졸버를 사용하며, 대부분의 클라이언트에는 동등한 푸시 설정이 있습니다. 장치는 내부 DNS에 평소 이름을 유지하고, 검색은 경로의 일부가 아니게 됩니다.

검색 프록시나 mDNS 리플렉터가 이 간극을 메울 수 있으며, 그것은 자체 호스트와 자체 노출, 자체 클라이언트 요구를 가진 실제 설계입니다. 경로를 추가했다고 해서 나타나는 것은 아닙니다. .local 쿼리를 공용 리졸버로 전달하지 마세요: 이 도메인은 RFC 6762에 의해 로컬 멀티캐스트용으로 예약되어 있고, 외부로 보내면 느린 실패와 불필요한 데이터 노출을 낳습니다.

이름이 아니라 서비스를 검증하세요

검색 목록의 이름은 검색 단계를 증명할 뿐, 서비스가 응답한다는 것을 증명하지 않습니다. 인쇄 큐나 웹 인터페이스를 열어 실제 작업을 완료하고, 다시 연결한 뒤 반복하세요.

검색은 이름을 공격적으로 캐시하므로 오래된 항목이 성공처럼 보일 수 있습니다. 인증서나 인증 프롬프트가 나타나면 그것은 다음 계층이며 별개의 문제입니다. 어떤 메커니즘을 바꿨는지, 리졸버인지 검색인지 적어 두면 다음 사람이 같은 질문을 처음부터 다시 열지 않아도 됩니다.