Dialogen sier at servernavnet ikke kunne slås opp, og profilfeltet du stirrer på, er en adresse. Den kombinasjonen er ikke en motsetning: klienten slår opp noe annet enn verdien du tror den leser. Finn ut hva den faktisk ringer til, før du konkluderer med at DNS er ødelagt. Rekkefølgen av klientens egne trinn forteller deg hvor du skal se.

Klienten slår opp et navn før den ringer

En innebygd Windows VPN-tilkobling leser profilen sin, slår opp serveradressen, starter tunnelen og autentiserer først etterpå. Feil 868 hører til det andre trinnet. Fordi de senere trinnene aldri kjøres, kan dialogen se ut som et påloggingsproblem når oppslaget feilet først.

Den rekkefølgen er nyttig fordi den begrenser laget som skal undersøkes. Når samme profil virker fra ett nett og feiler fra et annet, er forskjellen vanligvis navneoppslag og ikke tunneltypen eller kontoen. Test oppslaget der feilen oppstår, ikke der profilen ble laget.

Hvilket navn, når feltet viser en adresse

Les den lagrede verdien i stedet for visningsnavnet. Etiketten til en tilkobling er ikke serveradressen, og to oppføringer med like etiketter sender deg etter den gale:

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

Hvis profilen er klargjort for alle brukere, spør også om det omfanget med -AllUserConnection. Slå så opp nøyaktig den verdien kommandoen skrev ut, fra nettet der feilen oppstår. Bruk operatørens dokumenterte gateway, ikke det interne applikasjonsnavnet som først slås opp når tunnelen er oppe. Den andre spørringen feiler av en forventet grunn og sier deg ingenting om oppringingen:

Resolve-DnsName vpn.example.com

Når den lagrede verdien er virkelig numerisk, se etter et andre sted der klienten leser et navn. En EAP-konfigurasjon kan referere til en server, en profil importert fra et annet verktøy kan bære sin egen verdi, og et tidligere installasjonsprogram kan etterlate en duplikatoppføring. Feltet i dialogen er ikke alltid den eneste inngangen.

Gjenoppkoblingsmønsteret i Windows 7

Tråden bak denne feilen beskriver maskiner som koblet til én gang og deretter feilet ved et senere forsøk med 868, uten at noe ble endret i profilen. Bidragsytere rapporterte at omstart av tjenesten Remote Access Connection Manager eller å logge ut og inn igjen midlertidig gjenopprettet tilkoblingen. Det er omveier, ikke en påvist grunnårsak.

Behandle det mønsteret som en separat hypotese. En omstart nullstiller klienttilstanden, så en midlertidig suksess etterpå beviser ikke at DNS-posten var feil:

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

Les tabellen som et sett skillelige observasjoner, ikke som en diagnose. Den første raden er et navneproblem, den andre er klienttilstand, og den tredje er en profil som aldri var riktig. Hver av dem leder til en annen person og en annen rettelse.

Hva du bør samle inn til administratoren

Skriv ned profilnavnet, den lagrede adressen, tunneltypen, nettet klienten var på, og om feilen fulgte etter en frakobling. Den registreringen skiller en ekte oppslagsfeil fra den historiske gjenoppkoblingsatferden uten at noen må gjette. Ta også vare på klientens hendelseslogg rundt forsøket.

Omveien fra eldre versjoner er bevis for at atferden fantes, ikke et løfte om at den samme tjenesteomstarten vil reparere en nåværende maskin. Å erstatte et dokumentert vertsnavn med en bokstavelig adresse er heller ikke en reparasjon.

Noen profiler forventer en serveridentitet som samsvarer med det konfigurerte navnet, så en numerisk omvei kan bytte én feil mot en annen. Hvis navnet må bli, reparer oppslagsveien i stedet for profilteksten. Noter uansett hva du endret og hvorfor.

Relaterte artikler