Pogovorno okno sporoča, da imena strežnika ni bilo mogoče razrešiti, polje profila, v katero strmite, pa je naslov. Ta kombinacija ni protislovje: odjemalec razrešuje nekaj drugega kot vrednost, za katero mislite, da jo bere. Ugotovite, kam se dejansko povezuje, preden sklepate, da je DNS pokvarjen. Vrstni red lastnih korakov odjemalca vam pokaže, kam pogledati.

Odjemalec razreši ime, preden pokliče

Vgrajena povezava VPN v sistemu Windows prebere svoj profil, razreši naslov strežnika, zažene tunel in šele nato preveri pristnost. Napaka 868 spada k drugemu koraku. Ker se poznejši koraki nikoli ne izvedejo, je lahko pogovorno okno videti kot težava s poverilnicami, ko je iskanje prvo spodletelo.

Ta vrstni red je uporaben, ker zoži plast, ki jo je treba pregledati. Ko isti profil deluje iz enega omrežja in spodleti iz drugega, je razlika običajno razreševanje imen, ne vrsta tunela ali račun. Iskanje preizkusite tam, kjer pride do napake, ne tam, kjer je bil profil ustvarjen.

Katero ime, ko polje prikaže naslov

Berite shranjeno vrednost namesto prikazanega imena. Oznaka povezave ni njen naslov strežnika, in dva vnosa s podobnimi oznakami vas pošljeta za napačnim:

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

Če je profil pripravljen za vse uporabnike, poizvedite tudi po tem obsegu s -AllUserConnection. Nato razrešite natančno tisto vrednost, ki jo je ukaz izpisal, iz omrežja, kjer pride do napake. Uporabite dokumentirani prehod ponudnika, ne notranjega imena aplikacije, ki se razreši šele, ko je tunel vzpostavljen. Ta druga poizvedba spodleti iz pričakovanega razloga in vam o klicu ne pove ničesar:

Resolve-DnsName vpn.example.com

Ko je shranjena vrednost res številčna, poiščite drugo mesto, kjer odjemalec bere ime. Konfiguracija EAP se lahko sklicuje na strežnik, profil, uvožen iz drugega orodja, lahko nosi lastno vrednost, in starejši nameščevalnik lahko pusti podvojen vnos. Polje v pogovornem oknu ni vedno edini vnos.

Vzorec ponovnega povezovanja v sistemu Windows 7

Nit za to napako opisuje računalnike, ki so se enkrat povezali in nato pri poznejšem poskusu spodleteli z 868, ne da bi se v profilu kar koli spremenilo. Sodelavci so poročali, da je ponovni zagon storitve Remote Access Connection Manager ali odjava in ponovna prijava začasno obnovila povezavo. To so obhodi, ne dokazan temeljni vzrok.

Ta vzorec obravnavajte kot ločeno hipotezo. Ponovni zagon ponastavi stanje odjemalca, zato začasni uspeh po njem ne dokazuje, da je bil zapis DNS napačen:

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

Tabelo berite kot nabor razlikovalnih opažanj, ne kot diagnozo. Prva vrstica je težava z imenom, druga je stanje odjemalca, tretja pa profil, ki nikoli ni bil pravilen. Vsaka vodi k drugi osebi in drugemu popravku.

Kaj zbrati za skrbnika

Zapišite ime profila, shranjeni naslov, vrsto tunela, omrežje, v katerem je bil odjemalec, in ali je napaka sledila prekinitvi. Ta zapis loči resnično napako iskanja od zgodovinskega vedenja pri ponovnem povezovanju, ne da bi kdor koli moral ugibati. Shranite tudi dnevnik dogodkov odjemalca okoli poskusa.

Obhod iz starejših različic je dokaz, da je vedenje obstajalo, ne obljuba, da bo isti ponovni zagon storitve popravil sedanji računalnik. Zamenjava dokumentiranega imena gostitelja z dobesednim naslovom tudi ni popravilo.

Nekateri profili pričakujejo identiteto strežnika, ki ustreza konfiguriranemu imenu, zato lahko številčni obhod zamenja eno napako za drugo. Če mora ime ostati, popravite pot razreševanja, ne besedila profila. V vsakem primeru zapišite, kaj ste spremenili in zakaj.

Sorodni članki