Qué etapa de la VPN ha fallado: IPsec, el control L2TP o la autenticación PPP

Cambió la contraseña y nada se movió, porque el fallo nunca estuvo en PPP. L2TP/IPsec informa de un solo error de conexión para cinco entregas muy distintas, y cada entrega tiene su propia reparación. Trabaje al revés: encuentre la última etapa que funcionó y cambie solo lo que viene después. El orden de abajo también decide qué pruebas recoge primero.

Responda cuatro preguntas en orden

Fuerce un intento nuevo, porque algunos clientes siguen mostrando el error anterior hasta que el perfil se desconecta y se vuelve a conectar. Después responda esto: ¿había una asociación de seguridad IPsec, aparecieron una conexión de control L2TP y una llamada, llegó PPP a un veredicto de autenticación y entregó IPCP una dirección al cliente? El primer no es la etapa que arregla. Todo lo posterior no se ha probado, así que un nombre de usuario rechazado no demuestra nada cuando nunca existió una asociación.

Sincronice los relojes de ambos extremos antes de comparar. Un reintento que limpió IPsec y falló en PPP parece un solo fallo cuando el cliente solo muestra el mensaje final y el registro del servidor aún guarda el intento anterior. Lea por marca de tiempo, no por la línea más ruidosa.

Cuando solo tiene la captura de pantalla del usuario, apóyese en la separación más barata: una clave precompartida incorrecta y un xl2tpd que nunca responde producen el mismo texto en el diálogo de Windows, pero uno necesita un secreto cambiado en ambos extremos y el otro un demonio iniciado o una regla de cortafuegos en el propio servidor. Un dispositivo intermedio no puede descartar el 1701 interior una vez que IPsec en modo transporte lo ha envuelto, así que no busque un filtro de ruta que no existe.

Qué posee realmente cada capa

IPsec protege los paquetes entre los dos pares; L2TP transporta una sesión PPP dentro de esa ruta protegida, por eso RFC 3193 especifica el modo transporte en lugar de un túnel propio. La etiqueta del cliente dice L2TP, así que el túnel y el inicio de sesión parecen un solo mecanismo. No lo son: la conexión de control L2TP autentica los extremos del túnel donde un despliegue lo habilita, y PPP autentica por separado al usuario con CHAP, PAP o MS-CHAPv2 según la política del servidor.

Esa separación explica los dos secretos que la gente confunde. Una clave precompartida autentica a los pares IPsec. Un usuario y una contraseña identifican al usuario ante PPP. Reescribir el secreto compartido de Windows en un perfil que se autentica con certificados no cambia nada en la etapa que falla, y editar la contraseña PPP no puede aportar un canal protegido ausente. La misma contención se aplica a la comprobación de identidad: no desactive la identidad del par ni la validación del certificado para conseguir un túnel, porque entonces lo que conecta es la ruta, no el par.

La autenticación tampoco es el final de PPP. Una vez aceptado el usuario, IPCP negocia la dirección del cliente y las opciones DNS y WINS que el servidor está dispuesto a entregar. Un cliente puede pasar CHAP o MS-CHAPv2 y aun así quedarse sin dirección, lo que es un fallo dentro de PPP y no un problema de enrutamiento. L2TP simple sin IPsec sigue siendo válido y desprotegido, así que una conexión correcta nunca demuestra que el tráfico esté protegido; compruebe qué exige el servidor, no la etiqueta del cliente.

Decida por la primera etapa que falta

Lea la tabla por el primer elemento que falta, de izquierda a derecha. La columna derecha es el único trabajo que merece la pena en ese momento; todo lo que queda a su izquierda ya está probado, y volver a probarlo quema la ventana de interrupción sin añadir información.

Tres filas merecen un aviso. La fila 1701 es donde suelen aterrizar los clientes Windows detrás de NAT: la asociación se completa, luego no llega nada, y la causa es la encapsulación, no una contraseña mala. La fila IPCP es la que se lee mal como problema de ruta, porque Windows envuelve la dirección ausente en el error 720 y el icono de la bandeja solo dice que la conexión falló; ese fallo se sitúa después de la autenticación y antes del enrutamiento. La última fila no es ningún fallo de IPsec, aunque el icono diga desconectado.

Comandos que separan las capas

