L2TP sin IPsec en Linux: xl2tpd, pppd y NAT

El L2TP puro es PPP dentro de un sobre, y nada más. Transporta sus tramas; no las cifra ni demuestra quién está al otro lado, y por eso casi todos los despliegues meten IPsec debajo. Todavía existen razones honestas para usar la versión desnuda: un banco de laboratorio, un paso de migración o un enlace que ya está dentro de otra ruta protegida.

Si decide seguir adelante, anote esa advertencia en la nota de diseño y déjela ahí. Lo que sigue es la ruta operativa que uso en hosts de la familia Debian y RHEL: qué archivo se ocupa de qué, la MTU que evita el atasco clásico y las reglas de reenvío que hacen que el túnel valga la pena.

Tres archivos se reparten el trabajo

xl2tpd termina la conexión de control y entrega cada sesión a un demonio PPP, así que la configuración se reparte entre dos programas que nunca leen los archivos del otro. El escucha vive en /etc/xl2tpd/xl2tpd.conf, dentro de una sección [lns default] que nombra el conjunto de direcciones con ip range, el extremo del servidor con local ip y la entrega a PPP con pppoptfile. Active require authentication = yes, deje length bit y flow bit habilitados y elija un conjunto que nada más del host esté usando ya.

La política PPP corresponde al archivo que nombre esa opción, normalmente /etc/ppp/options.xl2tpd: auth, rechazos para pap, chap y mschap, require-mschap-v2, una MTU y una MRU de 1460 y una dirección DNS a la que el cliente pueda llegar después de levantar el enlace. Las credenciales son otra vez un tercer archivo, /etc/ppp/chap-secrets, donde el segundo campo debe coincidir con el nombre de la sección LNS y el cuarto puede fijar una dirección concreta del conjunto.

Por qué el túnel conecta y luego se atasca

Una trama Ethernet de 1500 bytes no cabe dentro de una ruta que ya gasta bytes en sus propias cabeceras. La cabecera IPv4 exterior cuesta 20, UDP cuesta 8 y la de L2TP unos 12, lo que deja 1460 para PPP y su carga. Anunciar esa cifra menor en PPP es lo que impide que los paquetes grandes se fragmenten o se descarten en silencio en algún punto intermedio.

El síntoma es un túnel que parece sano hasta que llega tráfico real: los pings y los mensajes de control pasan, una copia de archivo se cuelga y nada en el registro lo explica. Baje la MTU y la MRU a la vez en ambos extremos. Ajustar solo al cliente suele convertir un atasco duro en uno intermitente, que es peor de diagnosticar.

Un puerto lleva dos conversaciones

El UDP 1701 está debajo de las dos mitades del protocolo, y ese único hecho rompe más reglas de cortafuegos que cualquier otra parte de la instalación. Primero llegan una petición de inicio de conexión de control y su respuesta; la petición de sesión y la confirmación que siguen no establecen nada más que el par de identificadores. Después toma el relevo PPP, con control de enlace, luego autenticación y luego protocolo de control de IP para acordar las direcciones. Cada etapa tiene su propio vocabulario en el registro, y ninguna se anuncia como un fallo de L2TP.

Leer una captura exactamente en ese orden le dice qué etapa falló, y un fallo de autenticación PPP no se arreglará editando xl2tpd. El puerto compartido explica otro fallo habitual: una regla que solo permite los primeros paquetes de un flujo deja que la sesión se establezca y luego bloquea la transferencia. Permita el 1701 para toda la conversación, en ambos sentidos.

Hacer útil el túnel: reenvío y NAT

Una sesión por sí sola solo llega al servidor. El acceso a internet de los clientes necesita reenvío, una regla NAT para el conjunto en el enlace ascendente y un DNS que el cliente pueda consultar de verdad una vez levantado el enlace. El conjunto también debe quedar fuera del rango de la LAN, o las respuestas dirigidas a los clientes se entregan localmente en lugar de empujarse de vuelta al túnel.

En el servidor, active el reenvío con sysctl -w net.ipv4.ip_forward=1, traduzca el conjunto con iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE y después acepte el tráfico saliente del túnel con una regla FORWARD para -i ppp0 -o eth0 y el tráfico de vuelta con la regla espejo más -m state --state RELATED,ESTABLISHED. Haga persistentes esas reglas entre reinicios, porque un servidor que vuelve sin ellas se parece exactamente a una configuración L2TP rota.

Llegar a la propia LAN del servidor es otra tarea: añada una ruta de retorno para el conjunto en el router de la LAN, o proxy ARP en el servidor. Esconder a los clientes detrás de NAT cuando algo dentro de la LAN tiene que dirigirse a ellos directamente solo programa una segunda sesión de depuración para más adelante.

Qué no hace la pila desnuda y cómo verificarlo

Ninguna parte de esta pila cifra las tramas PPP, y nada en ella autentica el extremo remoto como el servidor que usted eligió de verdad. MS-CHAPv2 sí protege el intercambio de credenciales de un oyente que solo mira, pero un atacante situado en la ruta todavía puede interferir en la sesión. El cliente nativo de Windows ofrece L2TP solo junto con IPsec, así que cuente con Linux, el firmware de los routers y clientes de terceros como sus pares. Trate la configuración desnuda como un peldaño de diagnóstico, nunca como el lugar donde detenerse.

Verifique en un orden fijo: ejecute xl2tpd -D en primer plano, vigile el registro para la etapa PPP, lea la dirección asignada desde ip addr en ambos extremos y luego capture el UDP 1701 para confirmar que los datos fluyen después de levantar la sesión. Si los cuatro coinciden y el tráfico sigue fallando, la culpa es del enrutamiento, del NAT o de la MTU, no del propio L2TP.