L2TP/IPsec falla: aísle IPsec, la autenticación del túnel o el inicio de sesión PPP

Dentro de una conexión L2TP/IPsec se autentican tres cosas, y solo una de ellas afecta a la persona que marca. IPsec demuestra los extremos del túnel, la conexión de control L2TP puede volver a demostrar los pares con su propio secreto, y después PPP demuestra la cuenta de usuario dentro de la sesión. Un fallo en cualquier etapa parece un error genérico de inicio de sesión en el diálogo del cliente y se ve completamente distinto en el registro del servidor. Recorra las etapas en orden y deténgase en la primera que falle, porque toda etapa por debajo de una no probada también está sin probar.

Tres etapas de autenticación, tres identidades distintas

IPsec demuestra de quién son los extremos, con una clave precompartida o un certificado. Esa identidad pertenece a máquinas o pasarelas, nunca a la persona que está ante el teclado. Cuando los pares no logran ponerse de acuerdo en esta etapa, no se intercambia ni un solo paquete L2TP.

La conexión de control L2TP puede añadir un segundo intercambio de desafío y respuesta, separado, impulsado por un secreto compartido que ambos extremos deben tener.

El RFC 2661 hace opcional esa autenticación de la conexión de control, lo que explica por qué el mismo error produce síntomas distintos en dos servidores. Un despliegue que nunca configuró un secreto de túnel se salta la etapa por completo; uno que lo configuró solo en un lado falla antes de que PPP llegue a ofrecerse. Después PPP autentica al usuario con PAP, CHAP o MSCHAPv2 y entrega el nombre a un almacén de cuentas que puede ser local, estar en chap-secrets o en RADIUS. Una contraseña incorrecta en ese punto todavía le deja con un túnel funcionando y una sesión fallida.

Lea el punto de parada antes de editar una configuración

Empiece con ipsec --version para saber si la salida de estado pertenece a strongSwan o a Libreswan. Después lea el registro del servidor, no el diálogo del cliente, porque el servidor anota qué etapa se negó.

Una línea suele resolver el tique: una queja sobre IKE o sobre las propuestas es la primera etapa, un mensaje de la conexión de control es la segunda, y un rechazo del método PPP o de la cuenta es la tercera. Copie esa línea en el tique con la marca de tiempo. Adivinar desde el lado del cliente desperdicia la única prueba que ya tiene.

Mantenga el material de clave y las contraseñas fuera de ese pegado; el nombre de la etapa encamina el trabajo, y una clave precompartida filtrada reabre el tique con peores consecuencias.

Primer paso: ¿tiene IPsec una asociación?

Ejecute ipsec statusall en strongSwan o ipsec whack --status en Libreswan y busque una asociación hija establecida con contadores distintos de cero. ip xfrm state muestra la vista del núcleo en ambos. Un par de SA instalado con contadores que suben significa que la primera etapa está hecha y que puede continuar.

La ausencia total de asociación apunta a la dirección del par, al conjunto de propuestas o a la clave precompartida, y a veces a un dispositivo que reescribe UDP 500 mientras descarta UDP 4500. Una asociación que se establece y luego desaparece a los pocos segundos suele ser un desajuste de vigencia entre los dos extremos y no un problema de credenciales. Compruebe si ambos lados enumeran las mismas propuestas de cifrado y de hash antes de reescribir nada. Si no lo hacen, ninguna clave funcionará jamás.

Deténgase mientras falta la asociación. Editar las opciones de PPP en ese momento no cambia nada y esconde la avería real a la siguiente persona.

Segundo paso: ¿se autenticó la conexión de control L2TP?

Una vez que IPsec está en marcha, vigile el demonio L2TP para ver si una conexión de control alcanza un estado establecido, ya que PPP no puede empezar antes. Un rechazo en la conexión de control significa que el secreto del túnel difiere entre los extremos, o que un extremo exige un secreto que el otro nunca envía. Los clientes suelen exponer un único campo etiquetado como secreto compartido, y normalmente pertenece a IPsec y no a L2TP. Rellenarlo no configura el secreto del túnel, y borrarlo no lo desactiva.

Si ninguno de los dos lados tiene configurado un secreto de túnel, sáltese esta etapa y trate el fallo de la conexión de control como un problema de accesibilidad. Confirme que UDP 1701 llega al demonio y que ambos extremos coinciden en la misma encapsulación. Una regla de cortafuegos escrita para una de esas dos condiciones es una causa habitual de una conexión que se abre a medias.

Solo una sesión que empieza a negociar PPP ha superado realmente la etapa del túnel.

Tercer paso: ¿rechaza PPP la cuenta?

Un fallo de PPP se ve distinto desde fuera: el túnel está establecido, la sesión arranca y el demonio registra un fallo del método de autenticación o un rechazo de la cuenta. Lea el método que se nombra en ese mensaje. PAP y CHAP fallan por motivos distintos, y un servidor que rechaza uno rechazará a un cliente que solo ofrezca ese.

En un servidor Linux, revise el archivo de opciones que el demonio pasa a PPP, normalmente /etc/ppp/options.xl2tpd, y confirme qué métodos se aceptan y dónde se resuelven las cuentas. Un nombre que existe en RADIUS pero no en el archivo de secretos local falla limpiamente y parece una contraseña incorrecta. Después compruebe que el cliente ofrece un método que el servidor acepta, y no uno más fuerte que el servidor se niega a negociar. Cambiar la clave precompartida para reparar esta etapa pierde una tarde y no cambia nada.

Cuando la sesión por fin sube, la asignación de direcciones, el DNS y las rutas siguen sin comprobar, y cada uno falla en silencio a su manera. Mantenga las tres capas separadas en sus notas: una clave correcta con una cuenta equivocada siempre falla, y reparar una capa nunca repara otra.