¿Por qué PPTP y L2TP/IPsec se detienen antes del usuario?

Que no aparezca el usuario es un regalo diagnóstico: PPP aún no ha arrancado, así que la cuenta, la contraseña y la política de dominio todavía no se han consultado. En una conexión PPTP o L2TP/IPsec el cliente pide credenciales solo después de que el túnel existe y el servidor ha iniciado una sesión PPP. Todo lo que puede fallar antes de ese momento es transporte, intercambio de claves o montaje del túnel, una superficie mucho menor que «la VPN está rota».

Un aviso ausente reduce el fallo a tres etapas

Anote la última etapa que haya tenido éxito visible, porque cada una tiene un dueño distinto y una solución distinta. Adivinar la configuración de la cuenta mientras está atascado dos etapas antes es como se pierde una tarde.

Un cliente que expira sin aviso nunca obtuvo una asociación IPsec, así que el fallo está en IKE o en si sus paquetes llegan siquiera a la puerta de enlace. El que informa que está verificando credenciales y luego cae llegó más lejos de lo que sugiere el mensaje. Un aviso seguido de un rechazo es autenticación PPP, y eso pertenece a un artículo de cuenta, no a este.

Primera etapa: el protocolo que un cortafuegos descarta en silencio

PPTP necesita TCP 1723 para su canal de control y el protocolo IP 47 para la ruta de datos, y los dos viajan por separado. Muchas redes reenvían 1723 y descartan el protocolo 47, lo que produce un túnel que negocia y luego no transporta absolutamente nada. Un enrutador que hace NAT también necesita un paso compatible con GRE, y una ruta de acceso solo IPv6 no puede transportar PPTP bajo ninguna configuración.

L2TP sobre IPsec gasta el puerto 500 en IKE y el puerto 4500 en el cruce de NAT, y luego envuelve el propio tráfico L2TP en 1701, mientras ESP transporta la carga protegida en cuanto existe la asociación. Permita los dos puertos de control pero no ESP y obtendrá exactamente el síntoma del título: progreso visible y luego un cliente muerto antes de cualquier diálogo de credenciales. Probar desde un punto de acceso móvil es una forma barata de separar un problema de cliente de un problema de ruta.

Segunda etapa: una clave que no es la clave, una propuesta que no se ofrece

Una clave precompartida que no coincide falla rápido y en silencio, y la versión habitual es una clave que parece correcta en pantalla mientras lleva un salto de línea pegado o un espacio final. En un cliente Linux el diálogo no es necesariamente la fuente de la verdad: el complemento L2TP de NetworkManager guarda secretos en archivos bajo /etc/ipsec.d/, y un archivo antiguo por conexión que /etc/ipsec.secrets todavía incluye se usará en lugar del que acaba de escribir. Copie ese archivo a un lugar seguro, sáquelo de la ruta de inclusión y luego vuelva a escribir la clave a mano.

La otra mitad de esta etapa es la propuesta. Ambos extremos deben ponerse de acuerdo en el mismo conjunto de algoritmos de fase 1 — cifrado, integridad y grupo Diffie-Hellman — y en transformaciones ESP coincidentes para la fase 2, o la asociación no se forma en absoluto. Una pasarela que solo ofrece 3DES, SHA1 y MODP1024 rechazará un cliente configurado para algoritmos más fuertes, y su registro nombra la transformación rechazada. El registro nombra la discrepancia si lo lee en lugar de reiniciar el servicio otra vez. En vez de copiar una cadena de algoritmos de un hilo de foro, pregunte a la pasarela qué transformaciones negociará realmente: ike-scan apuntado a su dirección devuelve las transformaciones que negociará. Si la única oferta es criptografía que su política ya no permite, la corrección corresponde a la pasarela, no a una degradación del cliente.

En Windows la clave y el método de autenticación viven en el perfil de VPN, y una discrepancia aparece antes del aviso de credenciales y no después. Cuando el receptor es un Windows Server, confirme que el rol de acceso remoto está instalado, que el certificado coincide con el nombre al que se conectan los clientes y que ningún filtro de puertos es más estrecho que los protocolos anteriores.

Tercera etapa: el túnel existe y PPP nunca arranca

Cuando IKE termina y el aviso sigue sin aparecer, mire el demonio del túnel en lugar del cortafuegos. L2TP necesita algo escuchando en UDP 1701 — xl2tpd o kl2tpd en Linux, el servicio de acceso remoto en Windows — y un servicio instalado pero detenido se ve desde el cliente igual que un paquete descartado. Compruebe el oyente antes de reabrir reglas que ya verificó. Después PPP tiene que negociar, y el primer intercambio LCP es donde suele aterrizar un fallo silencioso.

Una trampa de esta etapa no es ningún fallo de red: Windows permite una sola conexión de un tipo de VPN dado a la vez, así que un segundo intento devuelve el error 937, «otra conexión de este tipo está en uso». Es una regla local, y la forma de sortearla es otro dispositivo, otro tipo de túnel o compartir la única conexión que ya existe.

Lea el registro en orden de etapas en lugar de adivinar

Detenga el cliente, vuelva a iniciarlo y lea los componentes en el orden en que escriben en el registro. Es decir, primero el demonio IPsec — strongSwan o Libreswan, y ipsec --version le dice cuál — luego el demonio L2TP, luego pppd. El componente que haya escrito en último lugar antes del fallo marca la etapa que hay que investigar, porque todo lo que viene después en la secuencia no se ejecutó en absoluto.

Verifique con una conexión nueva y no con una sesión guardada, porque un cliente que se reconecta desde la caché puede saltarse partes del intercambio y reproducir un resultado obsoleto. Confirme alcance, intercambio de claves, túnel y PPP uno a uno, en ese orden. Entonces el aviso ausente deja de ser un misterio y se convierte en la segunda línea de una lista con la que realmente se puede trabajar. Esa lista es también lo que le entrega al equipo de red, al que de otro modo se pediría que revisara el cortafuegos por un fallo que vive en un demonio no iniciado.