Dialogen siger, at servernavnet ikke kunne slås op, og det profilfelt, du stirrer på, er en adresse. Den kombination er ikke en modsætning: klienten slår noget andet op end den værdi, du tror, den læser. Find ud af, hvad den faktisk ringer til, før du konkluderer, at DNS er i stykker. Rækkefølgen af klientens egne trin fortæller dig, hvor du skal kigge.

Klienten slår et navn op, før den ringer

En indbygget Windows VPN-forbindelse læser sin profil, slår serveradressen op, starter tunnelen og godkender først derefter. Fejl 868 hører til andet trin. Fordi de senere trin aldrig kører, kan dialogen se ud som et legitimationsproblem, når opslaget fejlede først.

Den rækkefølge er nyttig, fordi den indsnævrer det lag, der skal undersøges. Når den samme profil virker fra et netværk og fejler fra et andet, er forskellen som regel navneopslag og ikke tunneltypen eller kontoen. Test opslaget der, hvor fejlen opstår, ikke der, hvor profilen blev oprettet.

Hvilket navn, når feltet viser en adresse

Læs den gemte værdi i stedet for visningsnavnet. Etiketten på en forbindelse er ikke dens serveradresse, og to poster med lignende etiketter sender dig efter den forkerte:

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

Hvis profilen er klargjort til alle brugere, skal du også forespørge det omfang med -AllUserConnection. Slå derefter præcis den værdi op, som kommandoen udskrev, fra det netværk, hvor fejlen opstår. Brug operatørens dokumenterede gateway, ikke det interne applikationsnavn, som først slås op, når tunnelen er oppe. Den anden forespørgsel fejler af en forventet grund og fortæller dig intet om opkaldet:

Resolve-DnsName vpn.example.com

Når den gemte værdi er virkelig numerisk, skal du lede efter et andet sted, hvor klienten læser et navn. En EAP-konfiguration kan referere til en server, en profil importeret fra et andet værktøj kan bære sin egen værdi, og en tidligere installationsprogram kan efterlade en dubletpost. Feltet i dialogen er ikke altid det eneste input.

Genopkoblingsmønstret i Windows 7

Tråden bag denne fejl beskriver maskiner, der oprettede forbindelse én gang og derefter fejlede ved et senere forsøg med 868, uden at noget blev ændret i profilen. Bidragydere rapporterede, at genstart af tjenesten Remote Access Connection Manager eller log ud og ind igen midlertidigt genoprettede forbindelsen. Det er omveje, ikke en påvist grundårsag.

Behandl det mønster som en separat hypotese. En genstart nulstiller klientens tilstand, så en midlertidig succes bagefter beviser ikke, at DNS-posten var forkert:

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

Læs tabellen som et sæt skelnelige observationer, ikke som en diagnose. Den første række er et navneproblem, den anden er klienttilstand, og den tredje er en profil, der aldrig var korrekt. Hver af dem fører til en anden person og en anden rettelse.

Hvad du skal samle til administratoren

Skriv profilnavnet, den gemte adresse, tunneltypen, det netværk klienten var på, og om fejlen fulgte efter en afbrydelse. Den registrering adskiller et rigtigt opslagsfejl fra den historiske genopkoblingsadfærd, uden at nogen skal gætte. Gem også klientens hændelseslog omkring forsøget.

Omvejen fra ældre builds er et bevis for, at adfærden fandtes, ikke et løfte om, at den samme tjenestegenstart vil reparere en nuværende maskine. At erstatte et dokumenteret værtsnavn med en bogstavelig adresse er heller ikke en reparation.

Nogle profiler forventer en serveridentitet, der matcher det konfigurerede navn, så en numerisk omvej kan bytte én fejl for en anden. Hvis navnet skal blive, skal du rette opslagsvejen i stedet for profilteksten. Under alle omstændigheder skal du notere, hvad du ændrede og hvorfor.

Relaterede artikler