/etc/hosts 항목이 VPN의 DNS에 도달하지 않는 이유

/etc/hosts에 이름을 추가하고 VPN에 연결하면 모두에게 레코드가 보일 것이라고 기대했습니다. 그렇게 되지 않으며, 놀라움은 보통 두 번째 증상과 함께 옵니다. 이름은 내 컴퓨터에서는 확인되지만 동료 컴퓨터에서는 실패하는데, 이는 고장 난 VPN DNS 서비스처럼 보이지만 실제로는 hosts 파일이 설계된 대로 정확히 동작하는 것입니다. hosts 파일은 로컬 이름 확인 구성이며 영역 업데이트가 아니고, 일반적인 VPN 연결에서 그것을 업로드하는 것은 아무것도 없습니다.

hosts는 로컬 재정의이며 영역 업데이트가 아니다

이 파일은 이름 서비스 라이브러리가 DNS 서버에 묻기 전에, 또는 그 대신에 참조하는 매핑 목록입니다. 10.40.0.20 build.corp.example 같은 줄은 그 한 대의 컴퓨터에서 애플리케이션이 내리는 결론을 바꿉니다. 레코드를 만들지 않고, 터널을 통과하지 않으며, 터널이 가리키는 DNS 서버는 그것의 존재를 전혀 모릅니다.

그래서 실패는 비대칭입니다. 여러분의 클라이언트는 파일에서 답을 얻습니다. 다른 클라이언트는 VPN DNS 서버에 묻고, 서버는 아무것도 돌려주지 않으며, 애플리케이션은 이름이 없다고 보고합니다. 두 컴퓨터 모두 올바르게 동작하고 있으며, 한쪽만 다른 쪽이 본 적 없는 재정의를 가지고 있습니다.

두 명령, 두 가지 다른 구성 요소

이 논쟁을 멈추는 가장 빠른 방법은 차이를 두 명령에서 눈에 보이게 만드는 것이며, 둘 다 hosts 항목이 있는 클라이언트에서 실행합니다:

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

첫 번째는 시스템 자체의 조회 경로에 묻는데, 일반적인 glibc 시스템에서는 DNS보다 먼저 로컬 파일을 읽습니다. 두 번째는 DNS 쿼리를 해당 주소의 서버로 직접 보내고 로컬 파일은 전혀 참조하지 않습니다. 첫 번째가 여러분의 항목을 반환하고 두 번째가 NXDOMAIN을 반환하면, 레코드가 DNS에 없고 여러분의 컴퓨터가 로컬 재정의에서 답하고 있음을 증명한 것입니다.

순서는 구성 가능하며, 특정 배포판에 대해 무엇이든 결론을 내리기 전에 /etc/nsswitch.conf의 hosts: 줄을 확인할 가치가 있습니다. hosts: files dns는 파일을 먼저 참조합니다. 순서를 바꾸기 위해서만 그 예를 동작하는 구성 위에 복사하지 마세요. 실제 시스템은 예에 없는 추가 소스와 조건부 서비스 항목을 자주 나열하기 때문입니다.

systemd-resolved는 테스트를 흐리게 만든다

systemd-resolved를 사용하는 시스템에서는 로컬 스텁도 hosts 데이터베이스의 이름을 제공합니다. 따라서 127.0.0.53에 쿼리하는 것은 원격 서버의 독립적인 테스트가 아닙니다. DNS 쿼리처럼 보이고 그렇게 동작하더라도 마찬가지입니다. 리졸버가 무엇을 알고 어떤 서버에 물을지는 다음으로 확인할 수 있습니다:

resolvectl query build.corp.example
resolvectl status

status 출력은 링크별 DNS 서버를 알려주며, 이렇게 VPN 링크가 리졸버를 받았는지 알 수 있습니다. 그 질문은 hosts 항목과 별개이며, 개인 이름이 한 사람이 아니라 모든 사용자에게 실패할 때 물을 가치가 있는 질문입니다.

애플리케이션은 또 다른 계층을 더할 수 있습니다. 자체 DNS-over-HTTPS 설정이 있는 브라우저, 자체 리졸버 구성이 있는 컨테이너, 프로세스 수명 동안 조회를 캐시하는 런타임은 각각 시스템과 다르게 답할 수 있습니다. 하나의 명령이 컴퓨터의 모든 프로그램을 설명한다고 가정하지 말고 관심 있는 애플리케이션을 테스트하세요.

VPN을 넘어 이름을 실제로 공유하는 것

개인 이름이 모든 사람에게 동작해야 한다면 모두의 리졸버가 도달할 수 있는 소유자가 필요합니다. 깔끔한 답은 레코드를 관리 영역에 게시하고 그 영역을 의도된 VPN DNS 경로로 확인 가능하게 만드는 것입니다. 그러면 레코드에 단일 진실 공급원, 감사 추적, 수명 주기가 생기고, 어느 노트북이 로컬 재정의를 들고 있는지 아무도 기억할 필요가 없습니다.

hosts 파일을 배포하는 것은 합법적인 대안이며, 그것은 이름 서비스가 아니라 엔드포인트 관리입니다. 그것을 선택한다면 파일은 플릿을 관리하는 무엇인가가 배포하고 버전을 관리하고 제거해야 하며, 설계에서도 그렇게 설명해야 합니다. “VPN이 알아서 한다”는 그 과정에 대한 설명이 아닙니다.

동적 DNS 등록은 세 번째 메커니즘으로, 자체 권한, 업데이트 인증, 레코드 수명을 가집니다. 그것은 hosts 항목에서 나오지 않으며, 클라이언트가 단순히 연결하는 것에서도 나오지 않습니다. 서버와 클라이언트가 둘 다 그렇게 구성되어 있지 않다면 말입니다. 저절로 나타나는 레코드는 누군가 보안 업데이트를 켰고 클라이언트가 스스로 등록한다는 신호이며, 그 구성은 문제 해결 스레드가 아니라 설계 기록에 속합니다. 아무도 그 설정의 소유자를 말할 수 없다면 자동 레코드를 검증되지 않은 것으로 취급하고 관리 영역을 진실 공급원으로 유지하세요.

확인된 이름은 경로가 아니다

이름 확인과 도달 가능성은 별개이며, 오래된 로컬 매핑은 그것들을 혼동하는 전형적인 방법입니다. 이동한 주소를 가리키는 hosts 항목은 DNS가 수정된 훨씬 뒤에도 낡은 호스트를 계속 선택할 것이고, 증상은 잘 확인되는 이름의 라우팅 실패처럼 보입니다.

따라서 보고가 “이름은 확인되지만 서비스에 도달할 수 없다”일 때는 시스템 조회와 VPN DNS 서버에 대한 명시적 쿼리를 비교하고, 그다음 얻은 주소를 서비스가 실제로 사용하는 주소와 대조하세요. systemd-resolved 참조는 그것이 참조하는 로컬 소스를 문서화하며, 그 비교에 필요한 지도가 바로 이것입니다.

그다음 재정의를 소유자를 통해 고치세요. 자신의 hosts 파일에서 한 줄을 지우는 것은 배포 스크립트에서 같은 줄을 받은 열두 대의 노트북에는 아무 효과가 없으며, 사람들이 실제로 겪는 이 문제의 판본은 바로 그것입니다.