L2TP/IPsec-eraro 789, 720 aŭ 691: riparu unue la ĝustan etapon

Windows 11 raportas malsaman numeron por ĉiu etapo de L2TP/IPsec, kaj tiu numero markas etapon anstataŭ taksi la malsukceson. 789 malsukcesas antaŭ ol ekzistas la PPP-ligilo, 720 malsukcesas dum la ligilo estas levata, kaj 691 malsukcesas post kiam la ligilo staras kaj la akreditaĵoj estas rifuzataj. La utila decido ne estas, kiu riparo estas plej populara; ĝi estas, kiun etapon la kodo pruvas, ke vi atingis. Legu tion unue, poste ŝanĝu unu tavolon po provo, por ke la sekva kodo ankoraŭ diru ion al vi.

Legu la kodon kiel etapon, ne kiel liston de difektoj

L2TP-ligo transiras tri limojn en fiksa ordo. IKE interkonsentas sekurecajn asociojn super UDP 500, NAT-trapaso movas tiun trafikon al UDP 4500, kaj nur poste la L2TP-tunelo portas PPP-sesion, kiu aŭtentikigas la uzanton kaj atribuas adreson.

Tiu ordo estas kial ŝanĝiĝanta erarkodo estas utila pruvo. Iri de 789 al 720 signifas, ke IPsec nun interkonsentas kaj la malsukceso moviĝis al ligila starigo. Iri de 720 al 691 signifas, ke la ligilo stariĝis kaj la enirejo rifuzis la identecon. Se vi aplikas kvin riparojn samtempe, vi perdas tiun signalon kaj ne povas diri, kiu ŝanĝo funkciis.

789: elektu inter la vojo kaj la loka politiko

Kodo 789 estas prilabora eraro dum la komencaj sekurecaj intertraktadoj. IPsec neniam produktis uzeblan asocion, do la konto ankoraŭ ne estis testita. Komencu per la vojo kaj la komuna ŝlosilo, ne per la konto.

Konfirmu, ke UDP 500 kaj UDP 4500 atingas la servilon kaj ke la antaŭe komuna ŝlosilo kongruas bajton post bajto, inkluzive usklecon kaj finajn spacojn. Se la servilo staras malantaŭ NAT, Windows eble bezonos ankaŭ la dokumentitan registran valoron. Uzu 1 kiam la servilo estas malantaŭ NAT kaj 2 kiam ambaŭ finoj estas, poste restartigu, ĉar la politika agento legas la valoron ĉe starto:

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

La pli peza adaptila riparo apartenas al la alia branĉo. Forigi la Wi-Fi-aparaton kaj la WAN-miniportojn, poste reskani pri aparataro, estas pravigita kiam la loka IPsec-stako mem estas difektita kaj aliaj VPN-tipoj malsukcesas same. Ĝi estas vana peno kiam nur unu L2TP-servilo malsukcesas dum ĉiu alia reta vojo funkcias.

720: elektu inter ĉi tiu adaptilo kaj la servila grupo

Eraro 720 raportas, ke la konekto al la fora komputilo ne povis esti starigita, kaj ĝi aperas post kiam IPsec sukcesis. La tunelo atingis la punkton levi interfacon aŭ akiri adreson, poste haltis. Tio igas ĝin demando pri loka adaptilo aŭ pri servila kapacito.

Uzu la radiuson de efiko por decidi. Unu malsukcesanta Windows-maŝino indikas difektitan WAN-miniporton, haltigitan servon Remote Access aŭ koruptitan konektan profilon. Pluraj klientoj malsukcesantaj samtempe indikas la servilon: elĉerpitan adresaron, haltigitan RRAS-servon aŭ aron, kiu jam ne kongruas kun la klienta subreto. Riparu tiun flankon, kiun la ŝablono indikas, antaŭ ol ŝanĝi la alian.

En la branĉo de unu kliento, forigu la WAN-miniportojn unufoje kaj reskani pri aparataraj ŝanĝoj, poste restartigu kaj reprovu. En la servila branĉo, kontrolu la aron kaj la servostaton anstataŭ la klienton, ĉar reinstali funkciantan adaptilon ne povas krei adreson, kiun la servilo ne havas.

691: elektu inter la akreditaĵo kaj haltigita helpanto

Kodo 691 estas rifuzo de aŭtentikigo, kaj ĝi estas la kodo plej ofte mislegata kiel malĝusta pasvorto. La tunelo staras, la enirejo vidis identecon, kaj ĝi rifuzis la identecon. La kaŭzo ankoraŭ povas sidi ekster la pasvorta kampo.

Kontrolu unue la domajnan kampon, poste la precizajn signojn en la pasvorto. Pasvorto enhavanta spacon, citilon aŭ ŝel-specialan signon povas esti fuŝita antaŭ ol ĝi atingas la servilon; en Linux, pppd raportas la saman rifuzon kiel E=691 por necitita valoro aŭ mankanta domajno. Retajpu la sekreton anstataŭ alglui ĝin, kaj forigu ĉiun konservitan akreditaĵon, kiu povas teni pli malnovan valoron.

La branĉo, kiun homoj maltrafas, estas haltigita helposervo. Kiam vendista kliento dependas de sia propra servo por transdoni akreditaĵojn al la enirejo, malŝaltita aŭ kraŝinta servo produktas 691 eĉ kiam la pasvorto estas ĝusta. Kontrolu la servostaton de la vendisto antaŭ ol restarigi la konton, precipe post restarto aŭ ĝisdatigo.

Por apartigi la branĉojn, testu la saman uzantnomon kontraŭ alia funkcianta VPN-profilo aŭ RADIUS-testa konto. Se tio sukcesas, la akreditaĵo estas bona kaj la loka klienta vojo estas suspektinda. Se ĝi malsukcesas same, la problemo estas la konto aŭ la enireja politiko.

Ŝanĝu unu tavolon po provo

Laboru de ekstere enen: atingeblo kaj NAT-trapaso, poste la antaŭe komuna ŝlosilo, poste la loka adaptila stako, poste la akreditaĵo, poste la servila aro kaj servoj. Tiu ordo sekvas la etapojn, kiujn la kodoj priskribas, kaj tenas ĉiun rezulton atribuebla al unu ŝanĝo.

Tenu mallongan protokolon de la kodo antaŭ kaj post ĉiu provo, de la klienta versio, kaj de tio, ĉu la servilo aŭ la kliento estis ŝanĝita. Sinsekvo kiel 789, poste 720, poste 691 estas mapo de progreso; la sama kodo dufoje signifas, ke la lasta ŝanĝo ne traktis tiun etapon. Reinstali Windows forviŝas tiun mapon kaj malofte riparas malsukceson, kiu loĝas ĉe la enirejo.

Kiam la kodo ĉesas ŝanĝiĝi, ĉesu ŝanĝi aferojn. Registru la nunan kodon, la servilan adreson, la aŭtentikigan metodon kaj la tempon de la provo, poste komparu tiun registron kun funkcianta kliento. La diferenco inter la du registroj kutime estas pli malgranda ol la listo de riparoj, kiujn homoj provas defaŭlte.