L2TP sen IPsec en Linux: xl2tpd, pppd e NAT

O L2TP nu é PPP dentro dun sobre, e nada máis. Transporta as súas tramas; non as cifra nin demostra quen está ao outro lado, e por iso case todos os despregamentos meten IPsec debaixo. Aínda existen razóns honestas para usar a versión espida: un banco de laboratorio, un paso de migración ou un enlace que xa está dentro doutra ruta protexida.

Se decide seguir adiante, anote esa advertencia na nota de deseño e déixea aí. O que segue é a ruta operativa que uso en hosts da familia Debian e RHEL: que ficheiro se ocupa de que, a MTU que evita o atasco clásico e as regras de reenvío que fan que o túnel pague a pena.

Tres ficheiros reparten o traballo

xl2tpd remata a conexión de control e entrega cada sesión a un demo PPP, así que a configuración repártese entre dous programas que nunca len os ficheiros do outro. O escoitante vive en /etc/xl2tpd/xl2tpd.conf, dentro dunha sección [lns default] que nomea o conxunto de enderezos con ip range, o extremo do servidor con local ip e a entrega a PPP con pppoptfile. Active require authentication = yes, deixe length bit e flow bit habilitados e escolla un conxunto que nada máis do host estea a usar xa.

A política PPP pertence ao ficheiro que nomee esa opción, normalmente /etc/ppp/options.xl2tpd: auth, rexeitamentos para pap, chap e mschap, require-mschap-v2, unha MTU e unha MRU de 1460 e un enderezo DNS ao que o cliente poida chegar despois de levantar o enlace. As credenciais son outra vez un terceiro ficheiro, /etc/ppp/chap-secrets, onde o segundo campo debe coincidir co nome da sección LNS e o cuarto pode fixar un enderezo concreto do conxunto.

Por que o túnel conecta e logo atasca

Unha trama Ethernet de 1500 bytes non cabe dentro dunha ruta que xa gasta bytes nas súas propias cabeceiras. A cabeceira IPv4 exterior custa 20, UDP custa 8 e a de L2TP uns 12, o que deixa 1460 para PPP e a súa carga. Anunciar esa cifra menor en PPP é o que impide que os paquetes grandes se fragmenten ou se descarten en silencio nalgún punto intermedio.

O síntoma é un túnel que parece san ata que chega tráfico real: os pings e as mensaxes de control pasan, unha copia de ficheiro colga e nada no rexistro o explica. Baixe a MTU e a MRU á vez nos dous extremos. Axustar só o cliente adoita converter un atasco duro nun intermitente, que é peor de diagnosticar.

Un porto leva dúas conversas

O UDP 1701 está debaixo das dúas metades do protocolo, e ese único feito rompe máis regras de cortalumes que calquera outra parte da instalación. Primeiro chegan unha petición de inicio de conexión de control e a súa resposta; a petición de sesión e a confirmación que seguen non establecen nada máis que o par de identificadores. Despois toma o relevo PPP, con control de enlace, logo autenticación e logo protocolo de control de IP para acordar os enderezos. Cada etapa ten o seu propio vocabulario no rexistro, e ningunha se anuncia como un fallo de L2TP.

Ler unha captura exactamente nesa orde dille que etapa fallou, e un fallo de autenticación PPP non se arranxará editando xl2tpd. O porto compartido explica outro fallo habitual: unha regra que só permite os primeiros paquetes dun fluxo deixa que a sesión se estableza e despois bloquea a transferencia. Permita o 1701 para toda a conversa, en ambos os sentidos.

Facer útil o túnel: reenvío e NAT

Unha sesión por si soa só chega ao servidor. O acceso a internet dos clientes necesita reenvío, unha regra NAT para o conxunto no enlace ascendente e un DNS que o cliente poida consultar de verdade unha vez levantado o enlace. O conxunto tamén debe quedar fóra do rango da LAN, ou as respostas dirixidas aos clientes entréganse localmente en lugar de empuxarse de volta ao túnel.

No servidor, active o reenvío con sysctl -w net.ipv4.ip_forward=1, traduza o conxunto con iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE e despois acepte o tráfico saínte do túnel cunha regra FORWARD para -i ppp0 -o eth0 e o tráfico de volta coa regra espello máis -m state --state RELATED,ESTABLISHED. Faga persistentes esas regras entre reinicios, porque un servidor que volta sen elas parécese exactamente a unha configuración L2TP rota.

Chegar á propia LAN do servidor é outra tarefa: engada unha ruta de retorno para o conxunto no router da LAN, ou proxy ARP no servidor. Agochar os clientes detrás de NAT cando algo dentro da LAN ten que dirixirse a eles directamente só programa unha segunda sesión de depuración para máis adiante.

Que non fai a pila espida e como verificalo

Ningunha parte desta pila cifra as tramas PPP, e nada nela autentica o extremo remoto como o servidor que vostede escolleu de verdade. MS-CHAPv2 si protexe o intercambio de credenciais dun oínte que só mira, pero un atacante situado na ruta aínda pode interferir na sesión. O cliente nativo de Windows ofrece L2TP só xunto con IPsec, así que conte con Linux, o firmware dos routers e clientes de terceiros como os seus pares. Trate a configuración espida como un chanzo de diagnóstico, nunca como o lugar onde deterse.

Verifique nunha orde fixa: execute xl2tpd -D en primeiro plano, vixíe o rexistro para a etapa PPP, lea o enderezo asignado desde ip addr nos dous extremos e despois capture o UDP 1701 para confirmar que os datos flúen despois de levantar a sesión. Se os catro coinciden e o tráfico segue fallando, a culpa é do encamiñamento, do NAT ou da MTU, non do propio L2TP.