Okno informuje, że nie udało się rozwiązać nazwy serwera, a pole profilu, w które się wpatrujesz, jest adresem. Ta kombinacja nie jest sprzecznością: klient rozwiązuje coś innego niż wartość, którą, jak sądzisz, odczytuje. Ustal, do czego faktycznie się łączy, zanim uznasz, że DNS jest zepsuty. Kolejność własnych kroków klienta pokazuje, gdzie szukać.

Klient rozwiązuje nazwę, zanim zadzwoni

Natywne połączenie VPN w Windows odczytuje profil, rozwiązuje adres serwera, uruchamia tunel i dopiero potem się uwierzytelnia. Błąd 868 należy do drugiego kroku. Ponieważ późniejsze kroki nigdy nie działają, okno może wyglądać jak problem z poświadczeniami, gdy wyszukiwanie zawiodło pierwsze.

Ta kolejność jest przydatna, bo zawęża warstwę do sprawdzenia. Gdy ten sam profil działa z jednej sieci, a zawodzi z innej, różnicą jest zwykle rozwiązywanie nazw, a nie typ tunelu czy konto. Testuj wyszukiwanie tam, gdzie występuje błąd, a nie tam, gdzie utworzono profil.

Która nazwa, gdy pole pokazuje adres

Czytaj zapisaną wartość zamiast wyświetlanej nazwy. Etykieta połączenia nie jest jego adresem serwera, a dwa wpisy o podobnych etykietach wysyłają cię za niewłaściwym:

Get-VpnConnection -Name "Work VPN" |
    Select-Object Name, ServerAddress, TunnelType

Jeśli profil przygotowano dla wszystkich użytkowników, odpytaj też ten zakres za pomocą -AllUserConnection. Następnie rozwiąż dokładnie tę wartość, którą wypisała komenda, z sieci, w której występuje błąd. Użyj udokumentowanej bramy operatora, a nie wewnętrznej nazwy aplikacji, która rozwiązuje się dopiero po podniesieniu tunelu. To drugie zapytanie zawodzi z oczekiwanego powodu i nic nie mówi o połączeniu:

Resolve-DnsName vpn.example.com

Gdy zapisana wartość jest naprawdę liczbowa, poszukaj drugiego miejsca, w którym klient czyta nazwę. Konfiguracja EAP może wskazywać serwer, profil zaimportowany z innego narzędzia może mieć własną wartość, a wcześniejszy instalator może zostawić zduplikowany wpis. Pole w oknie nie zawsze jest jedynym wejściem.

Wzorzec ponownego łączenia w Windows 7

Wątek stojący za tym błędem opisuje maszyny, które połączyły się raz, a potem zawiodły przy późniejszej próbie z 868, bez żadnej zmiany w profilu. Współtwórcy donosili, że ponowne uruchomienie usługi Remote Access Connection Manager albo wylogowanie i zalogowanie tymczasowo przywracało połączenie. To obejścia, a nie udowodniona przyczyna źródłowa.

Traktuj ten wzorzec jako osobną hipotezę. Ponowne uruchomienie resetuje stan klienta, więc późniejszy tymczasowy sukces nie dowodzi, że rekord DNS był błędny:

ObservationPoints towardWhat to do next
Fails from one network, works from anotherName resolution on that pathResolve the stored name from both networks
Fails after a disconnect, works after service restartClient state, not DNSRecord the sequence for the vendor
Fails only on a newly provisioned machineProfile content or scopeCompare ServerAddress and TunnelType

Czytaj tabelę jako zbiór rozróżniających obserwacji, a nie diagnozę. Pierwszy wiersz to problem z nazwą, drugi to stan klienta, a trzeci to profil, który nigdy nie był poprawny. Każdy prowadzi do innej osoby i innej poprawki.

Co zebrać dla administratora

Zapisz nazwę profilu, zapisany adres, typ tunelu, sieć, w której był klient, oraz czy błąd nastąpił po rozłączeniu. Ten zapis oddziela prawdziwy błąd wyszukiwania od historycznego zachowania przy ponownym łączeniu, bez potrzeby zgadywania. Zachowaj też dziennik zdarzeń klienta wokół próby.

Obejście ze starszych kompilacji jest dowodem, że zachowanie istniało, a nie obietnicą, że ten sam restart usługi naprawi obecną maszynę. Zastąpienie udokumentowanej nazwy hosta dosłownym adresem też nie jest naprawą.

Niektóre profile oczekują tożsamości serwera zgodnej ze skonfigurowaną nazwą, więc liczbowe obejście może wymienić jeden błąd na inny. Jeśli nazwa musi zostać, napraw ścieżkę rozwiązywania, a nie tekst profilu. W każdym razie zapisz, co zmieniłeś i dlaczego.

Powiązane artykuły