En un servidor Linux con strongSwan, swanctl --list-sas lista las asociaciones establecidas con la identidad del par, y ipsec statusall cubre hosts strongSwan y libreswan más antiguos. Debajo, ip xfrm state muestra las asociaciones reales del núcleo, mientras que ss -lunp | grep 1701 demuestra dónde está ligado xl2tpd. Ejecute xl2tpd -D en primer plano para ver aparecer las conexiones de control y las llamadas, y active la depuración de pppd en /etc/ppp/options.xl2tpd para ver el método ofrecido y la respuesta.

Cuando los registros muestran una autenticación correcta, la siguiente pregunta es si IPCP se completó. Compruebe que ip range en la sección [lns default] de /etc/xl2tpd/xl2tpd.conf todavía tenga direcciones libres, y que /etc/ppp/options.xl2tpd lleve realmente ms-dns y ms-wins si el cliente los espera. Un conjunto agotado y una opción DNS ausente se ven distintos en el cable: el primero deja al cliente sin dirección y con un 720, el segundo da dirección pero ningún resolutor, así que los nombres fallan mientras los ping a direcciones crudas funcionan. Ninguno se repara volviendo a introducir la contraseña.

En el cliente, el complemento L2TP de NetworkManager escribe la conversación de pppd en el diario, así que journalctl -u NetworkManager -b normalmente separa túnel levantado, autenticación rechazada de ningún túnel. En Windows, Get-VpnConnection informa de la configuración real de autenticación del perfil, y los eventos RasClient en Application del Visor de eventos nombran el componente que falla. Cuando el diálogo es demasiado vago, active netsh ras set tracing * enable.

Las capturas requieren una precaución. Con IPsec en modo transporte, el UDP 1701 interior va cifrado, así que una captura en la interfaz exterior muestra ESP, o UDP 4500 bajo NAT-T, y ningún L2TP. Que falte 1701 en una captura es esperable y no es prueba de un puerto bloqueado; observe si se mueven los contadores de ESP o de 4500.

NAT, MTU y rutas: donde la pila le engaña

NAT rompe las suposiciones antes de que nada esté autenticado. ESP es su propio protocolo IP, así que un dispositivo que traduce lo descarta salvo que los pares encapsulen; eso es lo que aporta el UDP 4500. En un servidor Windows que él mismo está detrás de un router doméstico o de una pasarela NAT en la nube, la etapa IPsec falla con el error 789 hasta que AssumeUDPEncapsulationContextOnSendRule se pone en 2 bajo la clave PolicyAgent y la máquina se reinicia, y el fallo sigue siendo indistinguible de un puerto cerrado. Los clientes detrás de NAT son más fáciles: con una dirección pública en el servidor, NAT-T sobre UDP 4500 los transporta y ese valor no interviene.

Una vez levantado PPP, un MTU con agujero negro imita un túnel muerto: los paquetes pequeños pasan, un apretón de manos TLS o la carga de una página se cuelgan, y el cliente puede seguir mostrando conectado. Baje el MTU de la interfaz o fije el MSS en la pasarela antes de culpar al servidor. El enrutamiento de túnel dividido es el otro impostor; una subred enviada con la máscara equivocada deja el túnel sano y una aplicación inalcanzable. Un nombre de host privado añade su propio salto: si la consulta sale por el resolutor local, el nombre no se resuelve antes de que se pruebe ninguna ruta.

Lista de comprobación antes de tocar credenciales

Trabaje la lista en orden y deténgase en el primer elemento que falle. Cada paso es barato, y cada uno descarta toda una clase de ediciones.

1. Confirme que la asociación existe en ambos extremos, emparejada por la identidad del par y no por una etiqueta de conectado.
2. Confirme que el UDP 1701 llega a xl2tpd; una asociación sin llamada es su fallo.
3. Lea el veredicto de PPP y, si autenticó, el resultado de IPCP, antes de suponer que la contraseña es incorrecta.
4. Solo ahora vuelva a introducir las credenciales en el formato que espera el servidor, porque un prefijo de dominio cambia la cuenta.
5. Si sigue fallando, capture ambos extremos con marcas de tiempo alineadas y compare etapa por etapa.

Parar en el segundo paso significa un problema de ruta o de encapsulación, y ninguna edición de la contraseña lo moverá. Parar en el tercer paso significa que el registro ya nombra el método o el conjunto de direcciones que hay que arreglar. En ambos casos el siguiente cambio es uno que puede justificar, y deja de dar vueltas a ajustes que nunca intervinieron.