L2TP/IPsec-feil 789, 720 eller 691: rett opp riktig trinn først

Windows 11 rapporterer et annet nummer for hvert L2TP/IPsec-trinn, og nummeret markerer et trinn i stedet for å vurdere feilen. 789 feiler før PPP-koblingen finnes, 720 feiler mens koblingen bygges opp, og 691 feiler etter at koblingen er oppe og påloggingsinformasjonen avvises. Den nyttige avgjørelsen er ikke hvilken retting som er mest populær; det er hvilket trinn koden beviser at du har nådd. Les det først, og bytt deretter ett lag per forsøk slik at den neste koden fortsatt forteller deg noe.

Les koden som et trinn, ikke som en feilliste

En L2TP-tilkobling krysser tre grenser i fast rekkefølge. IKE forhandler sikkerhetsassosiasjoner over UDP 500, NAT-gjennomgang flytter trafikken til UDP 4500, og først da bærer L2TP-tunnelen en PPP-økt som autentiserer brukeren og tildeler en adresse.

Den rekkefølgen er grunnen til at en skiftende feilkode er nyttig bevis. Å gå fra 789 til 720 betyr at IPsec nå forhandler og at feilen har flyttet seg til oppretting av koblingen. Å gå fra 720 til 691 betyr at koblingen kom opp og at gatewayen avviste identiteten. Hvis du bruker fem rettinger på én gang, mister du signalet og kan ikke si hvilken endring som virket.

789: velg mellom banen og den lokale policyen

Kode 789 er en behandlingsfeil under de innledende sikkerhetsforhandlingene. IPsec laget aldri en brukbar assosiasjon, så kontoen er ennå ikke testet. Start med banen og den delte nøkkelen, ikke med kontoen.

Bekreft at UDP 500 og UDP 4500 når serveren, og at den forhåndsdelte nøkkelen stemmer byte for byte, inkludert store og små bokstaver og mellomrom på slutten. Hvis serveren står bak NAT, kan Windows også trenge den dokumenterte registerverdien. Bruk 1 når serveren er bak NAT, og 2 når begge ender er det, og start deretter på nytt fordi policyagenten leser verdien ved oppstart:

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

Den tyngre adapterreparasjonen hører til den andre grenen. Å fjerne Wi-Fi-enheten og WAN-miniportene og deretter skanne etter maskinvare er berettiget når selve den lokale IPsec-stakken er skadet og andre VPN-typer feiler på samme måte. Det er bortkastet arbeid når bare én L2TP-server feiler mens alle andre nettverksbaner virker.

720: velg mellom denne adapteren og servergruppen

Feil 720 rapporterer at tilkoblingen til den eksterne datamaskinen ikke kunne opprettes, og den vises etter at IPsec har lykkes. Tunnelen nådde punktet der et grensesnitt heves eller en adresse hentes, og stoppet deretter. Det gjør det til et spørsmål om den lokale adapteren eller serverkapasiteten.

Bruk skadens radius til å avgjøre. Én Windows-maskin som feiler peker på en dårlig WAN-miniport, en stoppet Remote Access-tjeneste eller en skadet tilkoblingsprofil. Flere klienter som feiler samtidig peker på serveren: en uttømt adressepool, en stoppet RRAS-tjeneste eller en pool som ikke lenger passer klientens subnett. Rett den siden mønsteret peker på før du endrer den andre.

På grenen med én klient fjerner du WAN-miniportene én gang og skanner etter maskinvareendringer, og starter deretter på nytt og prøver igjen. På servergrenen kontrollerer du poolen og tjenestestatusen i stedet for klienten, fordi nyinstallering av en fungerende adapter ikke kan lage en adresse serveren ikke har.

691: velg mellom påloggingsinformasjonen og en stoppet hjelper

Kode 691 er en avvisning av autentisering, og det er koden som oftest leses feil som et galt passord. Tunnelen er oppe, gatewayen så en identitet og avviste den. Årsaken kan fortsatt ligge utenfor passordfeltet.

Kontroller domenefeltet først, deretter de nøyaktige tegnene i passordet. Et passord med et mellomrom, en anførselstegn eller et skallspesialtegn kan bli ødelagt før det når serveren; på Linux pppd rapporterer den samme avvisningen som E=691 for en verdi uten anførselstegn eller et manglende domene. Skriv hemmeligheten på nytt i stedet for å lime den inn, og fjern all lagret påloggingsinformasjon som kan ha en eldre verdi.

Grenen folk overser, er en stoppet hjelpetjeneste. Når en leverandørklient er avhengig av sin egen tjeneste for å sende påloggingsinformasjon til gatewayen, produserer en deaktivert eller krasjet tjeneste 691 selv når passordet er riktig. Kontroller leverandørens tjenestestatus før du tilbakestiller kontoen, spesielt etter en omstart eller oppdatering.

For å skille grenene tester du samme brukernavn mot en annen fungerende VPN-profil eller en RADIUS-testkonto. Hvis det lykkes, er påloggingsinformasjonen i orden og den lokale klientbanen mistenkelig. Hvis det feiler på samme måte, er problemet kontoen eller gatewaypolicyen.

Bytt ett lag per forsøk

Arbeid utenfra og inn: tilgjengelighet og NAT-gjennomgang, deretter den forhåndsdelte nøkkelen, deretter den lokale adapterstakken, deretter påloggingsinformasjonen, deretter serverpoolen og tjenestene. Den rekkefølgen følger trinnene kodene beskriver og holder hvert resultat henførbart til én endring.

Før en kort logg over koden før og etter hvert forsøk, klientbyggingen og om serveren eller klienten ble endret. En sekvens som 789, deretter 720, deretter 691 er et kart over fremdriften; samme kode to ganger betyr at den siste endringen ikke tok tak i det trinnet. Nyinstallering av Windows sletter dette kartet og retter sjelden en feil som bor på gatewayen.

Når koden slutter å endre seg, slutt å endre ting. Registrer gjeldende kode, serveradressen, autentiseringsmetoden og tidspunktet for forsøket, og sammenlign deretter den registreringen med en klient som virker. Forskjellen mellom de to registreringene er vanligvis mindre enn listen med rettinger folk prøver som standard.