Dlaczego nazwa serwera po dial-inie rozwiązuje się na jego adres VPN

Serwer plików biurowych odpowiada na swoim adresie LAN przez cały ranek, potem zdalny użytkownik łączy się przez dial-in i nazwa zaczyna się zamiast tego rozwiązywać na adres tunelu. Nic nie zostało ręcznie zmienione w DNS, i to jest wskazówka: rekord opublikowała sama maszyna. Trzy warunki decydują, czy naprawisz rejestrator, rekord czy widok klienta, a zła kolejność oznacza, że rekord wróci po następnym połączeniu.

Dwa adresy, jedna nazwa, trzy warunki

Serwer Windows z wieloma interfejsami może mieć adres LAN, jeden lub więcej adresów połączenia telefonicznego i czasem drugą kartę sieciową. Każdy interfejs może rejestrować własne adresy w DNS, jeśli ma dozwoloną rejestrację dynamiczną. Gdy adapter PPP się zarejestruje, ta sama nazwa hosta zyskuje adres osiągalny tylko dla partnera tunelu, a klienci LAN otrzymują go jako prawidłową odpowiedź.

Trzy warunki decydują o naprawie. Po pierwsze, czy dodatkowy adres jest osiągalny z klientów, które go otrzymują? Po drugie, czy jakiś odbiorca nadal zależy od tej rejestracji? Po trzecie, czy rekord jest dynamiczny i dlatego może wrócić, czy statyczny i dlatego celowy?

Odpowiedz na to, zanim czegokolwiek dotkniesz. Jeśli adres jest nieosiągalny z sieci, która pyta, żadne czyszczenie pamięci podręcznej klienta nie naprawi tego na długo. Jeśli coś od niego zależy, na przykład ścieżka zarządzania używana przez same strony tunelu, usunięcie zamiast tego psuje tę ścieżkę. A rekord dynamiczny usunięty bez zajęcia się jego wydawcą pojawi się ponownie przy następnym zdarzeniu rejestracji.

Przeczytaj rekord, zanim zmienisz rejestrator

Zapytaj o dokładną pełną nazwę kwalifikowaną z sieci, która zgłasza problem, i porównaj odpowiedzi z rzeczywistymi interfejsami i nasłuchami serwera. Jedna nazwa zwracająca kilka adresów jest normalna; pytanie brzmi, czy każdy z nich jest użyteczny dla klienta, który go otrzymuje.

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

Pierwsze zapytanie korzysta z lokalnego resolvera, drugie pyta bezpośrednio konkretny serwer DNS, a trzecie robi to samo z PowerShell w Windows. Porównanie ich oddziela nieaktualną pamięć podręczną klienta od odpowiedzi autorytatywnej. Jeśli bezpośrednie zapytanie już zwraca adres tunelu, problemem są opublikowane dane, a nie lokalne buforowanie.

Zapisz znacznik czasu rekordu i to, czy konsola DNS pokazuje go jako dynamiczny. Ten jeden atrybut mówi, który z trzech warunków powyżej obowiązuje, i to jest różnica między pięciominutowym sprzątaniem a naprawą, która się utrzymuje.

Napraw wydawcę albo rekord, ale wiedz który

Jeśli rekord jest dynamiczny i niechciany, trwałym rozwiązaniem jest uniemożliwienie temu interfejsowi rejestracji. Windows udostępnia ustawienia rejestracji dla każdego interfejsu, a usługa klienta DNS publikuje ponownie przy następnym połączeniu lub zmianie adresu. Wyłączenie rejestracji dla adaptera połączenia telefonicznego pozostawia rejestrację adaptera LAN nietkniętą, co zwykle jest tym, czego chcesz.

Uważaj na przełączniki dotyczące całej maszyny. Ustawienie globalne wyłączające dynamiczną aktualizację wpływa na każdy interfejs na tym hoście, w tym ten, na którego rejestracji polegają inni klienci. Na kontrolerze domeny ta sama ostrożność obowiązuje z większą siłą, ponieważ host może również posiadać rekordy lokalizacji usług, od których klienci zależą przy logowaniu.

Jeśli rekord jest statyczny, został tam umieszczony celowo i rozmowa jest z tym, kto go umieścił. Usunięcie statycznego rekordu, bo dziś jest niewygodny, usuwa jedyny dowód, dlaczego istnieje. W obu przypadkach usuń nieaktualną odpowiedź dopiero po zajęciu się wydawcą, i zapisz, co zmieniłeś, aby następna osoba mogła odróżnić celowy wpis od wypadku.

Zweryfikuj z sieci klienta, która zawiodła

Weryfikacja należy do sieci, która zgłosiła objaw, a nie do serwera. Wyczyść pamięć podręczną resolvera klienta obsługiwanym mechanizmem, a następnie powtórz pierwotne wyszukiwanie i pierwotne połączenie z usługą według nazwy.

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

Pierwsze polecenie czyści pamięć podręczną resolvera Windows, a drugie pokazuje, czy nazwa jest ponownie w pamięci podręcznej i który adres został zapisany. Udane połączenie serwera z samym sobą niczego nie dowodzi o kliencie LAN, a usunięcie trasy do niechcianego adresu nie poprawia tego, co publikuje DNS.

Na koniec powtórz zdarzenie, które wcześniej wprowadzało adres: połącz ponownie klienta VPN lub odśwież sesję połączenia telefonicznego. Sprawdź ponownie opublikowaną nazwę po tej zmianie cyklu życia. Naprawa, która trwa tylko do następnego połączenia, była sprzątaniem, a nie naprawą, a wiedza, którą z tych dwóch wykonałeś, jest różnicą między zamknięciem zgłoszenia a ponownym jego otwarciem w przyszłym tygodniu.