VPN przejął DNS i zepsuł nazwy lokalne: napraw listę

Tunel wstaje, intranet się ładuje, a nazwa drukarki przestaje się rozwiązywać. Albo odwrotnie: nazwy lokalne nadal działają, podczas gdy wszystko w sieci firmowej kończy się przekroczeniem czasu. Oba objawy pochodzą z tego samego miejsca, z listy resolverów, którą klient VPN przepisał przy połączeniu.

Napraw listę celowo, a potem osobno zajmij się mechanizmem push. Trasy to trzeci temat i nie to jest tu naprawiane.

Której listy aplikacje faktycznie używają

Windows rozwiązuje przez ustawienia na poziomie interfejsu, a nie przez to, co pokazuje jakieś okno, więc zacznij od efektywnych list dla każdego interfejsu. Alias znaczy więcej niż wyświetlana nazwa, bo każde polecenie poniżej adresuje interfejs. Pomylisz alias i naprawa wyląduje na złym adapterze. Będzie wyglądać, że działa, do następnego połączenia, gdy wróci własny wpis tunelu.

Pytanie brzmi, które serwery znalazły się z przodu i czy przyszły jako wpisy statyczne, czy jako dzierżawa DHCP. Oba fakty decydują, jaka naprawa jest dla ciebie dostępna.

netsh interface ipv4 show dnsservers
Get-DnsClientServerAddress -AddressFamily IPv4

Przeczytaj wynik dla adaptera tunelu i dla adaptera fizycznego i zanotuj każdy adres na obu. Wpis statyczny można usunąć polityką lub skryptem; wpis dostarczony przez DHCP jest związany z dzierżawą i wróci, co zmienia naprawę, którą należy wybrać. Nazwy w sieci zdalnej rozwiązuje ogłaszany resolver, nazwy w lokalnej sieci LAN adapter fizyczny, a zapytanie idzie do listy, którą sprawdza się najpierw.

Usuń wpychane serwery albo ustaw je niżej

Skasuj wpychane serwery, gdy nic w tunelu ich nie potrzebuje, bo własne resolvery adaptera fizycznego znów przejmują rolę. Zostaw je tylko wtedy, gdy sieć zdalna ma strefy, na które odpowiedzieć mogą wyłącznie jej serwery, a w takim przypadku postaw przed nimi lokalny resolver. Dwa polecenia poniżej obejmują oba wybory, więc wybierz to, które pasuje do sytuacji, zamiast uruchamiać oba.

netsh interface ipv4 delete dnsservers name="Corp VPN" address=all validate=no
netsh interface ipv4 add dnsservers name="Corp VPN" address=172.16.20.1 index=1 validate=no

Indeks 1 jest sprawdzany pierwszy, więc wpychane adresy pozostają dostępne, ale przestają być domyślną odpowiedzią na każde zapytanie. Flaga validate=no pomija test osiągalności, który często zawodzi, dopóki tunel się jeszcze układa, więc potwierdź wynik poleceniem show, zamiast ufać kodowi wyjścia.

Warto znać dwie granice, zanim się na tym oprze. Windows nie usunie serwerów, które przyszły przez DHCP za pomocą netsh, a te wartości trwają jako DhcpNameServer pod kluczem rejestru interfejsu, więc edycja rejestru jest ostatnią deską ratunku, którą trzeba sprawdzić ponownie po kolejnej dzierżawie. Kolejność powiązań adapterów też nie jest pewnym mechanizmem szeregowania, bo klient VPN może wstawić własny wpis na początek listy.

Gdzie można filtrować push

Lepsza naprawa usuwa opcję, zanim zostanie zastosowana. Klient Community OpenVPN potrafi filtrować wpychaną dyrektywę po nazwie, co zostawia konfigurację serwera nietkniętą.

pull-filter ignore "dhcp-option DNS "

Spacja na końcu należy do dopasowania, a filtr nazywa opcję, nie adres serwera. Jeśli profil zawiera też dyrektywę block-outside-dns, jej usunięcie zmienia ochronę przed wyciekiem, a nie rozwiązywanie nazw, więc zdecyduj o tym osobno, zamiast łączyć obie zmiany.

Dla jednej upartej nazwy hosta jedna linia w pliku hosts Windows jest stabilniejsza niż przestawianie resolverów dla całej maszyny. Jest też niewidoczna dla następnej osoby, więc zapisz ją tam, gdzie dokumentowana jest konfiguracja maszyny.

Spraw, aby naprawa przetrwała ponowne połączenie

Rozwiązywanie nazw trzeba przetestować dwa razy, raz wobec wybranego serwera i raz w formie, której używa aplikacja. Ta para oddziela problem kolejności resolverów od serwera, który w ogóle nie odpowiada. Pominięcie pierwszego testu zostawia obie przyczyny splątane.

Resolve-DnsName intranet.corp.example -Server 172.16.20.1
Resolve-DnsName printer.lan

Połącz tunel ponownie i powtórz oba polecenia. To, co zmieniłeś ręcznie, trwa tylko do następnego połączenia, bo klient odbudowuje stan resolverów, podnosząc adapter. Wstaw linie netsh do obsługiwanego skryptu połączenia twojego klienta, pozwól skryptowi zakończyć się sukcesem i dodaj krótkie oczekiwanie, zanim się uruchomi. Klient, który stosuje DNS po skrypcie, i tak nadpisze wynik.

Jeśli nazwy publiczne się rozwiązują, a wewnętrzne nadal zawodzą po naprawie, lista resolverów przestała być podejrzanym. Zapytanie prawdopodobnie w ogóle nie dociera do serwera, co wskazuje na routing albo regułę firewalla, a nie na kolejne ustawienie DNS. Zanotuj alias interfejsu i adresy, na których stanąłeś, bo oba różnią się między maszynami i żadne samo nie przetrwa przebudowy.