Kto tak naprawdę stosuje ustawienia DNS OpenConnect w Windows?

Podniesienie tunelu to nie to samo co zainstalowanie jego wartości DNS. OpenConnect negocjuje, a pomocnik po stronie Windows stosuje. Luka między tymi dwoma krokami wyjaśnia większość awarii prywatnych nazw w tym kliencie, a pomocnik prawie nigdy nie jest stroną ustawień VPN w Windows.

Oddziel to, co zaproponowała brama, od tego, co zainstalował Windows

Klient przekazuje dane połączenia interfejsowi skryptowemu, a warianty dla Unix i Windows to osobne programy. W Windows implementacją jest zwykle pomocnik JavaScript, który odczytuje zmienne, takie jak wewnętrzny serwer DNS i wewnętrzna domena, zanim dotknie jakiegokolwiek adaptera. Nic w samym tunelu nie zapisuje stanu resolvera.

Ten podział ma znaczenie, ponieważ wartość może istnieć w negocjacji i nigdy nie dotrzeć do adaptera. Brakujący, zawodzący w połowie lub będący starszą kopią osadzoną w nakładce GUI pomocnik pozostawia Windows dokładnie tak, jak były. Sesja wygląda na połączoną, prywatna nazwa nadal jest rozwiązywana przez lokalnego dostawcę, a nic w oknie klienta nie wskazuje różnicy. Odczytanie własnego wyjścia pomocnika to jedyny pewny sposób, by dowiedzieć się, który etap się zepsuł.

Nakładka GUI może dostarczać własną kopię klienta i pomocnika, więc drugi openconnect.exe gdzie indziej na dysku niczego nie dowodzi. Znajdź plik wykonywalny, który rozpoczął sesję, zanim ocenisz jego konfigurację.

Odczytaj stan resolvera bez zmieniania go

Trzy zapytania tylko do odczytu obejmują zwykłe zamieszanie, a każde odpowiada na inne pytanie:

Get-DnsClientServerAddress -AddressFamily IPv4
Get-DnsClient | Select-Object InterfaceAlias, ConnectionSpecificSuffix
Get-DnsClientNrptPolicy -Effective

Serwer na poziomie adaptera to, co większość ludzi rozumie przez DNS VPN. Sufiks właściwy dla połączenia decyduje, czy krótka nazwa w ogóle zostanie rozwinięta. Lista zasad przestrzeni nazw dotyczy pasujących nazw niezależnie od kolejności adapterów, a pusty wynik tam nie jest usterką, gdy pomocnik nigdy nie zamierzał go utworzyć. Odczytanie wszystkich trzech przed edycją zapobiega naprawie, która jedynie przenosi objaw gdzie indziej.

Zacznij od nazwy w pełni kwalifikowanej. Jeśli FQDN się rozwiązuje, a krótka nazwa nie, luką jest sufiks lub lista wyszukiwania, a nie adres serwera.

Jako drugi krok zapytaj bezpośrednio zamierzony serwer dowolnym już zainstalowanym narzędziem resolvera. Bezpośrednia odpowiedź dowodzi, że serwer jest osiągalny i autorytatywny dla strefy. Nie dowodzi niczego o tym, o który serwer aplikacja pyta domyślnie.

Nazwij komponent, który włada połączeniem

Typowe są dwa układy. Klient uruchomiony z terminala przekazuje jawnie ścieżkę swojego skryptu, więc właściciel jest widoczny w wykonanym poleceniu. Spakowana aplikacja uruchamia klienta za Ciebie i trzyma pomocnika we własnym katalogu, co oznacza, że dostawca decyduje, kiedy się zmieni.

Przed czymkolwiek porównaj wersje pomocnika między instalacjami. Uruchamianie pomocnika pobranego z lustra z podniesionymi uprawnieniami tylko dlatego, że nazwa pliku wygląda znajomo, zamienia lukę w DNS w incydent bezpieczeństwa.

Gdy właściciel jest znany, cel naprawy staje się oczywisty: obsługiwana ścieżka skryptu w launcherze, aktualizacja pakietu lub poprawiony profil na bramie. Żaden z nich nie wymaga ręcznej edycji właściwości adaptera.

Napraw właściciela, nie adapter

Ustawiony ręcznie DNS adaptera często przetrwa rozłączenie, dlatego wydaje się działać, a potem powoduje problemy w następnej sieci. Publiczny resolver przykręcony do każdego interfejsu ukrywa problem prywatnej przestrzeni nazw, zamiast go rozwiązywać. Gdy pomocnik nigdy nie otrzymał wartości DNS, profilem bramy jest miejsce, którego należy szukać. Gdy ją otrzymał, a adapter nadal pokazuje stary serwer, pomocnik zawiódł podczas łączenia, a dziennik klienta zwykle odnotowuje to przy wierszach konfiguracji tunelu.

Odbuduj stan obsługiwaną ścieżką, a następnie zweryfikuj cały cykl: połącz się, rozwiąż prywatny FQDN, otwórz usługę, rozłącz się i potwierdź, że adapter wrócił z poprzednimi serwerami.

Sprawdź aplikację, która faktycznie zawodzi

Przeglądarka z własnym ustawieniem szyfrowanego DNS ignoruje wszystko powyżej i nadal odpowiada z publicznego resolvera. Aplikacja trzymająca buforowaną odpowiedź negatywną sprzed podniesienia tunelu zachowuje się tak samo. Porównaj ją ze zwykłym zapytaniem systemowym na tej samej maszynie, zanim ponownie zmienisz adresy resolvera.

Jeśli zapytanie systemowe jest poprawne, a aplikacja nie, pozostała usterka tkwi w konfiguracji DNS tej aplikacji, a nie w ścieżce VPN.