Dijalog javlja da se ime poslužitelja nije moglo razriješiti, a polje profila u koje zurite jest adresa. Ta kombinacija nije proturječje: klijent razrješava nešto drugo od vrijednosti za koju mislite da je čita. Utvrdite na što zapravo poziva prije nego zaključite da je DNS pokvaren. Redoslijed vlastitih koraka klijenta pokazuje vam gdje tražiti.

Klijent razrješava ime prije nego pozove

Izvorna Windows VPN veza čita svoj profil, razrješava adresu poslužitelja, pokreće tunel i tek se onda autentificira. Pogreška 868 pripada drugom koraku. Budući da se kasniji koraci nikad ne izvode, dijalog može izgledati kao problem s vjerodajnicama kad je pretraga prva pala.

Taj je redoslijed koristan jer sužava sloj koji treba pregledati. Kad isti profil radi iz jedne mreže, a pada iz druge, razlika je obično u razrješavanju imena, a ne u vrsti tunela ili računu. Testirajte pretragu ondje gdje se kvar javlja, ne ondje gdje je profil stvoren.

Koje ime, kad polje pokazuje adresu

Čitajte pohranjenu vrijednost umjesto prikazanog imena. Oznaka veze nije njezina adresa poslužitelja, a dva unosa sa sličnim oznakama šalju vas za pogrešnim:

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

Ako je profil pripremljen za sve korisnike, ispitajte i taj obuhvat pomoću -AllUserConnection. Zatim razriješite točno onu vrijednost koju je naredba ispisala, iz mreže u kojoj se kvar javlja. Koristite dokumentirani pristupnik operatera, a ne interno ime aplikacije koje se razrješava tek nakon što se tunel podigne. Taj drugi upit pada iz očekivanog razloga i ne govori vam ništa o pozivu:

Resolve-DnsName vpn.example.com

Kad je pohranjena vrijednost doista brojčana, potražite drugo mjesto na kojem klijent čita ime. EAP konfiguracija može upućivati na poslužitelj, profil uvezen iz drugog alata može nositi vlastitu vrijednost, a raniji instalater može ostaviti dvostruki unos. Polje u dijalogu nije uvijek jedini ulaz.

Obrazac ponovnog povezivanja u Windowsu 7

Nit iza ove pogreške opisuje strojeve koji su se jednom povezali i zatim pali pri kasnijem pokušaju s 868, bez ikakve promjene u profilu. Suradnici su izvijestili da je ponovno pokretanje usluge Remote Access Connection Manager ili odjava i ponovna prijava privremeno vratilo vezu. To su zaobilazna rješenja, a ne dokazan korijenski uzrok.

Taj obrazac tretirajte kao zasebnu hipotezu. Ponovno pokretanje resetira stanje klijenta, pa privremeni uspjeh nakon toga ne dokazuje da je DNS zapis bio pogrešan:

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

Tablicu čitajte kao skup razlikovnih opažanja, a ne kao dijagnozu. Prvi red je problem s imenom, drugi je stanje klijenta, a treći je profil koji nikad nije bio ispravan. Svaki vodi do druge osobe i drugog ispravka.

Što prikupiti za administratora

Zapišite naziv profila, pohranjenu adresu, vrstu tunela, mrežu na kojoj je klijent bio i je li kvar uslijedio nakon prekida veze. Taj zapis odvaja stvarni neuspjeh pretrage od povijesnog ponašanja ponovnog povezivanja bez potrebe da ikome nagađa. Sačuvajte i dnevnik događaja klijenta oko pokušaja.

Zaobilazno rješenje iz starijih verzija dokaz je da je ponašanje postojalo, a ne obećanje da će isti restart usluge popraviti današnje računalo. Zamjena dokumentiranog imena hosta doslovnom adresom također nije popravak.

Neki profili očekuju identitet poslužitelja koji se podudara s konfiguriranim imenom, pa brojčano zaobilazno rješenje može zamijeniti jednu pogrešku drugom. Ako ime mora ostati, popravite put razrješavanja, a ne tekst profila. U svakom slučaju zapišite što ste promijenili i zašto.

Povezani članci