Eroare L2TP/IPsec 789, 720 sau 691: remediați mai întâi etapa corectă

Windows 11 raportează un număr diferit pentru fiecare etapă L2TP/IPsec, iar acel număr marchează o etapă în loc să evalueze defecțiunea. 789 eșuează înainte de a exista legătura PPP, 720 eșuează în timp ce legătura este ridicată, iar 691 eșuează după ce legătura este sus și acreditările sunt respinse. Decizia utilă nu este care remediere este mai populară; este care etapă dovedește codul că ați atins. Citiți asta mai întâi, apoi schimbați un singur strat pe încercare, astfel încât următorul cod să vă mai spună ceva.

Citiți codul ca pe o etapă, nu ca pe o listă de defecte

O conexiune L2TP traversează trei granițe într-o ordine fixă. IKE negociază asocieri de securitate prin UDP 500, traversarea NAT mută acel trafic pe UDP 4500 și abia apoi tunelul L2TP transportă o sesiune PPP care autentifică utilizatorul și atribuie o adresă.

Această ordine este motivul pentru care un cod de eroare care se schimbă este o dovadă utilă. Trecerea de la 789 la 720 înseamnă că IPsec negociază acum și că defecțiunea s-a mutat la stabilirea legăturii. Trecerea de la 720 la 691 înseamnă că legătura s-a ridicat și că poarta a respins identitatea. Dacă aplicați cinci remedieri deodată, pierdeți acel semnal și nu puteți spune care schimbare a funcționat.

789: alegeți între cale și politica locală

Codul 789 este o eroare de procesare în timpul negocierilor inițiale de securitate. IPsec nu a produs niciodată o asociere utilizabilă, așa că contul nu a fost încă testat. Începeți cu calea și cheia partajată, nu cu contul.

Confirmați că UDP 500 și UDP 4500 ajung la server și că cheia prepartajată se potrivește octet cu octet, inclusiv majusculele și spațiile de la final. Dacă serverul se află în spatele NAT, Windows poate avea nevoie și de valoarea de registru documentată. Folosiți 1 când serverul este în spatele NAT și 2 când ambele capete sunt, apoi reporniți, pentru că agentul de politici citește valoarea la pornire:

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

Reparația mai grea a adaptorului aparține celeilalte ramuri. Scoaterea dispozitivului Wi-Fi și a miniporturilor WAN și apoi rescanarea hardware-ului se justifică atunci când stiva IPsec locală este ea însăși deteriorată și alte tipuri de VPN eșuează la fel. Este efort irosit când eșuează doar un server L2TP, în timp ce toate celelalte căi de rețea funcționează.

720: alegeți între acest adaptor și grupul de servere

Eroarea 720 raportează că conexiunea la computerul la distanță nu a putut fi stabilită și apare după ce IPsec a reușit. Tunelul a ajuns la punctul de a ridica o interfață sau de a obține o adresă, apoi s-a oprit. Asta o face o chestiune de adaptor local sau de capacitate a serverului.

Folosiți raza de impact pentru a decide. O singură mașină Windows care eșuează indică un miniport WAN defect, un serviciu Remote Access oprit sau un profil de conexiune corupt. Mai mulți clienți care eșuează simultan indică serverul: un grup de adrese epuizat, un serviciu RRAS oprit sau un grup care nu mai corespunde subrețelei clientului. Remediați partea pe care o indică modelul înainte de a o schimba pe cealaltă.

În ramura cu un singur client, scoateți miniporturile WAN o dată și scanați modificările de hardware, apoi reporniți și încercați din nou. În ramura serverului, verificați grupul și starea serviciului, nu clientul, pentru că reinstalarea unui adaptor funcțional nu poate crea o adresă pe care serverul nu o are.

691: alegeți între acreditare și un ajutor oprit

Codul 691 este o respingere a autentificării și este codul cel mai des interpretat greșit ca parolă greșită. Tunelul este sus, poarta a văzut o identitate și a respins-o. Cauza poate fi încă în afara câmpului parolei.

Verificați mai întâi câmpul de domeniu, apoi caracterele exacte din parolă. O parolă care conține un spațiu, un ghilim sau un caracter special de shell poate fi alterată înainte de a ajunge la server; în Linux, pppd raportează aceeași respingere ca E=691 pentru o valoare fără ghilimele sau un domeniu lipsă. Retastați secretul în loc să îl lipiți și ștergeți orice acreditare salvată care ar putea avea o valoare mai veche.

Ramura pe care oamenii o ratează este un serviciu auxiliar oprit. Când un client al unui furnizor depinde de propriul serviciu pentru a transmite acreditările către poartă, un serviciu dezactivat sau blocat produce 691 chiar dacă parola este corectă. Verificați starea serviciului furnizorului înainte de a reseta contul, mai ales după o repornire sau o actualizare.

Pentru a separa ramurile, testați același nume de utilizator pe un alt profil VPN funcțional sau pe un cont de test RADIUS. Dacă reușește, acreditarea este bună și calea locală a clientului este suspectă. Dacă eșuează la fel, problema este contul sau politica porții.

Schimbați un strat pe încercare

Lucrați din exterior spre interior: accesibilitate și traversare NAT, apoi cheia prepartajată, apoi stiva adaptorului local, apoi acreditarea, apoi grupul de servere și serviciile. Această ordine urmează etapele descrise de coduri și păstrează fiecare rezultat atribuibil unei singure schimbări.

Țineți un jurnal scurt al codului înainte și după fiecare încercare, al versiunii clientului și al faptului dacă a fost schimbat serverul sau clientul. O secvență precum 789, apoi 720, apoi 691 este o hartă a progresului; același cod de două ori înseamnă că ultima schimbare nu a abordat acea etapă. Reinstalarea Windows șterge această hartă și rareori remediază o defecțiune care trăiește la poartă.

Când codul nu se mai schimbă, opriți-vă din a schimba lucruri. Înregistrați codul curent, adresa serverului, metoda de autentificare și momentul încercării, apoi comparați acea înregistrare cu un client care funcționează. Diferența dintre cele două înregistrări este de obicei mai mică decât lista de remedieri pe care oamenii le încearcă implicit.