Dialogas praneša, kad serverio vardo išspręsti nepavyko, o profilio laukas, į kurį žiūrite, yra adresas. Šis derinys nėra prieštaravimas: klientas sprendžia ką kita nei reikšmę, kurią, jūsų manymu, jis skaito. Išsiaiškinkite, ką jis iš tikrųjų kviečia, prieš darydami išvadą, kad DNS sugadintas. Kliento pačių veiksmų tvarka parodo, kur ieškoti.

Klientas išsprendžia vardą prieš skambindamas

Natūralus „Windows“ VPN ryšys perskaito profilį, išsprendžia serverio adresą, paleidžia tunelį ir tik tada atlieka autentifikaciją. Klaida 868 priklauso antram žingsniui. Kadangi vėlesni žingsniai niekada nevykdomi, dialogas gali atrodyti kaip prisijungimo duomenų problema, kai paieška nepavyko pirmoji.

Ši tvarka naudinga, nes susiaurina tikrinamą sluoksnį. Kai tas pats profilis veikia iš vieno tinklo ir nepavyksta iš kito, skirtumas paprastai yra vardų sprendimas, o ne tunelio tipas ar paskyra. Tikrinkite paiešką ten, kur kyla klaida, o ne ten, kur profilis buvo sukurtas.

Kuris vardas, kai laukas rodo adresą

Skaitykite išsaugotą reikšmę, o ne rodomą vardą. Ryšio etiketė nėra jo serverio adresas, o du įrašai su panašiomis etiketėmis nukreipia jus paskui netinkamą:

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

Jei profilis paruoštas visiems naudotojams, užklauskite ir tą sritį su -AllUserConnection. Tada išspręskite tiksliai tą reikšmę, kurią atspausdino komanda, iš tinklo, kuriame kyla klaida. Naudokite dokumentuotą operatoriaus šliuzą, o ne vidinį programos pavadinimą, kuris išsprendžiamas tik pakėlus tunelį. Antroji užklausa nepavyksta dėl numatomos priežasties ir nieko nepasako apie skambutį:

Resolve-DnsName vpn.example.com

Kai išsaugota reikšmė tikrai skaitinė, ieškokite antros vietos, kur klientas skaito vardą. EAP konfigūracija gali nurodyti serverį, profilis, importuotas iš kito įrankio, gali turėti savo reikšmę, o ankstesnis diegėjas gali palikti pasikartojantį įrašą. Dialogo laukas ne visada yra vienintelė įvestis.

„Windows 7“ persijungimo modelis

Šios klaidos gija aprašo kompiuterius, kurie kartą prisijungė, o vėliau bandydami nepavyko su 868, nors profilyje niekas nepasikeitė. Dalyviai pranešė, kad paslaugos „Remote Access Connection Manager“ paleidimas iš naujo arba atsijungimas ir prisijungimas iš naujo laikinai atkūrė ryšį. Tai apėjimo būdai, o ne įrodyta pagrindinė priežastis.

Traktuokite šį modelį kaip atskirą hipotezę. Paleidimas iš naujo atstato kliento būseną, todėl vėlesnė laikina sėkmė neįrodo, kad DNS įrašas buvo neteisingas:

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

Lentelę skaitykite kaip skiriamųjų stebėjimų rinkinį, o ne diagnozę. Pirmoji eilutė yra vardo problema, antroji – kliento būsena, trečioji – profilis, kuris niekada nebuvo teisingas. Kiekviena veda pas kitą žmogų ir prie kito sprendimo.

Ką surinkti administratoriui

Užsirašykite profilio pavadinimą, išsaugotą adresą, tunelio tipą, tinklą, kuriame buvo klientas, ir ar klaida įvyko po atsijungimo. Šis įrašas atskiria tikrą paieškos klaidą nuo istorinio persijungimo elgesio nereikalaujant, kad kas nors spėliotų. Taip pat išsaugokite kliento įvykių žurnalą apie bandymą.

Sprendimas iš senesnių versijų yra įrodymas, kad elgesys egzistavo, o ne pažadas, kad tas pats paslaugos paleidimas iš naujo sutvarkys dabartinį kompiuterį. Dokumentuoto pagrindinio kompiuterio vardo pakeitimas tiesioginiu adresu taip pat nėra taisymas.

Kai kurie profiliai tikisi serverio tapatybės, atitinkančios sukonfigūruotą vardą, todėl skaitinis apėjimo būdas gali iškeisti vieną klaidą į kitą. Jei vardas turi likti, taisykite sprendimo kelią, o ne profilio tekstą. Bet kuriuo atveju užsirašykite, ką ir kodėl pakeitėte.

Susiję straipsniai