¿NO_PROPOSAL_CHOSEN en L2TP? Examine primero la puerta de enlace

El aviso de nombre de usuario nunca aparece y el cliente informa de NO_PROPOSAL_CHOSEN. Las credenciales y la clave precompartida son irrelevantes en ese momento, porque los dos extremos no se han puesto de acuerdo sobre cómo proteger la fase 1. La mayoría de la gente responde pegando una cadena de cifrado que encontró en línea. Un análisis de la puerta de enlace responde a la misma pregunta con pruebas y lleva más o menos el mismo tiempo.

Qué descarta el mensaje

El rechazo ocurre en modo principal, antes de cualquier intercambio L2TP o PPP, así que ni el túnel ni la base de datos de usuarios se han consultado. La fase 1 negocia el cifrado, la integridad y un grupo Diffie-Hellman. La fase 2 negocia la propuesta ESP para los datos. Un fallo de la fase 1 no se arregla cambiando un ajuste PFS de la fase 2, y una asociación IKE completada no demuestra que la propuesta ESP encaje.

Anote el backend antes de editar la sintaxis: ipsec --version. libreswan y strongSwan aceptan grafías distintas de la propuesta para los mismos algoritmos.

Después lea el rechazo en contexto con journalctl --no-hostname _COMM=nm-l2tp-service _COMM=ipsec _COMM=pluto _COMM=charon _COMM=kl2tpd _COMM=xl2tpd _COMM=pppd.

Examine la puerta de enlace para conocer su conjunto de transformaciones

Un escáner pregunta directamente a la puerta de enlace qué transformaciones va a negociar. Detenga primero el servicio IPsec local para que la sonda no compita con su propio cliente y luego lea las líneas SA. Trate la lista como una prueba sobre el otro extremo, no como un menú para activarlo todo de golpe.

sudo ipsec stop
sudo ike-scan --trans=3des-sha1-modp1024 10.10.10.250 | grep SA=

Los equipos más antiguos suelen ofrecer 3DES, SHA1 y MODP1024, porque eran los valores predeterminados cuando se envió el producto y nadie los revisó. Guarde la salida sin procesar del análisis, porque es el único registro de lo que el otro extremo ofreció ese día. Si esa es la superposición más fuerte disponible, la escalada correcta es hacia el propietario de la puerta de enlace, no hacia una configuración de cliente que vuelve a habilitar criptografía débil para todos.

Ajuste la superposición sin desactivar la seguridad

Introduzca solo las transformaciones que aparecen tanto en el análisis como en su política. El ejemplo siguiente refleja una puerta de enlace que ofrece 3DES, SHA1 y MODP1024 en la fase 1. Fíjese en la advertencia sobre el backend: libreswan 4.x no compila el grupo modp1024, así que esto se aplica a strongSwan o a una compilación de libreswan con soporte de DH2. Verifique la versión antes de concluir que el cliente está roto.

Phase 1: 3des-sha1-modp1024
Phase 2: aes256-sha1,aes128-sha1,3des-sha1

Un signo de exclamación final fija una sola propuesta. Úselo para aislar una prueba y quítelo después para que la puerta de enlace pueda negociar algo más fuerte más adelante.

Compruebe el demonio y el puerto antes de reintentar

NetworkManager-l2tp inicia su propia instancia de xl2tpd. Si el servicio del sistema ya posee el puerto UDP 1701, el cliente recurre a un puerto de origen efímero, algo que el RFC 3193 permite y que algunos servidores descartan en silencio. Compruebe el propietario del socket antes del siguiente intento.

sudo ss -unlp | grep 1701
sudo systemctl stop xl2tpd.service
sudo systemctl disable xl2tpd.service

Los secretos generados obsoletos son otra causa silenciosa. Los archivos que hay bajo /etc/ipsec.d/ con el nombre de una conexión antigua pueden sobrevivir al perfil que los creó, así que elimine los que nada referencia y vuelva a intentarlo.

Por último, compruebe de dónde viene el consejo. Un ipsec.conf escrito para IKEv1 XAuth describe otro tipo de VPN, y su propuesta no es la única línea que estará mal en un perfil L2TP. Anote el conjunto de transformaciones que introdujo junto al perfil, para que la siguiente persona no repita la sonda.