Dialogen seier at servernamnet ikkje kunne slåast opp, og profilfeltet du stirrar på, er ei adresse. Den kombinasjonen er ikkje ei motsegn: klienten slår opp noko anna enn verdien du trur han les. Finn ut kva han faktisk ringjer til, før du konkluderer med at DNS er øydelagd. Rekkjefølgja av klienten sine eigne steg fortel deg kvar du skal sjå.

Klienten slår opp eit namn før han ringjer

Ei innebygd Windows VPN-tilkopling les profilen sin, slår opp serveradressa, startar tunnelen og autentiserer først etterpå. Feil 868 høyrer til det andre steget. Fordi dei seinare stega aldri køyrer, kan dialogen sjå ut som eit påloggingsproblem når oppslaget feila først.

Den rekkjefølgja er nyttig fordi ho avgrensar laget som skal undersøkjast. Når same profil verkar frå eitt nett og feilar frå eit anna, er skilnaden vanlegvis namneoppslag og ikkje tunneltypen eller kontoen. Test oppslaget der feilen oppstår, ikkje der profilen vart laga.

Kva namn, når feltet viser ei adresse

Les den lagra verdien i staden for visingsnamnet. Etiketten til ei tilkopling er ikkje serveradressa, og to oppføringar med like etikettar sender deg etter den gale:

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

Viss profilen er klargjord for alle brukarar, spør òg om det omfanget med -AllUserConnection. Slå så opp nøyaktig den verdien kommandoen skreiv ut, frå nettet der feilen oppstår. Bruk den dokumenterte gatewayen til operatøren, ikkje det interne applikasjonsnamnet som først blir slått opp når tunnelen er oppe. Den andre spørjinga feilar av ein venta grunn og seier deg ingenting om oppringinga:

Resolve-DnsName vpn.example.com

Når den lagra verdien er verkeleg numerisk, sjå etter ein annan stad der klienten les eit namn. Ein EAP-konfigurasjon kan visa til ein server, ein profil importert frå eit anna verktøy kan bera sin eigen verdi, og eit tidlegare installasjonsprogram kan etterlata ein duplikatoppføring. Feltet i dialogen er ikkje alltid den einaste inngangen.

Attkoplingsmønsteret i Windows 7

Tråden bak denne feilen skildrar maskinar som kopla til éin gong og deretter feila ved eit seinare forsøk med 868, utan at noko vart endra i profilen. Bidragsytarar rapporterte at omstart av tenesta Remote Access Connection Manager eller å logge ut og inn igjen mellombels attoppretta tilkoplinga. Det er omvegar, ikkje ei påvist grunnårsak.

Behandle det mønsteret som ein separat hypotese. Ein omstart nullstiller klienttilstanden, så ein mellombels suksess etterpå bevisar ikkje 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 eit sett skiljande observasjonar, ikkje som ein diagnose. Den første rada er eit namneblem, den andre er klienttilstand, og den tredje er ein profil som aldri var riktig. Kvar av dei leier til ein annan person og ei anna retting.

Kva du bør samle inn til administratoren

Skriv ned profilnamnet, den lagra adressa, tunneltypen, nettet klienten var på, og om feilen følgde etter ein fråkopling. Den registreringa skil ein ekte oppslagsfeil frå den historiske attkoplingsåtferda utan at nokon må gjette. Ta òg vare på hendingsloggen til klienten rundt forsøket.

Omvegen frå eldre versjonar er bevis for at åtferda fanst, ikkje eit løfte om at den same tenesteomstarten vil reparere ein noverande maskin. Å byte ut eit dokumentert vertsnamn med ei bokstaveleg adresse er heller ikkje ein reparasjon.

Nokre profilar ventar ein serveridentitet som samsvarer med det konfigurerte namnet, så ein numerisk omveg kan bytte éin feil mot ein annan. Viss namnet må bli, reparer oppslagsvegen i staden for profilteksten. Noter uansett kva du endra og kvifor.

Relaterte artiklar