Windows 11 meld ’n ander nommer vir elke L2TP/IPsec-stadium, en daardie nommer dui ’n stadium aan eerder as om die fout te beoordeel. 789 misluk voordat die PPP-skakel bestaan, 720 misluk terwyl die skakel opgebou word, en 691 misluk nadat die skakel op is en die geloofsbriewe verwerp word. Die nuttige besluit is nie watter herstelling die gewildste is nie; dit is watter stadium die kode bewys jy bereik het. Lees dit eerste, en verander dan een laag per poging sodat die volgende kode jou nog iets sê.

Lees die kode as ’n stadium, nie as ’n foutlys nie

’n L2TP-verbinding kruis drie grense in ’n vaste orde. IKE onderhandel sekuriteitsassosiasies oor UDP 500, NAT-traversal skuif daardie verkeer na UDP 4500, en eers dan dra die L2TP-tonnel ’n PPP-sessie wat die gebruiker verifieer en ’n adres toeken.

Daardie orde is hoekom ’n veranderende foutkode nuttige bewyse is. Om van 789 na 720 te gaan beteken IPsec onderhandel nou en die fout het na skakelopstelling geskuif. Om van 720 na 691 te gaan beteken die skakel het opgekom en die poort het die identiteit verwerp. As jy vyf herstellings gelyk toepas, verloor jy daardie sein en kan jy nie sê watter verandering gewerk het nie.

789: kies tussen die pad en die plaaslike beleid

Kode 789 is ’n verwerkingsfout tydens die eerste sekuriteitsonderhandelinge. IPsec het nooit ’n bruikbare assosiasie opgelewer nie, daarom is die rekening nog nie getoets nie. Begin met die pad en die gedeelde geheim, nie met die rekening nie.

Bevestig dat UDP 500 en UDP 4500 die bediener bereik en dat die vooraf gedeelde sleutel byte vir byte ooreenstem, insluitend hoofletters en oorblywende spasies. As die bediener agter NAT sit, het Windows dalk ook die gedokumenteerde registerwaarde nodig. Gebruik 1 wanneer die bediener agter NAT is en 2 wanneer beide kante dit is, en herbegin dan, want die beleidsagent lees die waarde by die opstart:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent" /v AssumeUDPEncapsulationContextOnSendRule /t REG_DWORD /d 1 /f

Die swaarder adapterherstel hoort by die ander tak. Om die Wi-Fi-toestel en die WAN-minipoorte te verwyder en dan vir hardeware te skandeer, is geregverdig wanneer die plaaslike IPsec-stapel self beskadig is en ander VPN-tipes op dieselfde manier misluk. Dit is vermorste moeite wanneer net een L2TP-bediener misluk terwyl elke ander netwerkpad werk.

720: kies tussen hierdie adapter en die bedienerpoel

Fout 720 sê dat die verbinding na die afgeleë rekenaar nie bewerkstellig kon word nie, en dit verskyn nadat IPsec geslaag het. Die tonnel het die punt bereik waar ’n koppelvlak opgebou of ’n adres verkry word, en het toe gestop. Dit maak dit ’n plaaslike adaptervraag of ’n bedienerkapasiteitsvraag.

Gebruik die impakradius om te besluit. Een Windows-masjien wat misluk, dui op ’n slegte WAN-minipoort, ’n gestopte Remote Access-diens of ’n beskadigde verbindingsprofiel. Verskeie kliënte wat op dieselfde tyd misluk, dui op die bediener: ’n uitgeputte adrespoel, ’n gestopte RRAS-diens of ’n poel wat nie meer by die kliëntsubnet pas nie. Herstel die kant wat die patroon impliseer voordat jy die ander verander.

Op die enkelkliënt-tak, verwyder die WAN-minipoorte een keer en skandeer vir hardewareveranderinge, herbegin dan en probeer weer. Op die bediener-tak, kyk na die poel en die dienstoestand eerder as na die kliënt, want om ’n werkende adapter te herinstalleer kan nie ’n adres skep wat die bediener nie het nie.

691: kies tussen die geloofsbrief en ’n gestopte helper

Kode 691 is ’n verwerping van verifikasie, en dit is die kode wat die meeste verkeerd gelees word as ’n verkeerde wagwoord. Die tonnel is op, die poort het ’n identiteit gesien, en dit het die identiteit geweier. Die oorsaak kan steeds buite die wagwoordveld sit.

Kontroleer eers die domeinveld, dan die presiese karakters in die wagwoord. ’n Wagwoord met ’n spasie, ’n aanhalingsteken of ’n skulp-spesiale karakter kan vermink word voordat dit die bediener bereik; op Linux, pppd rapporteer dieselfde verwerping as E=691 vir ’n waarde sonder aanhalingstekens of ’n ontbrekende domein. Tik die geheim weer in eerder as om dit te plak, en wis enige gestoorde geloofsbrief wat ’n ouer waarde kan hou.

Die tak wat mense mis, is ’n gestopte helperdiens. Wanneer ’n verskafferkliënt op sy eie diens staatmaak om geloofsbriewe aan die poort te gee, lewer ’n gedeaktiveerde of ineenstortende diens 691 op, selfs al is die wagwoord korrek. Kontroleer die verskafferdiens se toestand voordat jy die rekening herstel, veral ná ’n herbegin of ’n opdatering.

Om die takke te skei, toets dieselfde gebruikersnaam teen ’n ander werkende VPN-profiel of ’n RADIUS-toetsrekening. As dit slaag, is die geloofsbrief reg en is die plaaslike kliëntpad verdag. As dit op dieselfde manier misluk, is die rekening of die poortbeleid die probleem.

Verander een laag per poging

Werk van buite na binne: bereikbaarheid en NAT-traversal, dan die vooraf gedeelde sleutel, dan die plaaslike adapterstapel, dan die geloofsbrief, dan die bedienerpoel en dienste. Daardie orde volg die stadiums wat die kodes beskryf en hou elke resultaat toeskryfbaar aan een verandering.

Hou ’n kort log van die kode voor en ná elke poging, die kliëntbou, en of die bediener of die kliënt verander is. ’n Reeks soos 789, dan 720, dan 691 is ’n kaart van vordering; dieselfde kode twee keer beteken die laaste verandering het nie daardie stadium aangespreek nie. Om Windows te herinstalleer vee hierdie kaart uit en herstel selde ’n fout wat by die poort woon.

Wanneer die kode ophou verander, hou op om dinge te verander. Teken die huidige kode, die bedieneradres, die verifikasiemetode en die tyd van die poging op, en vergelyk dan daardie rekord met ’n kliënt wat werk. Die verskil tussen die twee rekords is gewoonlik kleiner as die lys herstellings wat mense by verstek probeer.

Verwante artikels