Error 789 de L2TP/IPsec a Windows: creeu el perfil i fixeu la proposta
L’error 789 falla en l’intercanvi IPsec, no a la contrasenya. Creeu el perfil L2TP amb un script, fixeu la proposta i llegiu els codis posteriors per etapa.
L’error 789 en una connexió L2TP de Windows significa que el túnel ha mort dins de l’intercanvi de seguretat IPsec, cosa que passa molt abans que Windows enviï una contrasenya d’usuari enlloc. Reintentar la contrasenya, o restablir-la al directori, no pot fer avançar aquesta etapa. El que sí que la fa avançar és reconstruir la connexió des de PowerShell amb la proposta que la passarel·la ofereix realment, perquè l’assistent de Configuració tria les transformacions IPsec en silenci i mai no us mostra què ha triat. Aquest és el manual per a això: creeu el perfil, fixeu la proposta i després feu servir una taula d’etapes perquè el codi següent us digui alguna cosa.
Creeu el perfil sense l’assistent
Add-VpnConnection escriu una entrada nativa de llibreta de telèfons, així que el resultat és el mateix objecte que l’aplicació Configuració editarà més tard. Executeu-lo des d’una sessió elevada quan la connexió hagi d’existir per a cada compte de la màquina, o des del context d’usuari quan hagi de romandre privada:
Add-VpnConnection -Name "Contoso L2TP" `
-ServerAddress 203.0.113.10 `
-TunnelType L2tp `
-EncryptionLevel Required `
-AuthenticationMethod MSChapv2 `
-RememberCredential -Force
Feu coincidir -AuthenticationMethod amb el que ofereix la passarel·la. MSChapv2, EAP i PAP no són intercanviables, i un perfil que exigeix un mètode que el servidor no acceptarà falla abans que es consulti cap registre d’usuari. Manteniu -EncryptionLevel Required per a qualsevol cosa real; Optional permet que Windows accepti un túnel sense xifrar si l’altre extrem n’ofereix un, cosa que és una drecera de laboratori i no una configuració per enviar.
Si passeu -L2tpPsk, aquesta clau prèviament compartida s’escriu al perfil del disc, des d’on qualsevol que pugui llegir el perfil en aquesta màquina la pot recuperar. Feu servir un certificat per autenticar l’altre extrem quan la passarel·la ho admeti, i quan una PSK sigui inevitable, manteniu-la fora del repositori i de l’historial de l’intèrpret d’ordres en lloc d’enganxar-la a cada execució d’aprovisionament.
Fixeu la proposta en lloc d’acceptar els valors predeterminats
Windows omple les transformacions IPsec ell mateix, i per això dues màquines amb una connexió aparentment idèntica poden fallar de manera diferent contra la mateixa passarel·la. Set-VpnConnectionIPsecConfiguration és la manera compatible de fixar-les:
Set-VpnConnectionIPsecConfiguration -ConnectionName "Contoso L2TP" `
-AuthenticationTransformConstants SHA256128 `
-CipherTransformConstants AES128 `
-EncryptionMethod AES128 `
-IntegrityCheckMethod SHA256 `
-DHGroup Group14 `
-PfsGroup None `
-PassThru -Force
Aquest conjunt és una disposició L2TP/IPsec habitual, no una resposta universal. Cada paràmetre accepta una llista fixa de valors, i una combinació que la plataforma no pot mapar torna com a error del cmdlet en lloc d’un perfil debilitat en silenci. Tracteu aquest error com una afirmació sobre els valors, no sobre els vostres permisos.
Copieu la proposta de la documentació de la passarel·la o de les seves configuracions actives de fase 1 i fase 2, i canvieu un camp alhora només mentre la passarel·la registra les transformacions que rebutja. Recórrer cinc camps produeix una connexió que funciona per accident i un registre que no explica res a la persona següent.
Llegiu una fallada per etapa, no pel text de l’error
789 pertany a una família de codis que a la finestra del client semblen tots iguals. Situeu el codi davant de l’etapa a què pertany abans de tornar a tocar el perfil:
| What you see | Stage that failed | Check first |
|---|---|---|
| Nothing happens, then a timeout | No IKE response at all | Server address, UDP 500 and 4500 reachability, NAT traversal on the gateway |
| Error 789 | IKE security exchange | Proposal, pre-shared key, certificate trust and client clock |
| Error 691 or a repeated password prompt | User authentication | Account state, domain, RADIUS or NPS policy |
| Tunnel up, some hosts unreachable | Routing or DNS after PPP | Split-tunnel routes, pushed DNS, remote subnet mask |
Les dues funcions de les credencials importen aquí. Una clau prèviament compartida o un certificat autentica els extrems entre ells, mentre que MSChapv2 o EAP us autentica dins del túnel. Restablir una contrasenya d’usuari no pot arreglar la primera, un secret compartit nou no pot arreglar la segona, i canviar les dues alhora destrueix l’evidència de quina era l’equivocada.
En el camí del certificat, comproveu el rellotge del client, la cadena de confiança i la identitat que espera la passarel·la abans de plantejar-vos relaxar la validació. Desactivar la validació converteix un 789 visible en un túnel que es connecta confiant en l’extrem equivocat, i res al client no us dirà que això ha passat. llista d’errors d’accés remot de Microsoft és la referència per als codis mateixos, i separa les fallades de la capa de seguretat de les fallades d’inici de sessió.
Verifiqueu des dels dos extrems abans de donar-ho per arreglat
Torneu a llegir el perfil, però no espereu la proposta a la sortida. Get-VpnConnection informa del nom, l’adreça del servidor, el tipus de túnel, el nivell de xifratge i el mètode d’autenticació, i no sap res de les transformacions, així que la lectura confirma que l’entrada existeix i apunta a l’amfitrió correcte:
Get-VpnConnection -Name "Contoso L2TP" |
Select-Object Name, ServerAddress, TunnelType, EncryptionLevel, AuthenticationMethod
Marqueu des de la línia d’ordres per obtenir un número en lloc d’una finestra: rasdial "Contoso L2TP" retorna el mateix codi de fallada que retornaria la interfície, i rasdial "Contoso L2TP" /disconnect l’esborra entre intents. Després llegiu el costat de la passarel·la per a aquest mateix intent. Un ipsec statusall de strongSwan o un registre IKE del router diu quina proposta ha arribat i quina s’ha rebutjat, i comparar-ho amb els valors del cmdlet és l’únic pas que demostra de veritat que els dos extrems s’han posat d’acord.
Una connexió correcta no és la línia d’arribada. Obriu l’aplicació que importa a l’usuari, perquè les rutes, el DNS empès i la configuració de túnel dividit fallen després que el túnel estigui en marxa i no produeixen cap finestra d’error.
Automatitzeu-ho i torneu enrere net
La instal·lació desatesa és la raó per fer un script d’això, i el pas de marcatge és on es filtren les credencials. rasdial les agafa a la seva línia d’ordres, on altres usuaris locals i la majoria de recollidors de registres les poden llegir:
subprocess.run(["rasdial", "Contoso L2TP"], check=True)
Preferiu una credencial limitada al compte que executa la feina, o deixeu que el perfil la desi amb -RememberCredential, en lloc de passar una contrasenya com a argument en una tasca programada. Les ordres d’aprovisionament mateixes són segures de repetir amb -Force, però superposaran encantades una proposta antiga, així que una reexecució només ajuda si el script porta els valors actuals.
Els perfils persisteixen entre reinicis i sobreviuen a la configuració de passarel·la per a la qual es van crear. Quan la proposta de la passarel·la es mou, elimineu l’entrada i torneu-la a crear en lloc d’apilar-hi un segon conjunt de valors: Remove-VpnConnection -Name "Contoso L2TP" -Force, i després repetiu els dos cmdlets amb el conjunt nou.
Tanqueu el bucle amb quatre comprovacions que viuen al costat del script: Get-VpnConnection mostra el tipus de túnel i el nivell de xifratge esperats; la passarel·la registra una fase 1 i una fase 2 completades per a l’adreça del vostre client; rasdial retorna èxit i l’aplicació s’obre; i la proposta enregistrada al script coincideix amb la configuració actual de la passarel·la. Quan arribi el 789 següent, aquesta comparació triga minuts en lloc d’una tarda.