Windows VPN forbinder ikke? Match koden med hændelsesloggen

Det virkede fredag. Om mandagen svarer den samme Windows-klient med en dialog, der siger, at forbindelsesforsøget mislykkedes, og sætningen nedenunder er en, du allerede har set til et dusin urelaterede problemer. Den dialog er enden af en kæde, ikke begyndelsen. Windows skjuler det trin, hvor forsøget faktisk døde, og to små beviser navngiver det: den numeriske resultatkode og én RasClient-hændelse fra det samme minut. Her er den rækkefølge, jeg bruger — fastlås forsøget, læs koden, hent hændelsen, og skift derefter præcis ét lag.

Dialogteksten er det sidste skridt, ikke årsagen

Sætningen, du læser, vælges, efter at forsøget allerede er rullet tilbage. "Forbindelsen blev afsluttet af fjerncomputeren, før forbindelsen blev oprettet" vises, når en server lægger på midt i forhandlingen, når IPsec fejlede, før dit brugernavn overhovedet blev sendt, og når en politik afviste tunnelen blankt. Tre forskellige ejere, én sætning. Behandl formuleringen som en symptomklasse, og lad den ikke styre noget, før koden er enig med den.

Det, du stadig kan fastlåse, er selve forsøget. Skriv forbindelsens navn ned, den tunneltype der er gemt i profilen — PPTP, L2TP/IPsec, SSTP eller IKEv2 — tiden til sekundet og koden. Hvis du ikke er sikker på, hvilken protokol der faktisk kørte, så åbn %APPDATA%\Microsoft\Network\Connections\Pbk\rasphone.pbk og læs posten i stedet for at stole på hukommelsen; en profil, der genbruges til en ny protokol, beholder sit gamle viste navn.

Læs tallet, før du læser ordene

Koder falder i tre trin, og trinnet betyder mere end den præcise formulering: en godkendelsesudveksling, der blev nået og afvist, en server, der aldrig svarede, eller en forhandling, der kollapsede, efter at linket kom op. 691 er den første slags — legitimationskontrollen kørte og fejlede, hvad enten det skyldtes en dårlig adgangskode, en låst eller udløbet konto eller en godkendelsesprotokol, som serveren ikke accepterer. 812 er også en afvisning, men med gyldige legitimationsoplysninger: en politik på serveren for fjernadgang besluttede imod dig. Microsoft vedligeholder den kanoniske liste over fejlkoder til opkalds- og VPN-forbindelser, og det er værd at læse dit nummer der, før du søger i meddelelsesteksten.

809 er den modsatte klasse: der kom intet tilbage. Det er et rutevejsproblem — TCP 443 filtreret for SSTP, GRE blokeret for PPTP, UDP 500 og 4500 eller ESP droppet for IPsec-gennemgang. En ny adgangskode kan ikke løse det, og et nyt certifikat kan heller ikke. 720 betyder, at linket kom op, og at PPP aldrig færdiggjorde forhandlingen, hvilket peger på en protokolukompatibilitet eller en server, der ikke kunne tildele en adresse. 789, eller 13801 på IKEv2, er identitet inde i IPsec: et certifikat, hvis emne ikke matcher det navn, du ringer til, en ikke-betroet kæde eller en forudelt nøgle, der er forskellig i de to ender.

Hent RasClient-hændelsen for det samme minut

I Hændelsesfremviser er Windows Logs > Application filtreret på kilden RasClient det første sted at kigge. Microsofts beskrivelse af fejl 720 peger på hændelse 20227 i den log. Den samme udbyder udsender andre id'er til andre udfald, så læs meddelelsen og den indlejrede resultatkode i stedet for at behandle id'et som diagnosen; en generisk dialog plus en 20227, der bærer 720, er allerede en meget snævrere historie.

Fra PowerShell, uden at klikke gennem 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 betyder normalt, at opkaldet aldrig kom langt nok til, at RAS kunne logge noget, eller at det software, der fejlede, slet ikke er den oprindelige klient — tredjepartsklienter holder deres egen diagnosticering og skriver ofte intet i Application-loggen. Tjek leverandørens log, før du konkluderer, at hændelseslogning er i stykker.

Byg én tidslinje i stedet for en bunke hændelser

Genforsøgsløkker skaber støj. Fem automatiske genopkoblinger efterlader en klynge af hændelser, og fristelsen er at læse dem som én sekvens med én årsag. De er fem separate forsøg, og kun nogle af dem nåede en server. Tag et vindue på to eller tre minutter, ét forbindelsesnavn, og list hver hændelse med sin egen kode, før du fortolker noget af det.

Spørg så, hvor forsøget stoppede. Når gatewayen eller godkendelses-backenden ikke har nogen post for det tidsstempel, nåede klienten aldrig derhen, og du ser på et tilgængelighedsproblem. Når backenden viser en anmodning og en afvisning, blev beslutningen taget der, og legitimations- eller politikklassen gælder. Sammenlign ure, før du sammenligner tider: klienter rapporterer lokal tid, mange gatewaye logger UTC, og en forskydning vil få et perfekt korreleret par til at se urelateret ud.

For en gentagelig optagelse, ring op fra kommandolinjen og lad den udskrive resultatet:

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

Konsollen viser det nummer, som GUI'en skjuler bag venlig tekst, og at køre det to gange fortæller dig, om koden er stabil eller periodisk.

Hvad hvert trin fortæller dig, at du skal ændre

Det er kun nyttigt at navngive trinnet, hvis det skrumper ændringssættet til ét lag:

• 691 — godkendelse: den EAP-metode, klienten tilbyder, over for den, serveren accepterer, kontostatus, adgangskodeudløb, tilladelse til indgående opkald.
• 812 — serverpolitik: den fjernadgangspolitik eller NPS-regel, der matcher denne bruger og dette tidsvindue.
• 809 — tilgængelighed: firewallregler på ruten, NAT og protokolgennemgang, den port, som den valgte tunneltype har brug for.
• 720 — PPP-forhandling: uoverensstemmelse i godkendelsesprotokol, adressetildeling, en PPP-indstilling på serversiden.
• 789 / 13801 — IPsec-identitet: certifikatemne over for det navn, du ringer til, betroet kæde, forudelt nøgle.

Skift en af dem, test den samme profil igen, og skriv den nye kode ned. En anden kode efter en ændring er fremskridt snarere end en selvmodsigelse: du flyttede fejlen til et senere trin, og det er sådan, det ser ud at rette et flertrins-håndtryk. Det, du ikke bør gøre, er at ændre firewallen, certifikatet og adgangskoden i én omgang og derefter give æren til den, der kom sidst.

Del beviserne, ikke miljøet

Hændelsesmeddelelser er rigere, end de ser ud. De bærer forbindelsesnavnet, kontoen, ofte gatewayens interne navn eller adresse og nogle gange et certifikatfingeraftryk. Behold originalen, hvor den hører til, og byg en separat redigeret kopi til alle andre; at skrive tidslinjen om fra hukommelsen mister netop de detaljer, der gør den nyttig.

En overdragelse, der bliver arbejdet på, kræver fem felter: koden, det trin den hører til, klienten og tunneltypen, tidsstemplet med dets tidszone, og om gatewayen overhovedet så anmodningen. Alt andet er valgfrit. Med de fem kan den næste skelne en legitimationsdiskussion fra en routingdiskussion uden at gentage undersøgelsen.

Før du lukker noget, skal du gentage forsøget på den samme profil og bekræfte, hvor koden lander nu. En succes afslutter det; en anden fejl betyder, at det oprindelige trin er rettet, og du har det næste i hånden.