다이얼인 후 서버 이름이 VPN 주소로 확인되는 이유

사무실 파일 서버가 오전 내내 LAN 주소로 응답했는데, 이후 원격 사용자가 다이얼인하자 이름이 대신 터널 주소로 확인되기 시작했습니다. DNS에서 손으로 편집한 것은 없었고, 그것이 단서입니다. 레코드는 머신 자체가 게시한 것입니다. 세 가지 조건이 등록자, 레코드, 클라이언트의 시야 중 무엇을 고칠지 결정하며, 순서를 틀리면 다음 연결 후에 레코드가 돌아옵니다.

두 주소, 하나의 이름, 세 가지 조건

멀티홈 Windows 서버는 LAN 주소, 하나 이상의 다이얼인 주소, 때로는 두 번째 네트워크 카드를 가질 수 있습니다. 각 인터페이스는 동적 등록이 허용되면 자신의 주소를 DNS에 등록할 수 있습니다. PPP 어댑터가 등록하면 같은 호스트 이름에 터널 상대만 도달할 수 있는 주소가 추가되고, LAN 클라이언트는 이를 유효한 응답으로 받습니다.

세 가지 조건이 복구를 결정합니다. 첫째, 추가 주소가 그것을 받는 클라이언트에서 도달 가능한가? 둘째, 어떤 소비자가 아직 그 등록에 의존하는가? 셋째, 레코드가 동적이어서 돌아올 수 있는가, 아니면 정적이어서 의도된 항목인가?

무엇이든 건드리기 전에 이에 답하세요. 주소가 질의하는 네트워크에서 도달할 수 없다면 클라이언트 캐시를 지우는 것으로 오래 고쳐지지 않습니다. 터널 상대가 직접 사용하는 관리 경로처럼 무언가가 그것에 의존한다면, 제거는 오히려 그 경로를 끊습니다. 그리고 게시자를 처리하지 않고 삭제한 동적 레코드는 다음 등록 이벤트에 다시 나타납니다.

등록자를 바꾸기 전에 레코드를 읽으세요

문제를 보고하는 네트워크에서 정확한 정규화된 이름을 조회하고, 응답을 서버의 실제 인터페이스와 수신기와 비교하세요. 하나의 이름이 여러 주소를 반환하는 것은 정상이며, 문제는 각 주소가 그것을 받는 클라이언트에 유용한가입니다.

dig +short files.corp.example A
dig @10.20.0.10 +short files.corp.example A
Resolve-DnsName files.corp.example -Server 10.20.0.10 -Type A

첫 번째 질의는 로컬 확인자를 사용하고, 두 번째는 특정 DNS 서버에 직접 묻고, 세 번째는 Windows의 PowerShell에서 같은 일을 합니다. 이를 비교하면 오래된 클라이언트 캐시와 권한 있는 응답을 구분할 수 있습니다. 직접 질의가 이미 터널 주소를 반환한다면 문제는 로컬 캐시가 아니라 게시된 데이터입니다.

레코드의 타임스탬프와 DNS 콘솔이 이를 동적으로 표시하는지 적어 두세요. 그 하나의 속성이 위의 세 조건 중 무엇이 적용되는지 알려 주며, 이는 오 분의 정리와 오래가는 복구의 차이입니다.

게시자를 고치거나 레코드를 고치되 어느 쪽인지 아세요

레코드가 동적이고 원하지 않는 것이라면 지속적인 해결책은 그 인터페이스가 등록하지 않게 하는 것입니다. Windows는 인터페이스별 등록 설정을 제공하며, DNS 클라이언트 서비스는 다음 연결이나 주소 변경 시 다시 게시합니다. 다이얼인 어댑터의 등록을 끄면 LAN 어댑터의 등록은 그대로 유지되며, 보통 그것이 원하는 바입니다.

머신 전체에 적용되는 스위치를 조심하세요. 동적 업데이트를 사용하지 않도록 하는 전역 설정은 해당 호스트의 모든 인터페이스에 영향을 주며, 다른 클라이언트가 등록을 의존하는 인터페이스도 포함됩니다. 도메인 컨트롤러에서는 같은 주의가 더 강하게 적용되는데, 호스트가 클라이언트 로그온에 필요한 서비스 위치 레코드도 소유할 수 있기 때문입니다.

레코드가 정적이라면 의도적으로 그곳에 놓인 것이며 대화는 그것을 놓은 사람과 하는 것입니다. 오늘 불편하다는 이유로 정적 레코드를 지우면 그것이 존재하는 이유에 대한 유일한 증거가 사라집니다. 두 경우 모두 게시자를 처리한 뒤에만 오래된 응답을 지우고, 무엇을 바꿨는지 기록해 다음 사람이 의도된 항목과 사고를 구별할 수 있게 하세요.

실패한 클라이언트 네트워크에서 검증하세요

검증은 증상을 보고한 네트워크에서 해야 하며 서버에서 하는 것이 아닙니다. 클라이언트 확인자 캐시를 지원되는 방식으로 비운 다음, 원래 조회와 이름으로의 원래 서비스 연결을 반복하세요.

ipconfig /flushdns
ipconfig /displaydns | findstr /i files.corp.example

첫 번째 명령은 Windows 확인자 캐시를 비우고, 두 번째는 이름이 다시 캐시되었는지와 어떤 주소가 저장되었는지를 보여 줍니다. 서버가 자기 자신에 연결하는 성공은 LAN 클라이언트에 대해 아무것도 증명하지 못하며, 원하지 않는 주소로 가는 경로를 제거해도 DNS가 게시하는 내용은 바로잡히지 않습니다.

마지막으로 예전에 주소를 들여오던 이벤트를 반복하세요. VPN 클라이언트를 다시 연결하거나 다이얼인 세션을 갱신하세요. 그 수명 주기 변경 후 게시된 이름을 다시 확인하세요. 다음 연결까지만 유지되는 복구는 정리가 아니라 복구가 아니며, 어느 쪽을 했는지 아는 것이 티켓을 닫는 것과 다음 주에 다시 여는 것의 차이입니다.