Dlaczego DNS przestaje działać po połączeniu OpenVPN w Windows

Resolver nadal odpowiada na ping, choć port 53 donikąd nie prowadzi. Sprawdź, czy filtruje block-outside-dns, a potem zapewnij resolver, do którego tunel dotrze.

Ping do firmowego resolvera nadal otrzymuje odpowiedź po połączeniu "OpenVPN", a mimo to każde wyszukiwanie nazwy zawodzi. Adres jest osiągalny, a port nie, kombinacja, która ma sens, gdy wiesz, że Windows potrafi filtrować DNS według adaptera. Gdy w profilu jest block-outside-dns, ten filtr jest pierwszym podejrzanym, a tabela tras to złe miejsce do szukania. Dwa testy poniżej rozdzielają warstwy w kilka sekund.

Osiągalny adres, martwy port

Udany ping dowodzi, że host działa i że istnieje ścieżka. Nie mówi nic o zgodzie na dotarcie do portu 53, bo omawiany filtr pracuje w innej warstwie i zależy od adaptera. Dlatego ten sam komputer może odpowiadać na ICMP i odrzucać każde zapytanie wysłane na ten sam adres. Uruchom oba testy w tej samej sesji, zanim zmienisz jakąkolwiek konfigurację.

ping <resolver-ip>
nslookup <name> <resolver-ip>

Ta para to diagnoza. Zwykły ruch do podsieci działa dalej, a rozwiązywanie nazw umiera, więc ludzie wnioskują, że serwer jest zepsuty albo że DNS nigdy nie został przesłany. Obu wyjaśnień drogo szukać, a dowody wskazują na coś węższego. Potwierdź parę, zanim dotkniesz ustawienia.

Ta opcja jest regułą platformy filtrowania

Dokumentacja OpenVPN opisuje block-outside-dns jako ograniczenie Windows Filtering Platform, które uniemożliwia aplikacjom dotarcie do DNS na adapterach poza tunelem. Obejmuje TCP i UDP na porcie 53. Ponieważ filtr żyje w WFP, a nie na zwykłej liście reguł zapory, dodanie reguły zezwalającej gdzie indziej nie musi zmienić wyniku. Dlatego powszechna rada, by zezwolić na DNS, wciąż zawodzi.

Ustawienie może przyjść z zaimportowanego profilu albo z serwera, a plik, który ostatnio edytowałeś, "nie jest dowodem na to, co wczytał klient". Czytaj efektywną konfigurację i dziennik połączenia razem. Opcja jest też specyficzna dla Windows, a traktowanie jej jako przenośnej daje rady, które nie mają zastosowania.

Szukaj komponentu klienta, który posiada to ograniczenie, zamiast dodawać kolejne reguły. Właściciel to rzecz, która naprawdę może je usunąć.

Filtr to nie resolver

Blokowanie ruchu poza tunelem nie instaluje w nim działającego resolvera. Opcja usuwa ścieżkę i zostawia konfigurację DNS tunelu temu, kto ustawił profil. Profil, który nigdy nie wysłał resolvera, nie ma teraz żadnego.

Przejdź przez trzy kontrole po kolei. Po pierwsze, którego resolvera faktycznie używa zawodząca aplikacja. Po drugie, czy klient zastosował ustawienia DNS sieci VPN. Po trzecie, który interfejs niesie ruch do tego resolvera.

  1. Używany resolver: porównaj Resolve-DnsName -Server <resolver-ip> <name> z serwerami DNS wymienionymi przez ipconfig /all.
  2. DNS sieci VPN zastosowany: sprawdź wpisy DNS adaptera tunelu w tym samym wyniku polecenia ipconfig /all.
  3. Używany interfejs: Find-NetRoute -RemoteIPAddress <resolver-ip> wskazuje interfejs wyjściowy dla tego celu.

Resolver LAN staje się nieosiągalny z założenia przy tej polityce, nawet gdy inny ruch LAN działa. To właśnie ta opcja wykonuje swoją pracę. Jeśli projekt wymaga DNS przez VPN, popraw rejestrację resolvera i ścieżkę tunelu; jeśli potrzebny jest split DNS z lokalnymi wyjątkami, właściciel konfiguracji musi wyrazić te wyjątki w obsługiwany sposób.

Czego opcja nie obejmuje

Port 53 to nie całe rozwiązywanie nazw. DNS over HTTPS i DNS over TLS używają innych transportów, a niektóre aplikacje prowadzą własną logikę resolvera niezależnie od ustawień systemu. Przeglądarka może więc rozwiązywać nazwy, gdy wiersz poleceń nie potrafi.

Traktuj tę różnicę jako diagnostykę, a nie sprzeczność. Porównaj oba, zanim uznasz, że resolver systemu jest zepsuty.

Trzymaj wniosek wąsko, gdy go zapisujesz. Ta opcja ogranicza jeden transport na jednej platformie, a reszta ścieżki rozwiązywania to osobne pytanie projektowe z własnym właścicielem.

Sprawdź stan przed rozłączeniem i po nim

Uruchom to samo wyszukiwanie podczas połączenia i ponownie po rozłączeniu klienta-właściciela. Pierwsze powinno zawieść dla zewnętrznego resolvera, dopóki tunel jest podniesiony, a drugie powinno się udać po usunięciu filtra. Jeśli po rozłączeniu nadal zawodzi, filtr nie został posprzątany.

ipconfig /displaydns
nslookup <name> <resolver-ip>

Restart usługi klienta lub komputera zwykle usuwa stary filtr. To potwierdza diagnozę, nie dowodząc trwałej naprawy. Zapisz, co widziałeś, bo filtr, który przetrwa rozłączenie, zrobi to znowu, a właśnie notatka uzasadnia zgłoszenie błędu.

Dopiero po tych kontrolach ma sens wymiana resolvera albo przebudowa polityki zapory. Oba są większymi zmianami, niż wspierają dowody.

Powiązane artykuły