짧은 내부 이름이 VPN에서 실패하는 이유: 결코 보지 못하는 접미사

짧은 이름은 사무실에서는 작동했지만 VPN에서는 실패하고, 전체 이름은 문제없이 확인됩니다. 고장 난 것은 없습니다. intranet 같은 맨이름은 완전한 이름이 아닙니다. 클라이언트가 검색 목록에서 접미사를 붙여 결과를 묻습니다. VPN 프로필이 그 접미사를 제공하지 않으면 익숙한 짧은 형태는 더 이상 존재하지 않습니다.

이것이 신화의 전부입니다. DNS가 망가진 것이 아니라 검색 정책이 바뀐 것입니다.

맨이름은 이름이 아니다

레이블 하나를 입력하면 리졸버는 무엇을 물을지 결정해야 합니다. 주어진 이름을 그대로 시도한 뒤, 무언가 응답할 때까지 검색 목록의 항목을 하나씩 붙입니다. Linux에서는 resolv.conf가 search와 ndots 설정으로 그 순서를 제어합니다. Windows에서는 접미사 목록과 이름 확인 정책이 같은 역할을 합니다. 접미사를 제거하면 리졸버가 덧붙일 것이 없습니다.

따라서 작동하는 짧은 이름은 정책의 증거이지, 건강한 DNS 서버의 증거가 아닙니다.

접미사 목록과 리졸버 주소가 각각 하는 일

이 둘은 끊임없이 혼동됩니다. 리졸버 주소는 누구에게 물을지 말하고, 접미사 목록은 어느 이름에 대해 물을지 말합니다. VPN은 접미사 없는 사설 리졸버를 줄 수도 있고, 잘못된 리졸버와 함께 접미사를 줄 수도 있습니다. 그 실패 중 DNS 장애처럼 보이는 것은 하나뿐입니다.

잘못된 쪽을 고치면 지원 시간을 태우므로 따로 확인하세요.

세 가지 증상, 세 명의 다른 담당자.

먼저 전체 이름을 시험하세요

추측이 아니라 관리자가 문서화한 정규화된 전체 이름을 문의하세요. 작동하는 FQDN은 리졸버에 도달할 수 있고 레코드가 존재함을 증명하며, 한 번의 질의로 가능한 원인의 절반을 제거합니다. 어떤 서버가 응답했는지 보여주는 도구를 사용해 캐시된 결과를 읽지 않도록 하세요.

시험은 비공개로 유지하세요. 내부 변형을 공용 리졸버로 보내는 것은 이름을 노출하고 아무도 의도하지 않은 정책을 시험합니다.

수정은 어디에 속하는가

소유 프로필이나 그것을 생성하는 관리 시스템을 고치세요. 로컬 리졸버 구성을 수동으로 편집하면 보통 다시 연결할 때 사라지거나, 머신이 가입하는 모든 네트워크에 적용되어 더 나쁩니다.

Windows에서는 기억하는 체크박스 대신 실제 적용되는 정책을 확인하세요. Get-DnsClientNrptPolicy는 실제로 시행 중인 이름 확인 규칙을 보여줍니다.

macOS에서는 scutil --dns가 범위가 지정된 인터페이스별 리졸버 구성을 VPN이 밀어 넣은 검색 도메인까지 포함해 출력합니다.

Linux에서는 /etc/resolv.conf의 search 줄을 읽되, VPN 클라이언트가 다시 썼는지 확인하세요. 파일이 관리되고 있다면 렌더링된 파일이 아니라 진실의 원천을 편집하세요. 이전 네트워크에서 남은 오래된 search 줄은 흔한 원인입니다.

프로필과 함께 보관할 것

수정된 전체 이름, 접미사 목록, 리졸버 주소를 클라이언트 프로필 옆에 보관하세요. intranet 사이트가 죽었다고 보고하는 다음 사람은 빈 페이지에서 시작하는 대신 알려진 세 값을 비교할 수 있습니다.

그리고 짧은 형태만 실패한다면 티켓에 그렇게 적으세요. 그 한 문장이 리졸버 팀의 오후를 아껴 줍니다.