Windows-VPN verbind nie? Pas die kode by die gebeurtenislog

'n Windows-VPN-dialoog verberg die stadium wat misluk het. Lees die resultaatkode, haal die RasClient-gebeurtenis vir daardie poging en verander net die laag wat gebreek het.

Dit het Vrydag gewerk. Maandag antwoord dieselfde Windows-kliënt met 'n dialoog wat sê die verbindingspoging het misluk, en die sin daaronder is een wat jy al vir 'n dosyn onverwante probleme gesien het. Daardie dialoog is die einde van 'n ketting, nie die begin daarvan nie. Windows verberg die stadium waar die poging werklik dood is, en twee klein stukke bewyse noem dit: die numeriese resultaatkode en een RasClient-gebeurtenis uit daardie selfde minuut. Hier is die volgorde wat ek gebruik — pen die poging vas, lees die kode, haal die gebeurtenis, verander dan presies een laag.

Die dialoogteks is die laaste stap, nie die oorsaak nie

Die sin wat jy lees, word gekies nadat die poging al afgewikkel is. "Die verbinding is deur die afgeleë rekenaar beëindig voordat die verbinding tot stand gekom het" verskyn wanneer 'n bediener midde-in die onderhandeling opgehang het, wanneer IPsec misluk het voordat jou gebruikersnaam ooit gestuur is, en wanneer 'n beleid die tonnel heeltemal geweier het. Drie verskillende eienaars, een sin. Behandel die bewoording as 'n simptoomklas en laat dit niks stuur voordat die kode daarmee saamstem nie.

Wat jy nog kan vaspen, is die poging self. Skryf die verbindingsnaam neer, die tonneltipe wat in die profiel gestoor is — PPTP, L2TP/IPsec, SSTP of IKEv2 — die tyd tot op die sekonde, en die kode. As jy nie seker is watter protokol werklik geloop het nie, maak %APPDATA%\Microsoft\Network\Connections\Pbk\rasphone.pbk oop en lees die inskrywing eerder as om jou geheue te vertrou; 'n profiel wat vir 'n nuwe protokol hergebruik word, hou sy ou vertoonnaam.

Lees die nommer voordat jy die woorde lees

Kodes val in drie stadiums, en die stadium maak meer saak as die presiese bewoording: 'n verifikasie-uitruiling wat bereik en geweier is, 'n bediener wat nooit geantwoord het nie, of 'n onderhandeling wat in duie gestort het nadat die skakel opgekom het. 691 is die eerste soort — die geloofsbriefkontrole het geloop en gefaal, hetsy weens 'n slegte wagwoord, 'n geslote of vervalde rekening, of 'n verifikasieprotokol wat die bediener nie aanvaar nie. 812 is ook 'n weiering, maar met geldige geloofsbriewe: 'n beleid op die afgeleë toegang-bediener het teen jou besluit. Microsoft hou die kanonieke lys van inbel- en VPN-foutkodes, en dit is die moeite werd om jou nommer daar te lees voordat jy die boodskapteks soek.

809 is die teenoorgestelde klas: niks het teruggekom nie. Dit is 'n padprobleem — TCP 443 gefiltreer vir SSTP, GRE geblokkeer vir PPTP, UDP 500 en 4500 of ESP laat val vir IPsec-deurvoer. 'n Nuwe wagwoord kan dit nie regmaak nie en 'n nuwe sertifikaat ook nie. 720 beteken die skakel het opgekom en PPP het nooit klaar onderhandel nie, wat op 'n protokolwanpassing of 'n bediener wat nie 'n adres kon toeken nie, dui. 789, of 13801 op IKEv2, is identiteit binne IPsec: 'n sertifikaat wie se onderwerp nie by die naam wat jy skakel pas nie, 'n onvertroude ketting, of 'n vooraf-gedeelde sleutel wat tussen die twee kante verskil.

Haal die RasClient-gebeurtenis vir daardie selfde minuut

In Gebeurteniskyker is Windows Logs > Application gefiltreer op bron RasClient die eerste plek om te kyk. Microsoft se beskrywing van fout 720 wys na gebeurtenis 20227 in daardie log. Dieselfde verskaffer lewer ander identifiseerders vir ander uitkomste, so lees die boodskap en die ingebedde resultaatkode eerder as om die ID as die diagnose te behandel; 'n generiese dialoog plus 'n 20227 wat 720 dra, is al 'n veel smaller storie.

Vanuit PowerShell, sonder om deur die GUI te klik:

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

