Windows VPN ansluter inte? Matcha koden mot händelseloggen

I fredags fungerade det. På måndagen svarar samma Windows-klient med en dialog som säger att anslutningsförsöket misslyckades, och meningen under är en du redan har sett för ett dussin orelaterade problem. Den dialogen är slutet på en kedja, inte början. Windows döljer steget där försöket faktiskt dog, och två små bevis namnger det: den numeriska resultatkoden och en RasClient-händelse från samma minut. Här är ordningen jag använder — fäst försöket, läs koden, hämta händelsen och ändra sedan exakt ett lager.

Dialogtexten är det sista steget, inte orsaken

Meningen du läser väljs efter att försöket redan har rullats upp. "Anslutningen avbröts av fjärrdatorn innan anslutningen upprättades" visas när en server lägger på mitt i förhandlingen, när IPsec misslyckades innan ditt användarnamn ens skickades, och när en princip avvisade tunneln direkt. Tre olika ägare, en mening. Behandla formuleringen som en symptomklass och låt den inte styra något förrän koden håller med om den.

Det du fortfarande kan fästa är själva försöket. Skriv ned anslutningens namn, tunneltypen som sparats i profilen — PPTP, L2TP/IPsec, SSTP eller IKEv2 —, tiden till sekunden och koden. Om du inte är säker på vilket protokoll som faktiskt körde, öppna %APPDATA%\Microsoft\Network\Connections\Pbk\rasphone.pbk och läs posten i stället för att lita på minnet; en profil som återanvänds för ett nytt protokoll behåller sitt gamla visningsnamn.

Läs numret innan du läser orden

Koder faller i tre steg, och steget spelar större roll än den exakta formuleringen: ett autentiseringsutbyte som nåddes och avvisades, en server som aldrig svarade, eller en förhandling som kollapsade efter att länken kom upp. 691 är den första sorten — kontrollen av inloggningsuppgifter körde och misslyckades, vare sig det berodde på ett dåligt lösenord, ett låst eller utgånget konto, eller ett autentiseringsprotokoll som servern inte accepterar. 812 är också en avvisning, men med giltiga inloggningsuppgifter: en princip på servern för fjärråtkomst beslutade mot dig. Microsoft underhåller den kanoniska lista över felkoder för uppringnings- och VPN-anslutningar, och det är värt att läsa ditt nummer där innan du söker i meddelandetexten.

809 är den motsatta klassen: ingenting kom tillbaka. Det är ett vägproblem — TCP 443 filtrerat för SSTP, GRE blockerat för PPTP, UDP 500 och 4500 eller ESP släppt för IPsec-genomgång. Ett nytt lösenord kan inte åtgärda det, och inte ett nytt certifikat heller. 720 betyder att länken kom upp och att PPP aldrig slutförde förhandlingen, vilket pekar på en protokollmissmatchning eller en server som inte kunde tilldela en adress. 789, eller 13801 på IKEv2, är identitet inuti IPsec: ett certifikat vars subjekt inte stämmer med namnet du ringer, en ej betrodd kedja, eller en fördelad nyckel som skiljer sig mellan de två ändarna.

Hämta RasClient-händelsen för samma minut

I Händelsevisaren är Windows Logs > Application filtrerat på källa RasClient den första platsen att titta på. Microsofts beskrivning av fel 720 pekar på händelse 20227 i den loggen. Samma leverantör ger ut andra identifierare för andra utfall, så läs meddelandet och den inbäddade resultatkoden i stället för att behandla ID:t som diagnosen; en generisk dialog plus en 20227 som bär 720 är redan en mycket snävare historia.

Från PowerShell, utan att klicka genom GUI:t:

Get-WinEvent -FilterHashtable @{
  LogName      = 'Application'
  ProviderName = 'RasClient'
  StartTime    = (Get-Date).AddMinutes(-15)
} | Format-List TimeCreated, Id, Message

Ett tomt resultat är informativt. Det betyder oftast att uppringningen aldrig kom tillräckligt långt för att RAS skulle logga något, eller att programvaran som misslyckades inte är den inbyggda klienten alls — tredjepartsklienter har sin egen diagnostik och skriver ofta inget i Application-loggen. Kontrollera leverantörens logg innan du drar slutsatsen att händelseloggningen är trasig.

Bygg en tidslinje i stället för en hög med händelser

Återförsöksslingor skapar brus. Fem automatiska återanslutningar lämnar ett kluster av händelser, och frestelsen är att läsa dem som en enda sekvens med en enda orsak. Det är fem separata försök, och bara några av dem nådde en server. Ta ett fönster på två eller tre minuter, ett anslutningsnamn, och lista varje händelse med sin egen kod innan du tolkar något.

Fråga sedan var försöket stannade. När gatewayen eller autentiseringsbackend inte har någon post för den tidsstämpeln nådde klienten aldrig fram, och du tittar på ett tillgänglighetsproblem. När backend visar en begäran och en avvisning fattades beslutet där, och klassen inloggningsuppgifter eller princip gäller. Jämför klockor innan du jämför tider: klienter rapporterar lokal tid, många gatewayer loggar i UTC, och en förskjutning får ett perfekt korrelerat par att se orelaterat ut.

För en repeterbar inspelning, ring upp från kommandoraden och låt den skriva ut resultatet:

rasdial "Office VPN"
rasdial "Office VPN" /disconnect

Konsolen visar numret som GUI:t döljer bakom vänlig text, och att köra det två gånger berättar om koden är stabil eller periodisk.

Vad varje steg säger att du ska ändra

Att namnge steget är bara användbart om det krymper ändringsuppsättningen till ett lager:

• 691 — autentisering: den EAP-metod klienten erbjuder mot den servern accepterar, kontostatus, lösenordsutgång, tillstånd för inringning.
• 812 — serverprincip: principen för fjärråtkomst eller NPS-regeln som passar den här användaren och det här tidsfönstret.
• 809 — tillgänglighet: brandväggsregler på vägen, NAT och protokollgenomgång, porten som den valda tunneltypen behöver.
• 720 — PPP-förhandling: missmatchning i autentiseringsprotokoll, adresstilldelning, en PPP-inställning på serversidan.
• 789 / 13801 — IPsec-identitet: certifikatets subjekt mot namnet du ringer, förtroendekedja, fördelad nyckel.

Ändra en av dem, testa samma profil igen och skriv ned den nya koden. En annan kod efter en ändring är framsteg snarare än motsägelse: du flyttade felet till ett senare steg, och det är så reparation av ett flerstegshandslag ser ut. Det du inte bör göra är att ändra brandväggen, certifikatet och lösenordet i en enda sittning och sedan ge äran till den som kom sist.

Dela bevisen, inte miljön

Händelsemeddelanden är rikare än de ser ut. De bär anslutningsnamnet, kontot, ofta gatewayens interna namn eller adress, och ibland ett certifikatavtryck. Behåll originalet där det hör hemma, och bygg en separat redigerad kopia för alla andra; att skriva om tidslinjen ur minnet tappar just de detaljer som gör den användbar.

En överlämning som blir gjord behöver fem fält: koden, steget den hör till, klienten och tunneltypen, tidsstämpeln med sin tidszon, och om gatewayen såg begäran alls. Allt annat är valfritt. Med de fem kan nästa person skilja en diskussion om inloggningsuppgifter från en om routning utan att upprepa undersökningen.

Innan du stänger något, spela upp försöket på samma profil och bekräfta var koden landar nu. En framgång avslutar det; ett annat fel betyder att det ursprungliga steget är reparerat och du har nästa i handen.