Windows VPN-felkoder: vilket steg misslyckades och vad du ska logga

Öppna Windows VPN-dialogen efter ett fel och den ger dig ett nummer och en mening, där meningen oftast är den mindre användbara hälften. Numret anger vilket steg i anslutningen som misslyckades, och steget avgör vilken logg, vilken inställning och vilket team du ska titta på härnäst. Att gå igenom stegen i ordning tar ungefär tio minuter och förhindrar den välbekanta sekvensen med att installera om adaptrar, byta protokoll och återställa stacken för att laga ett konto som aldrig fick ringa upp.

Läs numret som ett steg

En inbyggd anslutning passerar fyra milstolpar. Den når servern och upprättar en länk, förhandlar säkerhet, autentiserar användaren och tillämpar adressering och routing. Ett fel i varje sådant lämnar olika bevis, och en kod som hör till ett steg säger ingenting användbart om de andra.

Misstaget att undvika är att behandla koden som en allvarlighetsgrad. Ett länkfel och ett auktoriseringsfel läses båda som "kunde inte ansluta", och de har inget annat gemensamt. Allvarlighetsgrad säger hur brådskande något är; steget säger vad du ska öppna.

Steg ett: länken och uppringningsförsöket

829 betyder att den underliggande länken föll. Det säger inte om motparten slutade svara, om en mellanbox dödade sessionen eller om en policy på klienten stängde den. En uppringningsslutförandekod som 703 är ännu tidigare: försöket kom aldrig så långt att det fick en länk, vilket oftast pekar på profilen, tjänstens status eller en lokal policy.

Get-VpnConnection -Name 'Corp' | Select-Object Name,ServerAddress,TunnelType,AuthenticationMethod,ConnectionStatus
Test-NetConnection -ComputerName vpn.example.net -Port 443
Get-WinEvent -LogName Application -MaxEvents 200 | Where-Object ProviderName -match 'RasClient' | Select-Object -First 15 TimeCreated,Id,Message

Händelsefrågan är den del folk hoppar över. En klientpost med tidsstämpel och gränssnittsnamn är värd mer än dialogen, eftersom den säger om försöket ens lämnade maskinen. Ingen post och inget svar från lyssnaren är ett nåbarhetsproblem, och ingen klientredigering ändrar det.

Om samma profil fungerar på ett annat nätverk, stanna här. Koden beskriver ett vägvillkor och inte ett konfigurationsfel, och nästa användbara jämförelse är de två inspelningarna och inte ännu en ominstallation.

Steg två: PPP och miniportbindningen

720 ligger mellan länken och användaren. Tunneln kom upp och då kunde PPP-lagret inte förhandla fram en adress eller ett styrprotokoll, vilket ofta är ett bindningsproblem på klienten och inte en avvisad inloggning. Den skillnaden är kodens hela värde: den säger att inloggningen aldrig nåddes, så kontot är inte den misstänkta.

Get-NetAdapter -IncludeHidden | Where-Object InterfaceDescription -match 'WAN Miniport' | Select-Object Name,Status,ifIndex
Get-NetAdapterBinding | Where-Object ComponentID -match 'ms_pptp|ms_l2tp|ms_sstp|ms_agile' | Select-Object Name,ComponentID,Enabled

Att läsa de två utskrifterna är mer informativt än att återställa något som helst. En miniport som finns men inte startade, eller en protokollbindning som stängts av annan programvara, ger exakt det här stegets fel. Båda går att laga utan att röra resten av stacken. En fullständig återställning tar däremot bort adressering och filtertillstånd som inte hade något med felet att göra.

Steg tre: identitet och auktorisering

691 betyder att inloggningsuppgifterna avvisades. 649 betyder att kontot inte får ringa upp, och 812 betyder att en princip för fjärråtkomst avvisade anslutningen. Det är beslut, inte transportfel, och klienten kan bara rapportera dem.

Bevisen finns på andra sidan. Be gateway-operatören om försöket vid den tidsstämpeln och principen som matchade; fråga katalogägaren om kontot har uppringningsrättighet och om det finns i gruppen som principen kräver. Att byta tunneltyp eller installera om klienten kan inte ändra ett beslut som fattats om en identitet.

En användbar vana i detta steg är att skriva den exakta kontosträngen i ärendet, inklusive eventuellt domänprefix. Förvånansvärt många 691-fall är sparade inloggningsuppgifter för fel domän, och det syns i kontosträngen och inte i protokollinställningarna.

Steg fyra: ansluten, och ingenting fungerar

En anslutning kan slutföras och ändå vara oanvändbar. Den har en adress, klienten rapporterar framgång och varje begäran från programmet tar timeout. Ingenting i dialogen speglar det, och det finns ingen kod att slå upp. Vid den punkten är dialogen slut och de användbara bevisen finns någon annanstans.

Get-NetRoute -DestinationPrefix 10.24.0.0/16 | Select-Object DestinationPrefix,NextHop,InterfaceAlias
Resolve-DnsName files.corp.example.internal
Test-NetConnection -ComputerName 10.24.6.15 -Port 445

Om rutten saknas har servern inte skjutit dit den eller klienten har tappat den. Om rutten finns och namnet misslyckas är uppslagningen problemet. Om båda fungerar och programmet ändå misslyckas är du förbi tunneln och inne i programmets egen konfiguration.

Håll ändringarna till ett lager per test. Varje redigering före nästa försök blir en del av kontexten för nästa kod, och en kod som beskriver din senaste ändring är sämre än ingen kod alls.

Ett försök, en ändring, en post

Vilket steg det än gäller bör posten innehålla koden, meddelandet, profilnamnet, tidsstämpeln och nätverket du var på. Fem fält, och vart och ett av dem finns redan framför dig i dialogen eller klientloggen. Den uppsättningen är liten nog att klistra in i ett ärende och specifik nog för att någon annan ska kunna återskapa den.

Sätt sedan den tidsstämpeln bredvid posten på andra sidan. Tabellen nära sidans överkant säger vilket steg som äger varje avvikelse. Utan den andra posten snävar koden bara in sökningen; med den är steget avgjort. Jämförelsen är det som gör ett nummer till en diagnos och inte till en gissning.

Den vanan täcker nästan varje inbyggt Windows VPN-fel, och ingen av grenarna kräver ominstallation av något. Dialogen berättade hela tiden vilket du hade; arbetet ligger i att vägra behandla dem alla som samma problem.