Windows VPN maakt geen verbinding? Koppel de code aan het gebeurtenislogboek

Vrijdag werkte het. Maandag antwoordt dezelfde Windows-client met een dialoog die zegt dat de verbindingspoging is mislukt, en de zin eronder is er een die je al hebt gezien bij een dozijn ongerelateerde problemen. Die dialoog is het einde van een keten, niet het begin. Windows verbergt de fase waarin de poging echt stierf, en twee kleine bewijzen noemen die: de numerieke resultaatcode en één RasClient-gebeurtenis uit diezelfde minuut. Dit is de volgorde die ik gebruik — leg de poging vast, lees de code, haal de gebeurtenis op en wijzig dan precies één laag.

De dialoogtekst is de laatste stap, niet de oorzaak

De zin die je leest wordt gekozen nadat de poging al is afgewikkeld. "De verbinding is door de externe computer beëindigd voordat de verbinding tot stand kwam" verschijnt wanneer een server midden in de onderhandeling ophangt, wanneer IPsec faalde voordat je gebruikersnaam ooit werd verzonden, en wanneer een beleid de tunnel botweg weigerde. Drie verschillende eigenaren, één zin. Behandel de formulering als een symptoomklasse en laat hem niets aansturen tot de code het ermee eens is.

Wat je nog kunt vastleggen, is de poging zelf. Schrijf de naam van de verbinding op, het tunneltype dat in het profiel is opgeslagen — PPTP, L2TP/IPsec, SSTP of IKEv2 —, de tijd tot op de seconde en de code. Als je niet zeker weet welk protocol echt liep, open dan %APPDATA%\Microsoft\Network\Connections\Pbk\rasphone.pbk en lees de vermelding in plaats van op je geheugen te vertrouwen; een profiel dat opnieuw wordt gebruikt voor een nieuw protocol houdt zijn oude weergavenaam.

Lees het nummer voordat je de woorden leest

Codes vallen in drie fasen, en de fase telt zwaarder dan de exacte formulering: een authenticatie-uitwisseling die werd bereikt en geweigerd, een server die nooit antwoordde, of een onderhandeling die instortte nadat de link omhoog kwam. 691 is de eerste soort — de controle van inloggegevens liep en faalde, of dat nu kwam door een verkeerd wachtwoord, een vergrendeld of verlopen account, of een authenticatieprotocol dat de server niet accepteert. 812 is ook een weigering, maar met geldige inloggegevens: een beleid op de server voor externe toegang besliste tegen je. Microsoft onderhoudt de canonieke lijst met foutcodes voor inbel- en VPN-verbindingen, en het loont om daar je nummer te lezen voordat je de berichttekst doorzoekt.

809 is de tegenovergestelde klasse: er kwam niets terug. Dat is een padprobleem — TCP 443 gefilterd voor SSTP, GRE geblokkeerd voor PPTP, UDP 500 en 4500 of ESP weggegooid voor IPsec-pass-through. Een nieuw wachtwoord kan dat niet oplossen en een nieuw certificaat ook niet. 720 betekent dat de link omhoog kwam en dat PPP de onderhandeling nooit afmaakte, wat wijst op een protocolonverenigbaarheid of een server die geen adres kon toewijzen. 789, of 13801 bij IKEv2, is identiteit binnen IPsec: een certificaat waarvan het subject niet overeenkomt met de naam die je kiest, een niet-vertrouwde keten, of een vooraf gedeelde sleutel die verschilt tussen de twee uiteinden.

Haal de RasClient-gebeurtenis van diezelfde minuut op

In Logboekviewer is Windows Logs > Application gefilterd op bron RasClient de eerste plek om te kijken. Microsofts beschrijving van fout 720 verwijst naar gebeurtenis 20227 in dat logboek. Dezelfde provider zendt andere identificaties uit voor andere uitkomsten, dus lees het bericht en de ingebedde resultaatcode in plaats van de ID als de diagnose te behandelen; een algemene dialoog plus een 20227 die 720 draagt is al een veel smaller verhaal.

Vanuit PowerShell, zonder door de GUI te klikken:

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

