Windows-VPN-foutcodes: welke fase is mislukt en wat je moet loggen

Open na een fout het Windows-VPN-dialoogvenster en het geeft je een nummer en een zin, waarbij de zin meestal de minst nuttige helft is. Het nummer geeft aan welke fase van de verbinding is mislukt, en de fase bepaalt welk log, welke instelling en welk team je hierna moet bekijken. De fasen op volgorde doorlopen kost ongeveer tien minuten en voorkomt de bekende reeks van adapters opnieuw installeren, protocollen wisselen en de stack resetten om een account te repareren dat nooit mocht inbellen.

Lees het nummer als een fase

Een native verbinding doorloopt vier mijlpalen. Hij bereikt de server en brengt een link tot stand, onderhandelt over beveiliging, authenticeert de gebruiker en past adressering en routering toe. Een fout in elk daarvan laat ander bewijs achter, en een code die bij één fase hoort zegt niets nuttigs over de andere.

De fout die je moet vermijden is de code als ernstgraad behandelen. Een linkfout en een autorisatiefout lezen beide als "kon niet verbinden", en ze hebben verder niets gemeen. Ernst zegt hoe urgent iets is; de fase zegt wat je moet openen.

Fase één: de link en de inbelpoging

829 betekent dat de onderliggende link is weggevallen. Het zegt niet of de externe peer stopte met antwoorden, of een tussenliggend apparaat de sessie doodde, of een beleid op de client hem sloot. Een inbelvoltooiingscode zoals 703 is nog eerder: de poging kwam nooit zo ver dat er een link was, wat meestal wijst op het profiel, de servicestatus of een lokaal beleid.

Get-VpnConnection -Name 'Corp' | Select-Object Name,ServerAddress,TunnelType,AuthenticationMethod,ConnectionStatus
Test-NetConnection -ComputerName vpn.example.net -Port 443
Get-WinEvent -LogName Application -MaxEvents 200 | Where-Object ProviderName -match 'RasClient' | Select-Object -First 15 TimeCreated,Id,Message

De gebeurtenisquery is het deel dat mensen overslaan. Een registratie aan de clientzijde met een tijdstempel en een interfacenaam is meer waard dan het dialoogvenster, omdat die zegt of de poging de machine überhaupt heeft verlaten. Geen registratie en geen antwoord van de luisteraar is een bereikbaarheidsprobleem, en geen enkele clientbewerking verandert dat.

Als hetzelfde profiel op een ander netwerk werkt, stop hier. De code beschrijft een padconditie en geen configuratiefout, en de volgende nuttige vergelijking zijn de twee opnames en niet nog een herinstallatie.

Fase twee: PPP en de miniport-binding

720 zit tussen de link en de gebruiker. De tunnel kwam omhoog en daarna kon de PPP-laag geen adres of besturingsprotocol onderhandelen, wat vaak een bindingsprobleem op de client is en geen geweigerde referentie. Dat onderscheid is de hele waarde van de code: hij zegt dat de referentie nooit is bereikt, dus het account is niet de verdachte.

Get-NetAdapter -IncludeHidden | Where-Object InterfaceDescription -match 'WAN Miniport' | Select-Object Name,Status,ifIndex
Get-NetAdapterBinding | Where-Object ComponentID -match 'ms_pptp|ms_l2tp|ms_sstp|ms_agile' | Select-Object Name,ComponentID,Enabled

Die twee uitvoer lezen is informatiever dan wat dan ook resetten. Een miniport die aanwezig is maar niet gestart, of een protocolbinding die door andere software is uitgeschakeld, levert precies de fout van deze fase op. Beide zijn te verhelpen zonder de rest van de stack aan te raken. Een volledige reset verwijdert juist adressering en filterstatus die niets met de storing te maken hadden.

Fase drie: identiteit en autorisatie

691 betekent dat de referenties zijn geweigerd. 649 betekent dat het account niet mag inbellen, en 812 betekent dat een beleid voor externe toegang de verbinding heeft geweigerd. Dat zijn beslissingen, geen transportfouten, en de client kan ze alleen melden.

Het bewijs ligt aan de andere kant. Vraag de gateway-beheerder om de poging op dat tijdstempel en het beleid dat overeenkwam; vraag de directory-eigenaar of het account inbelrechten heeft en of het in de groep zit die het beleid vereist. Het tunneltype wijzigen of de client opnieuw installeren kan een beslissing over een identiteit niet veranderen.

Een nuttige gewoonte in deze fase is de exacte accountstring in het ticket schrijven, inclusief een eventuele domeinprefix. Een verrassend aantal 691-gevallen zijn opgeslagen referenties voor het verkeerde domein, en dat zie je in de accountstring en niet in de protocolinstellingen.

Fase vier: verbonden, en niets werkt

Een verbinding kan tot stand komen en toch nutteloos zijn. Hij heeft een adres, de client meldt succes en elke aanvraag van de applicatie loopt in een time-out. Niets in het dialoogvenster weerspiegelt dat, en er is geen code om op te zoeken. Op dat punt is het dialoogvenster klaar en ligt het nuttige bewijs elders.

Get-NetRoute -DestinationPrefix 10.24.0.0/16 | Select-Object DestinationPrefix,NextHop,InterfaceAlias
Resolve-DnsName files.corp.example.internal
Test-NetConnection -ComputerName 10.24.6.15 -Port 445

Ontbreekt de route, dan heeft de server hem niet geduwd of de client hem laten vallen. Bestaat de route en faalt de naam, dan is resolutie het probleem. Werken beide en faalt de applicatie nog steeds, dan ben je voorbij de tunnel en in de configuratie van de applicatie zelf.

Houd de wijzigingen op één laag per test. Elke bewerking voor de volgende poging wordt onderdeel van de context van de volgende code, en een code die je laatste bewerking beschrijft is erger dan helemaal geen code.

Eén poging, één wijziging, één registratie

Welke fase het ook is, de registratie moet de code, het bericht, de profielnaam, het tijdstempel en het netwerk waarop je zat bevatten. Vijf velden, en elk daarvan staat al voor je in het dialoogvenster of het clientlog. Die set is klein genoeg om in een ticket te plakken en specifiek genoeg voor iemand anders om hem te reproduceren.

Zet dan dat tijdstempel naast de registratie aan de andere kant. De tabel boven aan deze pagina zegt welke fase bij elke afwijking hoort. Zonder de tweede registratie vernauwt de code alleen de zoektocht; met die registratie is de fase beslist. De vergelijking is wat een nummer in een diagnose verandert en niet in een gok.

Die gewoonte dekt vrijwel elke native Windows-VPN-storing, en geen van de takken vereist dat je iets opnieuw installeert. Het dialoogvenster vertelde je altijd welke je had; het werk zit erin te weigeren ze allemaal als hetzelfde probleem te behandelen.