'n Leë resultaat is insiggewend. Dit beteken gewoonlik die inbel het nooit ver genoeg gekom vir RAS om enigiets te log nie, of dat die sagteware wat gefaal het glad nie die inheemse kliënt is nie — derdeparty-kliënte hou hul eie diagnostiek en skryf dikwels niks na die Application-log nie. Kyk in die verskaffer se log voordat jy aflei dat gebeurtenislogtering stukkend is.

Bou een tydlyn in plaas van 'n hoop gebeurtenisse

Herprobeer-lusse maak geraas. Vyf outomatiese herverbindings laat 'n groep gebeurtenisse, en die versoeking is om dit as een reeks met 'n enkele oorsaak te lees. Dit is vyf afsonderlike pogings, en net sommige daarvan het 'n bediener bereik. Neem 'n venster van twee of drie minute, een verbindingsnaam, en lys elke gebeurtenis met sy eie kode voordat jy enigiets daarvan interpreteer.

Vra dan waar die poging gestop het. Wanneer die poort of die verifikasie-agterkant geen rekord vir daardie tydstempel hou nie, het die kliënt dit nooit bereik nie, en jy kyk na 'n bereikbaarheidsprobleem. Wanneer die agterkant 'n versoek en 'n weiering wys, is die besluit daar geneem, en geld die geloofsbrief- of beleidsklas. Vergelyk klokke voordat jy tye vergelyk: kliënte rapporteer plaaslike tyd, baie poorte log UTC, en 'n afwyking sal 'n volkome gekorreleerde paar onverwant laat lyk.

Vir 'n herhaalbare vaslegging, inbel vanaf die opdragreël en laat dit die resultaat druk:

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

Die konsole wys die nommer wat die GUI agter vriendelike teks wegsteek, en om dit twee keer te hardloop sê jou of die kode stabiel of wisselvallig is.

Wat elke stadium jou sê om te verander

Om die stadium te benoem is net nuttig as dit die veranderingsstel tot een laag verklein:

  • 691 — verifikasie: die EAP-metode wat die kliënt bied teenoor die een wat die bediener aanvaar, rekeningtoestand, wagwoordverval, inbeltoestemming.
  • 812 — bedienerbeleid: die afgeleë toegang-beleid of NPS-reël wat by hierdie gebruiker en hierdie tydvenster pas.
  • 809 — bereikbaarheid: firewall-reëls op die pad, NAT en protokol-deurvoer, die poort wat die gekose tonneltipe nodig het.
  • 720 — PPP-onderhandeling: verifikasieprotokol-wanpassing, adrestoekenning, 'n PPP-instelling aan die bedienerkant.
  • 789 / 13801 — IPsec-identiteit: sertifikaatonderwerp teenoor die naam wat jy skakel, vertroueketting, vooraf-gedeelde sleutel.

Verander een van daardie dinge, toets dieselfde profiel weer, en skryf die nuwe kode neer. 'n Ander kode ná 'n verandering is vooruitgang eerder as 'n teenstrydigheid: jy het die faling na 'n later stadium geskuif, en dit is hoe die regmaak van 'n meervoudige-stadium-handdruk lyk. Wat jy nie moet doen nie, is om die firewall, die sertifikaat en die wagwoord in een sitting te verander en dan die een wat laaste gekom het, eer te gee.

Deel die bewyse, nie die omgewing nie

Gebeurtenisboodskappe is ryker as wat dit lyk. Hulle dra die verbindingsnaam, die rekening, dikwels die poort se interne naam of adres, en soms 'n sertifikaat-duimafdruk. Hou die oorspronklike waar dit hoort, en bou 'n aparte geredigeerde kopie vir enigiemand anders; om die tydlyn uit die geheue oor te tik, verloor juis die besonderhede wat dit nuttig maak.

'n Oordrag wat opgevolg word, het vyf velde nodig: die kode, die stadium waaraan dit behoort, die kliënt en tonneltipe, die tydstempel met sy tydsone, en of die poort die versoek hoegenaamd gesien het. Alles anders is opsioneel. Met daardie vyf kan die volgende persoon 'n geloofsbrief-argument van 'n roetering-argument onderskei sonder om die ondersoek te herhaal.

Voordat jy iets afsluit, speel die poging op dieselfde profiel weer en bevestig waar die kode nou beland. 'n Sukses beëindig dit; 'n ander faling beteken die oorspronklike stadium is reggemaak en jy het die volgende een in die hand.

Verwante artikels