Windows VPN kobler ikke til? Match koden mot hendelsesloggen

Det fungerte på fredag. På mandag svarer den samme Windows-klienten med en dialog som sier at tilkoblingsforsøket mislyktes, og setningen under er en du allerede har sett for et dusin urelaterte problemer. Den dialogen er slutten på en kjede, ikke begynnelsen. Windows skjuler trinnet der forsøket faktisk døde, og to små bevis navngir det: den numeriske resultatkoden og én RasClient-hendelse fra samme minutt. Her er rekkefølgen jeg bruker — fest forsøket, les koden, hent hendelsen, og endre deretter nøyaktig ett lag.

Dialogteksten er det siste trinnet, ikke årsaken

Setningen du leser, velges etter at forsøket allerede er rullet ut. "Tilkoblingen ble avsluttet av fjernmaskinen før tilkoblingen ble opprettet" vises når en server legger på midt i forhandlingen, når IPsec feilet før brukernavnet ditt ble sendt i det hele tatt, og når en policy avviste tunnelen blankt. Tre forskjellige eiere, én setning. Behandle formuleringen som en symptomklasse og la den ikke styre noe før koden er enig med den.

Det du fortsatt kan feste, er selve forsøket. Skriv ned navnet på tilkoblingen, tunneltypen som er lagret i profilen — PPTP, L2TP/IPsec, SSTP eller IKEv2 —, tiden til sekundet og koden. Hvis du ikke er sikker på hvilken protokoll som faktisk kjørte, åpne %APPDATA%\Microsoft\Network\Connections\Pbk\rasphone.pbk og les oppføringen i stedet for å stole på hukommelsen; en profil som gjenbrukes for en ny protokoll beholder det gamle visningsnavnet sitt.

Les tallet før du leser ordene

Koder faller i tre trinn, og trinnet betyr mer enn den nøyaktige formuleringen: en autentiseringsutveksling som ble nådd og avvist, en server som aldri svarte, eller en forhandling som kollapset etter at linken kom opp. 691 er den første typen — kontrollen av påloggingsinformasjon kjørte og feilet, enten på grunn av et dårlig passord, en låst eller utløpt konto, eller en autentiseringsprotokoll serveren ikke godtar. 812 er også en avvisning, men med gyldig påloggingsinformasjon: en policy på serveren for ekstern tilgang bestemte mot deg. Microsoft vedlikeholder den kanoniske listen over feilkoder for oppringing og VPN-tilkoblinger, og det er verdt å lese nummeret ditt der før du søker i meldingsteksten.

809 er den motsatte klassen: ingenting kom tilbake. Det er et ruteproblem — TCP 443 filtrert for SSTP, GRE blokkert for PPTP, UDP 500 og 4500 eller ESP droppet for IPsec-gjennomgang. Et nytt passord kan ikke fikse det, og et nytt sertifikat kan heller ikke. 720 betyr at linken kom opp og at PPP aldri fullførte forhandlingen, noe som peker på en protokollukompatibilitet eller en server som ikke kunne tildele en adresse. 789, eller 13801 på IKEv2, er identitet inne i IPsec: et sertifikat der emnet ikke samsvarer med navnet du ringer, en ikke-klarert kjede, eller en forhåndsdelt nøkkel som er forskjellig i de to endene.

Hent RasClient-hendelsen for det samme minuttet

I Hendelsesvisning er Windows Logs > Application filtrert på kilde RasClient det første stedet å se. Microsofts beskrivelse av feil 720 peker på hendelse 20227 i den loggen. Den samme leverandøren sender ut andre identifikatorer for andre utfall, så les meldingen og den innebygde resultatkoden i stedet for å behandle ID-en som diagnosen; en generisk dialog pluss en 20227 som bærer 720 er allerede en mye smalere historie.

Fra PowerShell, uten å klikke gjennom GUI-en:

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

