L2TP se conecta pero la negociación PPP falla: ¿qué fase?

El túnel IPsec se establece, el cliente muestra un par protegido y luego la conexión muere antes de que algo llegue a la subred privada. Esa brecha es PPP haciendo su propio trabajo: las opciones de enlace, la autenticación de usuario y la asignación de dirección ocurren todas después de que el túnel cifrado ya existe. Nada de un intercambio exitoso de primera fase proporciona una contraseña ni una dirección interna. Lee las fases en orden y el fallo suele nombrarse solo.

El túnel es solo la primera capa

L2TP transporta tramas PPP dentro de un túnel protegido por IPsec, lo que significa que dos negociaciones independientes deben tener éxito antes de que se pueda enrutar un paquete. La exterior demuestra que ambos extremos coinciden en claves e identidades. La interior decide los parámetros del enlace, si el usuario se autentica y qué dirección recibe el cliente.

Un fallo dentro de PPP parece un túnel roto en cada cliente que solo muestra una luz de estado. Tratarlo como un problema de túnel lleva a regenerar claves, reiniciar servicios y, al final, sustituir un secreto compartido que nunca estuvo mal. La distinción útil es barata: si el intercambio con el par se completó y el cliente pasó a una petición de nombre de usuario o a una etapa de autenticación, el túnel está bien. Todo lo posterior a ese punto pertenece a PPP.

Lee la última fase que tuvo éxito

Recorre el registro hacia delante y detente en la primera fase que no se completó. Primero viene LCP, después la autenticación y después IPCP para los parámetros de IPv4.

sudo journalctl -u xl2tpd -b --no-pager | tail -n 40
sudo journalctl -b --no-pager | grep -i -E 'pppd|lcp|chap|ipcp'
ip -4 address show ppp0

Un tiempo de espera de LCP significa que los dos extremos nunca acordaron las opciones básicas del enlace, lo que es un perfil que no coincide o un protocolo interno bloqueado, no una contraseña incorrecta. Un rechazo explícito de autenticación es el caso contrario: el enlace subió y un lado rechazó las credenciales. Un tiempo de espera de IPCP tras una autenticación correcta apunta a grupos de direcciones o a la política del servidor. Cada uno tiene un dueño distinto y una reparación distinta, y por eso la fase importa más que el texto final del error.

Guarda el fragmento del registro junto con el nombre de la fase en el ticket. Una cola pegada sin la frontera de fase invita al siguiente lector a adivinar, y adivinar aquí cuesta una hora.

Acuerdo entre el cliente y el servidor

Ambos extremos deben aceptar el mismo método de autenticación, y un perfil guardado puede pedir uno que el servidor retiró el trimestre pasado. Los despliegues gestionados también ocultan el lado del servidor, donde el motivo del rechazo suele registrarse contra el usuario y no contra el dispositivo.

Activa un método compatible en lugar de cada opción heredada, porque un cliente que ofrece cinco métodos oculta cuál falló. Pide al administrador la política del lado del servidor y el rechazo exacto, lo que no exige que nadie publique una contraseña. Un método heredado activado para rescatar a un solo cliente tiende a extenderse a cada perfil que copia el archivo.

Verifica la dirección, no el inicio de sesión

Un inicio de sesión completado no es una sesión utilizable. IPCP negocia la dirección interna, y un grupo agotado o una política que niega al cliente todavía pueden dejar un túnel conectado sin nada que enrutar.

ip -4 address show ppp0
ip route get 10.52.9.1
ping -c 2 10.52.9.1

Comprueba primero la dirección interna, luego la ruta y el resolutor para el recurso que realmente necesitas. Una dirección interna no es la salida pública que informa un sitio web, y confundir las dos cosas manda a la gente a cazar una fuga que no existe. Prueba el recurso privado por dirección antes de probarlo por nombre, para que un fallo de DNS no se confunda con un fallo de enrutamiento.

Escribe la fase, el método y la dirección en una sola nota y ponle fecha. Si la misma cuenta vuelve a fallar dentro de un mes, esa nota es la diferencia entre una comprobación de cinco minutos y una investigación nueva. Los fallos en fases distintas son incidentes distintos, aunque el cliente muestre un solo diálogo.