L2TP zonder IPsec op Linux: xl2tpd, pppd en NAT

Kaal L2TP is PPP in een envelop, en niets anders. Het draagt uw frames; het versleutelt ze niet en het bewijst niet wie er aan de andere kant zit, waardoor bijna elke uitrol IPsec eronder schuift. Eerlijke redenen om de kale versie te draaien bestaan nog steeds: een labbank, een migratiestap of een verbinding die al binnen een ander beschermd pad ligt.

Als u toch doorgaat, zet die waarschuwing dan in de ontwerpnotitie en laat hem daar staan. Wat volgt is het operationele pad dat ik op hosts uit de Debian- en RHEL-familie gebruik: welk bestand waarvoor verantwoordelijk is, de MTU die de klassieke stilstand voorkomt, en de doorstuurregels die de tunnel de moeite waard maken.

Drie bestanden delen het werk

xl2tpd beëindigt de controleverbinding en draagt elke sessie over aan een PPP-daemon, dus de configuratie is verdeeld over twee programma's die nooit elkaars bestanden lezen. De luisteraar woont in /etc/xl2tpd/xl2tpd.conf, binnen een sectie [lns default] die de adrespool met ip range benoemt, de serverkant met local ip en de overdracht aan PPP met pppoptfile. Schakel require authentication = yes in, laat length bit en flow bit aan staan, en kies een pool die niets anders op de host al gebruikt.

PPP-beleid hoort in het bestand dat die optie noemt, meestal /etc/ppp/options.xl2tpd: auth, weigeringen voor pap, chap en mschap, require-mschap-v2, een MTU en MRU van 1460, en een DNS-adres dat de client kan bereiken nadat de verbinding omhoog is. De inloggegevens staan weer in een derde bestand, /etc/ppp/chap-secrets, waar het tweede veld bij de naam van de LNS-sectie moet passen en het vierde veld een bepaald adres uit de pool kan vastzetten.

Waarom de tunnel verbindt en dan blijft hangen

Een Ethernet-frame van 1500 byte past niet in een pad dat al bytes uitgeeft aan zijn eigen headers. De buitenste IPv4-header kost 20, UDP kost 8 en de L2TP-header ongeveer 12, wat 1460 overlaat voor PPP en zijn lading. Juist dat kleinere getal in PPP aankondigen houdt grote pakketten ervan af om te worden gefragmenteerd of ergens in het midden stil te worden weggegooid.

Het symptoom is een tunnel die gezond lijkt totdat er echt verkeer komt: pings en controleboodschappen komen door, een bestandskopie blijft hangen, niets in het log verklaart het. Verlaag MTU en MRU samen aan beide kanten. Alleen de client aanpassen verandert een harde stilstand meestal in een periodieke, die slechter te diagnosticeren is.

Eén poort draagt twee gesprekken

UDP 1701 ligt onder beide helften van het protocol, en dat ene feit breekt meer firewallregels dan welk ander deel van de opzet dan ook. Eerst komen een verzoek om de controleverbinding te starten en het antwoord daarop; het sessieverzoek en de bevestiging daarna vestigen niets meer dan het paar identificaties. Daarna neemt PPP over: linkbeheer, dan authenticatie, dan het IP-controleprotocol om adressen af te stemmen. Elke fase heeft zijn eigen vocabulaire in het log, en geen ervan kondigt zichzelf aan als een L2TP-storing.

Een opname precies in die volgorde lezen vertelt u welke fase is mislukt, en een PPP-authenticatiefout wordt niet gerepareerd door xl2tpd te bewerken. De gedeelde poort verklaart nog een veelvoorkomende fout: een regel die alleen de eerste pakketten van een stroom toestaat, laat de sessie tot stand komen en blokkeert daarna de overdracht. Sta 1701 toe voor het hele gesprek, in beide richtingen.

De tunnel nuttig maken: doorsturen en NAT

Een sessie bereikt op zichzelf alleen de server. Clienttoegang tot internet vraagt om doorsturen, een NAT-regel voor de pool op de uplink, en DNS die de client echt kan bevragen nadat de verbinding omhoog is. De pool moet ook buiten het LAN-bereik blijven, anders worden antwoorden aan de clients lokaal afgeleverd in plaats van terug de tunnel in geduwd.

Op de server schakelt u doorsturen in met sysctl -w net.ipv4.ip_forward=1, vertaalt u de pool met iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE, en accepteert u daarna uitgaand tunnelverkeer met een FORWARD-regel voor -i ppp0 -o eth0 en terugkerend verkeer met de spiegelregel plus -m state --state RELATED,ESTABLISHED. Maak die regels blijvend over herstarts heen, want een server die zonder hen terugkomt ziet er precies uit als een kapotte L2TP-configuratie.

De eigen LAN van de server bereiken is een andere taak: voeg een retourroute voor de pool toe op de LAN-router, of proxy ARP op de server. Clients achter NAT verbergen terwijl iets binnen de LAN hen rechtstreeks moet aanspreken, plant alleen een tweede debugsessie voor later.

Wat de kale stapel niet doet, en hoe u het controleert

Geen deel van deze stapel versleutelt de PPP-frames, en niets erin authenticeert de andere kant als de server die u werkelijk hebt gekozen. MS-CHAPv2 beschermt de uitwisseling van inloggegevens wel tegen een luisteraar die alleen meekijkt, maar een aanvaller in het pad kan de sessie nog steeds verstoren. De native Windows-client biedt L2TP alleen in combinatie met IPsec, dus reken op Linux, routerfirmware en clients van derden als uw tegenpartijen. Behandel de kale configuratie als een diagnostische tussenstap, nooit als de plek om te stoppen.

Controleer in een vaste volgorde: start xl2tpd -D op de voorgrond, houd het journaal in de gaten voor de PPP-fase, lees het toegewezen adres uit ip addr aan beide kanten, en leg dan UDP 1701 vast om te bevestigen dat gegevens stromen nadat de sessie omhoog is. Als alle vier kloppen en het verkeer toch faalt, ligt de fout in routing, NAT of MTU en niet in L2TP zelf.