L2TP/IPsec-fejl 789, 720 eller 691: ret den rigtige fase først

Windows 11 rapporterer et andet nummer for hver L2TP/IPsec-fase, og nummeret markerer en fase i stedet for at vurdere fejlen. 789 fejler, før PPP-forbindelsen findes, 720 fejler, mens forbindelsen oprettes, og 691 fejler, efter at forbindelsen er oppe, og loginoplysningerne afvises. Den nyttige beslutning er ikke, hvilken rettelse der er mest populær; det er, hvilken fase koden beviser, at du har nået. Læs det først, og skift derefter ét lag for hvert forsøg, så den næste kode stadig fortæller dig noget.

Læs koden som en fase, ikke som en fejlliste

En L2TP-forbindelse krydser tre grænser i en fast rækkefølge. IKE forhandler sikkerhedsassociationer over UDP 500, NAT-gennemgang flytter trafikken til UDP 4500, og først derefter bærer L2TP-tunnelen en PPP-session, der godkender brugeren og tildeler en adresse.

Den rækkefølge er grunden til, at en skiftende fejlkode er nyttigt bevis. At gå fra 789 til 720 betyder, at IPsec nu forhandler, og at fejlen er flyttet til oprettelse af forbindelsen. At gå fra 720 til 691 betyder, at forbindelsen kom op, og at gatewayen afviste identiteten. Hvis du anvender fem rettelser på én gang, mister du signalet og kan ikke se, hvilken ændring der virkede.

789: vælg mellem stien og den lokale politik

Kode 789 er en behandlingsfejl under de indledende sikkerhedsforhandlinger. IPsec skabte aldrig en brugbar association, så kontoen er endnu ikke testet. Start med stien og den delte nøgle, ikke med kontoen.

Bekræft, at UDP 500 og UDP 4500 når serveren, og at den foruddelte nøgle stemmer byte for byte, inklusive store og små bogstaver og efterfølgende mellemrum. Hvis serveren står bag NAT, kan Windows også have brug for den dokumenterede registreringsværdi. Brug 1, når serveren er bag NAT, og 2, når begge ender er, og genstart derefter, fordi politikagenten læser værdien ved opstart:

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

Den tungere adapterreparation hører til den anden gren. At fjerne Wi-Fi-enheden og WAN-miniportene og derefter scanne efter hardware er berettiget, når selve den lokale IPsec-stak er beskadiget, og andre VPN-typer fejler på samme måde. Det er spildt arbejde, når kun én L2TP-server fejler, mens alle andre netværksstier virker.

720: vælg mellem denne adapter og serverpuljen

Fejl 720 rapporterer, at forbindelsen til den eksterne computer ikke kunne oprettes, og den vises, efter at IPsec er lykkedes. Tunnelen nåede punktet, hvor en grænseflade rejses, eller en adresse hentes, og stoppede derefter. Det gør det til et spørgsmål om den lokale adapter eller serverens kapacitet.

Brug skadesradius til at beslutte. Én Windows-maskine, der fejler, peger på en dårlig WAN-miniport, en stoppet Remote Access-tjeneste eller en beskadiget forbindelsesprofil. Flere klienter, der fejler samtidig, peger på serveren: en udtømt adressepulje, en stoppet RRAS-tjeneste eller en pulje, der ikke længere passer til klientens undernet. Ret den side, som mønsteret peger på, før du ændrer den anden.

På grenen med én klient fjerner du WAN-miniportene én gang og scanner efter hardwareændringer, genstarter og prøver igen. På servergrenen kontrollerer du puljen og tjenestetilstanden i stedet for klienten, fordi geninstallation af en fungerende adapter ikke kan skabe en adresse, som serveren ikke har.

691: vælg mellem loginoplysningen og en stoppet hjælper

Kode 691 er en afvisning af godkendelse, og det er den kode, der oftest læses forkert som en forkert adgangskode. Tunnelen er oppe, gatewayen har set en identitet, og den afviste identiteten. Årsagen kan stadig ligge uden for adgangskodefeltet.

Kontroller domænefeltet først, derefter de præcise tegn i adgangskoden. En adgangskode med et mellemrum, et anførselstegn eller et shell-specialtegn kan blive ødelagt, før den når serveren; på Linux pppd rapporterer den samme afvisning som E=691 for en værdi uden anførselstegn eller et manglende domæne. Skriv hemmeligheden igen i stedet for at indsætte den, og ryd enhver gemt loginoplysning, der kan indeholde en ældre værdi.

Den gren, folk overser, er en stoppet hjælpetjeneste. Når en leverandørklient afhænger af sin egen tjeneste for at sende loginoplysninger til gatewayen, giver en deaktiveret eller nedbrudt tjeneste 691, selv om adgangskoden er korrekt. Kontroller leverandørens tjenestetilstand, før du nulstiller kontoen, især efter en genstart eller en opdatering.

For at skelne grenene testes det samme brugernavn mod en anden fungerende VPN-profil eller en RADIUS-testkonto. Hvis det lykkes, er loginoplysningen i orden, og klientstien er mistænkelig. Hvis det fejler på samme måde, er problemet kontoen eller gatewaypolitikken.

Skift ét lag for hvert forsøg

Arbejd udefra og ind: tilgængelighed og NAT-gennemgang, derefter den foruddelte nøgle, derefter den lokale adapterstak, derefter loginoplysningen, derefter serverpuljen og tjenesterne. Den rækkefølge følger de faser, koderne beskriver, og holder hvert resultat henførbart til én ændring.

Før en kort log over koden før og efter hvert forsøg, klientbuilden og om serveren eller klienten blev ændret. En sekvens som 789, derefter 720, derefter 691 er et kort over fremskridt; den samme kode to gange betyder, at den sidste ændring ikke adresserede den fase. Geninstallation af Windows sletter dette kort og retter sjældent en fejl, der bor på gatewayen.

Når koden holder op med at ændre sig, stop med at ændre ting. Registrér den aktuelle kode, serveradressen, godkendelsesmetoden og tidspunktet for forsøget, og sammenlign derefter den registrering med en klient, der virker. Forskellen mellem de to registreringer er normalt mindre end listen af rettelser, folk prøver som standard.