Een leeg resultaat is informatief. Het betekent meestal dat het inbellen nooit ver genoeg kwam om iets vast te leggen, of dat de software die faalde helemaal niet de native client is — clients van derden houden hun eigen diagnostiek bij en schrijven vaak niets in het Application-logboek. Controleer het logboek van de leverancier voordat je concludeert dat gebeurtenisregistratie kapot is.

Bouw één tijdlijn in plaats van een hoop gebeurtenissen

Herhaal-lussen produceren ruis. Vijf automatische herverbindingen laten een cluster gebeurtenissen achter, en de verleiding is ze te lezen als één reeks met één oorzaak. Het zijn vijf afzonderlijke pogingen, en slechts enkele bereikten een server. Neem een venster van twee of drie minuten, één verbindingsnaam, en lijst elke gebeurtenis met zijn eigen code op voordat je iets interpreteert.

Vraag dan waar de poging stopte. Wanneer de gateway of de authenticatie-backend geen enkel record heeft voor die tijdstempel, heeft de client die nooit bereikt, en kijk je naar een bereikbaarheidsprobleem. Wanneer de backend een verzoek en een weigering toont, is de beslissing daar genomen, en geldt de klasse inloggegevens of beleid. Vergelijk klokken voordat je tijden vergelijkt: clients rapporteren lokale tijd, veel gateways loggen in UTC, en een afwijking zal een perfect gecorreleerd paar er ongerelateerd laten uitzien.

Voor een herhaalbare opname, bel vanuit de opdrachtregel en laat het resultaat afdrukken:

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

De console toont het nummer dat de GUI achter vriendelijke tekst verbergt, en het twee keer uitvoeren vertelt je of de code stabiel of periodiek is.

Wat elke fase je zegt te wijzigen

De fase benoemen is alleen nuttig als het de wijzigingsset tot één laag verkleint:

• 691 — authenticatie: de EAP-methode die de client biedt tegenover die de server accepteert, accountstatus, wachtwoordverloop, inbelrechten.
• 812 — serverbeleid: het beleid voor externe toegang of de NPS-regel die bij deze gebruiker en dit tijdvenster past.
• 809 — bereikbaarheid: firewallregels op het pad, NAT en protocol-pass-through, de poort die het gekozen tunneltype nodig heeft.
• 720 — PPP-onderhandeling: onverenigbaarheid van authenticatieprotocol, adrestoewijzing, een PPP-instelling aan de serverkant.
• 789 / 13801 — IPsec-identiteit: certificaatsubject tegenover de naam die je kiest, vertrouwensketen, vooraf gedeelde sleutel.

Wijzig een van die, test hetzelfde profiel opnieuw en noteer de nieuwe code. Een andere code na een wijziging is vooruitgang in plaats van tegenspraak: je hebt de fout naar een latere fase verplaatst, en zo ziet het repareren van een meerfasige handdruk eruit. Wat je niet moet doen, is de firewall, het certificaat en het wachtwoord in één sessie wijzigen en dan de eer geven aan degene die als laatste kwam.

Deel het bewijs, niet de omgeving

Gebeurtenisberichten zijn rijker dan ze lijken. Ze dragen de verbindingsnaam, het account, vaak de interne naam of het adres van de gateway, en soms een certificaatvingerafdruk. Bewaar het origineel waar het hoort, en bouw een aparte geredigeerde kopie voor iedereen die verder kijkt; de tijdlijn uit je geheugen overtikken verliest precies de details die hem bruikbaar maken.

Een overdracht die wordt opgepakt heeft vijf velden nodig: de code, de fase waartoe hij behoort, de client en het tunneltype, de tijdstempel met zijn tijdzone, en of de gateway het verzoek überhaupt zag. Al het andere is optioneel. Met die vijf kan de volgende persoon een discussie over inloggegevens onderscheiden van een over routering zonder het onderzoek te herhalen.

Voordat je iets afsluit, speel de poging op hetzelfde profiel opnieuw af en bevestig waar de code nu landt. Een succes beëindigt het; een andere fout betekent dat de oorspronkelijke fase is gerepareerd en je de volgende in handen hebt.