L2TP sense IPsec a Linux: xl2tpd, pppd i NAT

El L2TP pur és PPP dins d'un sobre, i res més. Porta les vostres trames; no les xifra ni demostra qui seu a l'altre extrem, i per això gairebé cada desplegament hi posa IPsec a sota. Encara hi ha motius honestos per fer servir la versió nua: un banc de laboratori, un pas de migració o un enllaç que ja és dins d'un altre camí protegit.

Si tireu endavant, poseu aquest advertiment a la nota de disseny i deixeu-lo allà. El que segueix és el camí operatiu que faig servir en amfitrions de la família Debian i RHEL: quin fitxer s'encarrega de què, l'MTU que evita l'encallament clàssic i les regles de reenviament que fan que el túnel valgui la pena.

Tres fitxers es reparteixen la feina

xl2tpd acaba la connexió de control i lliura cada sessió a un dimoni PPP, de manera que la configuració es reparteix entre dos programes que mai no llegeixen els fitxers de l'altre. L'oient viu a /etc/xl2tpd/xl2tpd.conf, dins d'una secció [lns default] que anomena el conjunt d'adreces amb ip range, l'extrem del servidor amb local ip i el lliurament a PPP amb pppoptfile. Activeu require authentication = yes, deixeu length bit i flow bit habilitats i trieu un conjunt que cap altra cosa de l'amfitrió no faci servir.

La política PPP pertany al fitxer que nomena aquesta opció, normalment /etc/ppp/options.xl2tpd: auth, refusos per a pap, chap i mschap, require-mschap-v2, un MTU i un MRU de 1460 i una adreça DNS que el client pugui assolir després d'aixecar l'enllaç. Les credencials són un tercer fitxer, /etc/ppp/chap-secrets, on el segon camp ha de coincidir amb el nom de la secció LNS i el quart pot fixar una adreça concreta del conjunt.

Per què el túnel es connecta i després s'encalla

Una trama Ethernet de 1500 bytes no cap dins d'un camí que ja gasta bytes en les seves pròpies capçaleres. La capçalera IPv4 exterior costa 20, UDP costa 8 i la de L2TP uns 12, cosa que deixa 1460 per a PPP i la seva càrrega. Anunciar aquesta xifra més petita a PPP és el que evita que els paquets grans es fragmentin o es descartin silenciosament enmig del camí.

El símptoma és un túnel que sembla sa fins que arriba trànsit real: els pings i els missatges de control passen, una còpia de fitxer s'encalla i res al registre ho explica. Baixeu l'MTU i l'MRU alhora als dos extrems. Ajustar només el client sol convertir un encallament dur en un d'intermitent, que és pitjor de diagnosticar.

Un port porta dues converses

L'UDP 1701 és sota les dues meitats del protocol, i aquest sol fet trenca més regles de tallafocs que qualsevol altra part de la configuració. Primer arriben una petició d'inici de connexió de control i la seva resposta; la petició de sessió i la confirmació que segueixen no estableixen res més que el parell d'identificadors. Després pren el relleu PPP, amb control d'enllaç, després autenticació i després protocol de control d'IP per acordar les adreces. Cada etapa té el seu vocabulari al registre, i cap d'elles no s'anuncia com una fallada d'L2TP.

Llegir una captura exactament en aquest ordre us diu quina etapa ha fallat, i una fallada d'autenticació PPP no es repararà editant xl2tpd. El port compartit explica una altra fallada habitual: una regla que només permet els primers paquets d'un flux deixa que la sessió s'estableixi i després bloqueja la transferència. Permeteu el 1701 per a tota la conversa, en tots dos sentits.

Fer útil el túnel: reenviament i NAT

Una sessió per si sola només arriba al servidor. L'accés a internet dels clients necessita reenviament, una regla NAT per al conjunt a l'enllaç ascendent i un DNS que el client pugui consultar de debò després d'aixecar l'enllaç. El conjunt també ha de quedar fora del rang de la LAN, o les respostes adreçades als clients es lliuren localment en lloc d'empènyer-se de tornada al túnel.

Al servidor, activeu el reenviament amb sysctl -w net.ipv4.ip_forward=1, traduïu el conjunt amb iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE, i després accepteu el trànsit de sortida del túnel amb una regla FORWARD per a -i ppp0 -o eth0 i el trànsit de retorn amb la regla mirall més -m state --state RELATED,ESTABLISHED. Feu persistents aquestes regles entre reinicis, perquè un servidor que torna sense elles sembla exactament una configuració L2TP espatllada.

Arribar a la LAN pròpia del servidor és una altra tasca: afegiu una ruta de retorn per al conjunt al router de la LAN, o proxy ARP al servidor. Amagar els clients darrere de NAT quan alguna cosa dins de la LAN els ha d'adreçar directament només programa una segona sessió de depuració per a més endavant.

Què no fa la pila nua i com verificar-ho

Cap part d'aquesta pila no xifra les trames PPP, i res no autentica l'extrem remot com el servidor que heu triat de debò. MS-CHAPv2 sí que protegeix l'intercanvi de credencials d'un oient que només mira, però un atacant situat al camí encara pot interferir en la sessió. El client natiu de Windows ofereix L2TP només en combinació amb IPsec, així que compteu amb Linux, el firmware dels routers i clients de tercers com a parells. Tracteu la configuració nua com un graó de diagnòstic, mai com el lloc on aturar-se.

Verifiqueu en un ordre fix: executeu xl2tpd -D en primer pla, observeu el registre per a l'etapa PPP, llegiu l'adreça assignada des de ip addr als dos extrems i després captureu l'UDP 1701 per confirmar que les dades flueixen després d'aixecar la sessió. Si les quatre coses coincideixen i el trànsit encara falla, la culpa és d'encaminament, NAT o MTU, no del mateix L2TP.