L2TP/IPsec-fel 789, 720 eller 691: åtgärda rätt steg först

Windows 11 rapporterar olika nummer för varje L2TP/IPsec-steg, och numret markerar ett steg i stället för att bedöma felet. 789 misslyckas innan PPP-länken finns, 720 misslyckas medan länken byggs upp och 691 misslyckas efter att länken är uppe och inloggningsuppgifterna avvisas. Det användbara beslutet är inte vilken åtgärd som är populärast; det är vilket steg koden bevisar att du har nått. Läs det först och ändra sedan ett lager per försök så att nästa kod fortfarande säger dig något.

Läs koden som ett steg, inte som en fellista

En L2TP-anslutning korsar tre gränser i fast ordning. IKE förhandlar säkerhetsassociationer över UDP 500, NAT-genomgång flyttar trafiken till UDP 4500, och först därefter bär L2TP-tunneln en PPP-session som autentiserar användaren och tilldelar en adress.

Den ordningen är skälet till att en föränderlig felkod är ett användbart bevis. Att gå från 789 till 720 betyder att IPsec nu förhandlar och att felet har flyttat till uppkopplingen. Att gå från 720 till 691 betyder att länken kom upp och att gatewayen avvisade identiteten. Om du använder fem åtgärder samtidigt förlorar du signalen och kan inte säga vilken ändring som fungerade.

789: välj mellan vägen och den lokala policyn

Kod 789 är ett bearbetningsfel under de inledande säkerhetsförhandlingarna. IPsec skapade aldrig en användbar association, så kontot har ännu inte testats. Börja med vägen och den delade nyckeln, inte med kontot.

Bekräfta att UDP 500 och UDP 4500 når servern och att den fördelade nyckeln stämmer byte för byte, inklusive versaler och små bokstäver samt mellanslag i slutet. Om servern står bakom NAT kan Windows också behöva det dokumenterade registervärdet. Använd 1 när servern står bakom NAT och 2 när båda ändarna gör det, starta sedan om eftersom principagenten läser värdet vid start:

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

Den tyngre adapterreparationen hör till den andra grenen. Att ta bort Wi-Fi-enheten och WAN-miniportarna och sedan skanna efter maskinvara är motiverat när själva den lokala IPsec-stacken är skadad och andra VPN-typer misslyckas på samma sätt. Det är bortkastad möda när bara en L2TP-server misslyckas medan alla andra nätverksvägar fungerar.

720: välj mellan den här adaptern och serverpoolen

Fel 720 rapporterar att anslutningen till fjärrdatorn inte kunde upprättas, och det visas efter att IPsec har lyckats. Tunneln nådde punkten där ett gränssnitt höjs eller en adress hämtas och stannade sedan. Det gör det till en fråga om den lokala adaptern eller serverns kapacitet.

Använd skadans radie för att besluta. En Windows-maskin som misslyckas pekar på en dålig WAN-miniport, en stoppad Remote Access-tjänst eller en skadad anslutningsprofil. Flera klienter som misslyckas samtidigt pekar på servern: en uttömd adresspool, en stoppad RRAS-tjänst eller en pool som inte längre matchar klientens subnät. Åtgärda den sida som mönstret pekar på innan du ändrar den andra.

I grenen med en klient tar du bort WAN-miniportarna en gång och skannar efter maskinvaruändringar, startar sedan om och försöker igen. I servergrenen kontrollerar du poolen och tjänstestatusen i stället för klienten, eftersom ominstallation av en fungerande adapter inte kan skapa en adress som servern inte har.

691: välj mellan inloggningsuppgiften och en stoppad hjälpare

Kod 691 är ett autentiseringsavslag, och det är koden som oftast läses fel som ett felaktigt lösenord. Tunneln är uppe, gatewayen såg en identitet och avvisade den. Orsaken kan fortfarande ligga utanför lösenordsfältet.

Kontrollera domänfältet först och sedan de exakta tecknen i lösenordet. Ett lösenord med ett mellanslag, ett citattecken eller ett skalspecialtecken kan förvanskas innan det når servern; på Linux pppd rapporterar samma avslag som E=691 för ett värde utan citattecken eller en saknad domän. Skriv hemligheten igen i stället för att klistra in den, och rensa alla sparade inloggningsuppgifter som kan innehålla ett äldre värde.

Grenen folk missar är en stoppad hjälptjänst. När en leverantörsklient är beroende av sin egen tjänst för att skicka inloggningsuppgifter till gatewayen producerar en inaktiverad eller kraschad tjänst 691 även när lösenordet är korrekt. Kontrollera leverantörens tjänstestatus innan du återställer kontot, särskilt efter en omstart eller en uppdatering.

För att skilja grenarna åt testar du samma användarnamn mot en annan fungerande VPN-profil eller ett RADIUS-testkonto. Om det lyckas är inloggningsuppgiften i ordning och den lokala klientvägen misstänkt. Om det misslyckas på samma sätt är problemet kontot eller gatewayprincipen.

Ändra ett lager per försök

Arbeta utifrån och in: nåbarhet och NAT-genomgång, sedan den fördelade nyckeln, sedan den lokala adapterstacken, sedan inloggningsuppgiften, sedan serverpoolen och tjänsterna. Den ordningen följer de steg som koderna beskriver och håller varje resultat hänförbart till en enda ändring.

För en kort logg över koden före och efter varje försök, klientbygget och om servern eller klienten ändrades. En sekvens som 789, sedan 720, sedan 691 är en karta över framstegen; samma kod två gånger betyder att den senaste ändringen inte tog itu med det steget. Ominstallation av Windows suddar den här kartan och åtgärdar sällan ett fel som bor på gatewayen.

När koden slutar ändras ska du sluta ändra saker. Registrera aktuell kod, serverns adress, autentiseringsmetoden och tidpunkten för försöket och jämför sedan den posten med en klient som fungerar. Skillnaden mellan de två posterna är vanligtvis mindre än listan med åtgärder som folk provar som standard.