VPN DNS는 작동하는데 .local 이름은 여전히 실패한다면, 누가 해석하는가?

같은 VPN에 있는 두 대의 컴퓨터, 같은 호스트 이름인데 한 대만 이름을 해석합니다. 차이는 보통 터널이 아니라 어떤 리졸버가 답했는지에 있습니다. Linux 데스크톱에서 그 이름은 이름 서비스 스위치를 거치거나 systemd-resolved의 스텁을 거치거나 애플리케이션이 함께 가져온 리졸버를 거칠 수 있으며, 각각은 같은 접미사에 자기 규칙을 적용합니다. 규칙이 갈라지는 곳이 바로 접미사입니다. .local는 중립적인 레이블이 아니기 때문입니다. 무언가 실행되는 순서를 바꾸기 전에 실패하는 프로그램이 실제로 어느 경로를 타는지 먼저 밝혀내세요.

두 리졸버, 두 가지 다른 답

전통적인 glibc 조회는 nsswitch.conf의 hosts: 줄을 따라가며 하나가 답할 때까지 각 모듈에 차례로 묻습니다. 스텁 리스너를 통해 systemd-resolved와 통신하는 클라이언트는 대신 단일 프로세스에 묻고, 그 프로세스는 링크별 정책과 자체 특수 사례를 적용합니다. 자체 리졸버를 포함하거나 그렇게 하는 라이브러리를 링크하는 애플리케이션은 둘 다 우회할 수 있습니다. 따라서 호스트 이름 하나가 한 컴퓨터에서 세 명의 소유자를 가질 수 있고, 그중 VPN이 의도한 바를 아는 사람은 한 명뿐입니다.

무엇이든 바꾸기 전에 소유자를 식별하세요. 수정 방법이 셋 각각 다르기 때문입니다. 같은 데스크톱의 브라우저와 명령줄 도구가 정당하게 불일치할 수 있으며, 그 불일치가 단서이지 버그가 아닙니다. 브라우저는 이름을 해석하는데 도구는 해석하지 못한다면, 디버깅 대상은 VPN 경로가 아니라 리졸버 경로입니다. 라우팅 장애가 이름 서비스 장애로 오인되지 않도록 경로를 따로 확인하세요. 둘이 일치한다면 장애는 호스트 상류에 있으며 여기 리졸버 설정은 더 손댈 가치가 없습니다.

어떤 명령이 실제로 리졸버에 물었는가

읽기 전용 명령 두 개가 서로 관련된 질문에 답하며, 둘을 비교하면 설정을 읽는 것보다 문제를 빨리 국소화할 수 있습니다. 실제 내부 이름을 사용하고 출력은 비공개로 유지하세요. 내부 레코드는 여전히 내부이기 때문입니다. 둘 다 실패하는 프로그램이 도는 같은 세션에서 실행하세요.

getent ahosts files.corp.local
resolvectl query files.corp.local
resolvectl status

첫 번째는 설정된 모듈을 통해 묻고, 일반적인 프로그램이 경험하는 것이 이것입니다. 두 번째는 systemd-resolved에 직접 묻고 응답한 링크, 프로토콜, 서버를 보고합니다. 서버에 주소로 질의하는 것은 서버가 레코드를 가지고 있다는 것만 증명합니다. 애플리케이션이 그 서버에 물었는지는 말해 주지 않기 때문입니다. VPN을 나르는 링크와 그것이 주장하는 도메인을 읽고, 그 목록을 실패하는 이름의 접미사와 비교하세요.

왜 .local이 유니캐스트 영역을 건너뛰는가

systemd-resolved 참조 문서 에 따르면 .local로 끝나는 다중 레이블 이름은 mDNS가 켜져 있을 때 일반 유니캐스트 DNS가 아니라 보통 멀티캐스트 DNS로 갑니다. RFC 6762는 그 이름 공간을 링크 로컬 멀티캐스트용으로 남겨 두므로, 기업 영역이 올바른 레코드를 가지고 있어도 그 접미사에 대해서는 결코 조회되지 않습니다. 터널이 리졸버를 완벽하게 라우팅해도 경쟁에서 질 수 있습니다. 캐시에서 성공한 ping은 방금 일어난 조회에 대해 아무것도 말해 주지 않습니다.

문서화된 예외가 있고, 그것이 이 사례 대부분을 해결합니다. 링크가 그 접미사를 검색 도메인이나 라우팅 도메인으로 선언하면, 데몬은 그것을 유니캐스트 경로에 유지하고 멀티캐스트 특수 사례를 건너뜁니다. 이는 링크별 정책이지 전역 선호가 아닙니다. 같은 VPN 서버를 쓰는 두 컴퓨터도 한쪽 네트워크 프로필만 도메인을 선언하면 다르게 동작할 수 있으니, 기억나는 프로필이 아니라 활성 프로필을 읽으세요.

좁은 예외가 전역 재정렬을 이긴다

이름을 바꿀 수 없는 기존 영역이라면 리졸버와 VPN 담당자에게 그것을 나르는 연결에서 도메인을 선언하게 하세요. 그 접미사 하나에 대한 라우팅 도메인 항목과 의도한 서버 주소만 있으면 담당자가 지정된 작은 변경이며, 손으로 편집한 파일이 아니라 링크와 함께 삽니다.

연결이 끊겼다 돌아와도 살아남습니다. 링크가 돌아오면 링크 정책이 다시 적용되기 때문입니다. 공유 nsswitch.conf를 편집하는 것은 유혹적이지만 더 비싼 대안입니다. 컴퓨터의 모든 이름, 로컬 검색까지 조회 동작을 바꾸기 때문입니다. 멀티캐스트 데몬을 끄는 것도 같지 않습니다. 로컬 동작을 없애면서 어떤 리졸버에도 기업 영역을 가르치지 않습니다. 서비스가 물려받은 것이 아니라 새것이라면 조직이 관리하는 하위 도메인 아래에 두고 경쟁을 완전히 피하세요. 이름이 펌웨어에 고정되어 있거나 라벨에 인쇄되어 있다면 좁은 예외를, 클라이언트를 아직 관리한다면 새 하위 도메인을 선택하세요.

변경 후 무엇을 증명할 것인가

테스트용으로 설치한 도구가 아니라 애플리케이션 자체의 조회로 수정을 증명하고, 대신 답할 수 있는 캐시를 모두 비우세요. 그다음 리졸버 경로와 답을 제공한 링크를 확인합니다. 마지막으로 로컬 검색이 변경 전과 같이 동작하는지 확인하세요. 사라진 프린터가 사람들이 가장 늦게 알아차리는 부분이기 때문입니다. 다음 세 명령은 이름, 경로, TLS 신원을 이 순서로 확인합니다.

getent ahosts files.corp.local
resolvectl query files.corp.local
curl -sv --max-time 5 https://files.corp.local/ 2>&1 | head -n 20

인증서가 틀리면 주소가 맞아도 엄격한 클라이언트는 실패하므로, 해석이 되면 애플리케이션이 기대하는 이름을 확인하세요. 서비스가 사무실 대역뿐 아니라 VPN 주소에서도 연결을 받는지 확인합니다. 도메인 범위, 서버, 소유자를 연결 문서에 적어 두세요. 그렇지 않으면 이 장애를 만나는 다음 사람이 방금 피한 것과 같은 전역 편집으로 손을 뻗을 것입니다.