Et tomt resultat er informativt. Det betyr vanligvis at oppringingen aldri kom langt nok til at RAS loggførte noe, eller at programvaren som feilet ikke er den opprinnelige klienten i det hele tatt — tredjepartsklienter holder sin egen diagnostikk og skriver ofte ingenting i Application-loggen. Sjekk loggen til leverandøren før du konkluderer med at hendelseslogging er ødelagt.

Bygg én tidslinje i stedet for en haug med hendelser

Gjenforsøksløkker skaper støy. Fem automatiske gjenoppkoblinger etterlater en klynge hendelser, og fristelsen er å lese dem som én sekvens med én årsak. De er fem separate forsøk, og bare noen av dem nådde en server. Ta et vindu på to eller tre minutter, ett tilkoblingsnavn, og list opp hver hendelse med sin egen kode før du tolker noe av det.

Spør så hvor forsøket stoppet. Når gatewayen eller autentiseringsbackenden ikke har noen oppføring for det tidsstempelet, nådde klienten aldri frem, og du ser på et tilgjengelighetsproblem. Når backenden viser en forespørsel og en avvisning, ble beslutningen tatt der, og klassen påloggingsinformasjon eller policy gjelder. Sammenlign klokker før du sammenligner tider: klienter rapporterer lokal tid, mange gatewayer logger i UTC, og en forskyvning vil få et perfekt korrelert par til å se urelatert ut.

For en repeterbar registrering, ring opp fra kommandolinjen og la den skrive ut resultatet:

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

Konsollen viser nummeret som GUI-en skjuler bak vennlig tekst, og å kjøre det to ganger forteller deg om koden er stabil eller periodisk.

Hva hvert trinn sier du skal endre

Det er bare nyttig å navngi trinnet hvis det krymper endringssettet til ett lag:

• 691 — autentisering: EAP-metoden klienten tilbyr mot den serveren godtar, kontostatus, passordutløp, tillatelse til innringing.
• 812 — serverpolicy: policyen for ekstern tilgang eller NPS-regelen som passer denne brukeren og dette tidsvinduet.
• 809 — tilgjengelighet: brannmurregler på ruten, NAT og protokollgjennomgang, porten den valgte tunneltypen trenger.
• 720 — PPP-forhandling: uoverensstemmelse i autentiseringsprotokoll, adressetildeling, en PPP-innstilling på serversiden.
• 789 / 13801 — IPsec-identitet: sertifikatemne mot navnet du ringer, tillitskjede, forhåndsdelt nøkkel.

Endre en av dem, test den samme profilen på nytt, og skriv ned den nye koden. En annen kode etter en endring er fremgang snarere enn en selvmotsigelse: du flyttet feilen til et senere trinn, og det er slik reparasjon av et flertrinns håndtrykk ser ut. Det du ikke skal gjøre, er å endre brannmuren, sertifikatet og passordet i én økt og deretter gi æren til den som kom sist.

Del bevisene, ikke miljøet

Hendelsesmeldinger er rikere enn de ser ut. De bærer tilkoblingsnavnet, kontoen, ofte gatewayens interne navn eller adresse, og noen ganger et sertifikatfingertrykk. Behold originalen der den hører hjemme, og bygg en egen redigert kopi for alle andre; å skrive tidslinjen på nytt fra hukommelsen mister nettopp detaljene som gjør den nyttig.

En overlevering som blir jobbet med trenger fem felt: koden, trinnet den hører til, klienten og tunneltypen, tidsstempelet med tidssonen sin, og om gatewayen så forespørselen i det hele tatt. Alt annet er valgfritt. Med de fem kan neste person skille en diskusjon om påloggingsinformasjon fra en rutediskusjon uten å gjenta undersøkelsen.

Før du lukker noe, spill av forsøket på den samme profilen og bekreft hvor koden lander nå. En suksess avslutter det; en annen feil betyr at det opprinnelige trinnet er rettet og du har det neste i hånden.