Dialogrutan säger att servernamnet inte kunde slås upp, och profilfältet du stirrar på är en adress. Den kombinationen är inte en motsägelse: klienten slår upp något annat än det värde du tror att den läser. Ta reda på vad den faktiskt ringer innan du drar slutsatsen att DNS är trasigt. Ordningen för klientens egna steg visar var du ska titta.

Klienten slår upp ett namn innan den ringer

En inbyggd Windows VPN-anslutning läser sin profil, slår upp serveradressen, startar tunneln och autentiserar först därefter. Fel 868 hör till det andra steget. Eftersom de senare stegen aldrig körs kan dialogrutan se ut som ett inloggningsproblem när uppslaget misslyckades först.

Den ordningen är användbar eftersom den begränsar lagret som ska undersökas. När samma profil fungerar från ett nät och misslyckas från ett annat är skillnaden vanligtvis namnuppslag och inte tunneltypen eller kontot. Testa uppslaget där felet uppstår, inte där profilen skapades.

Vilket namn, när fältet visar en adress

Läs det sparade värdet i stället för visningsnamnet. Etiketten för en anslutning är inte dess serveradress, och två poster med liknande etiketter skickar dig efter den felaktiga:

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

Om profilen är förberedd för alla användare, fråga även om det omfånget med -AllUserConnection. Slå sedan upp exakt det värde som kommandot skrev ut, från nätet där felet uppstår. Använd operatörens dokumenterade gateway, inte det interna applikationsnamnet som först slås upp när tunneln är uppe. Den andra frågan misslyckas av en förväntad anledning och säger dig ingenting om uppringningen:

Resolve-DnsName vpn.example.com

När det sparade värdet verkligen är numeriskt, leta efter en andra plats där klienten läser ett namn. En EAP-konfiguration kan referera till en server, en profil importerad från ett annat verktyg kan bära sitt eget värde, och ett tidigare installationsprogram kan lämna en dubblettpost. Fältet i dialogrutan är inte alltid den enda indatan.

Återanslutningsmönstret i Windows 7

Tråden bakom det här felet beskriver maskiner som anslöt en gång och sedan misslyckades vid ett senare försök med 868, utan att något ändrades i profilen. Bidragsgivare rapporterade att omstart av tjänsten Remote Access Connection Manager eller att logga ut och in igen tillfälligt återställde anslutningen. Det är kringgångar, inte en påvisad grundorsak.

Behandla det mönstret som en separat hypotes. En omstart nollställer klientens tillstånd, så en tillfällig framgång efteråt bevisar inte att DNS-posten var fel:

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 en uppsättning särskiljande observationer, inte som en diagnos. Den första raden är ett namnproblem, den andra är klienttillstånd och den tredje är en profil som aldrig var korrekt. Var och en leder till en annan person och en annan åtgärd.

Vad du bör samla in till administratören

Skriv ned profilnamnet, den sparade adressen, tunneltypen, nätet klienten var på och om felet följde på en frånkoppling. Den anteckningen skiljer ett verkligt uppslagsfel från det historiska återanslutningsbeteendet utan att någon behöver gissa. Spara också klientens händelselogg kring försöket.

Kringgången från äldre versioner är bevis för att beteendet fanns, inte ett löfte att samma tjänsteomstart reparerar en nuvarande maskin. Att ersätta ett dokumenterat värdnamn med en bokstavlig adress är inte heller en reparation.

Vissa profiler förväntar sig en serveridentitet som matchar det konfigurerade namnet, så en numerisk kringgång kan byta ett fel mot ett annat. Om namnet måste stanna, reparera uppslagsvägen i stället för profiltexten. Anteckna hur som helst vad du ändrade och varför.

Relaterade artiklar