L2TP sonder IPsec op Linux: xl2tpd, pppd en NAT

Kaal L2TP is PPP in 'n koevert, en niks anders nie. Dit dra jou rame; dit versleutel hulle nie en dit bewys nie wie aan die ander kant sit nie, en dit is die rede waarom byna elke ontplooiing IPsec daaronder skuif. Eerlike redes om die kaal weergawe te gebruik bestaan steeds: 'n laboratoriumbank, 'n migrasiestap, of 'n skakel wat reeds binne 'n ander beskermde pad lê.

As jy aangaan, sit daardie waarskuwing in die ontwerpnota en hou dit daar. Wat volg, is die operasionele pad wat ek op Debian- en RHEL-familie-gashere gebruik: watter lêer waarvoor verantwoordelik is, die MTU wat die klassieke vasdraai verhoed, en die aanstuurreëls wat die tonnel die moeite werd maak.

Drie lêers verdeel die werk

xl2tpd beëindig die beheerverbinding en oorhandig elke sessie aan 'n PPP-daemon, so die konfigurasie is oor twee programme versprei wat nooit mekaar se lêers lees nie. Die luisteraar woon in /etc/xl2tpd/xl2tpd.conf, binne 'n [lns default]-afdeling wat die adrespoel met ip range benoem, die bedienerkant met local ip, en die oorhandiging aan PPP met pppoptfile. Skakel require authentication = yes aan, laat length bit en flow bit geaktiveer, en kies 'n poel wat niks anders op die gasheer al gebruik nie.

PPP-beleid hoort in watter lêer daardie opsie ook al noem, gewoonlik /etc/ppp/options.xl2tpd: auth, weierings vir pap, chap en mschap, require-mschap-v2, 'n MTU en MRU van 1460, en 'n DNS-adres wat die kliënt kan bereik nadat die skakel op is. Geloofsbriewe is weer 'n derde lêer, /etc/ppp/chap-secrets, waar die tweede veld by die LNS-afdelingnaam moet pas en die vierde veld 'n spesifieke adres uit die poel kan vaspen.

Waarom die tonnel koppel en dan vasdraai

'n 1500-greep Ethernet-raam pas nie binne 'n pad wat reeds grepe aan sy eie koptekste spandeer nie. Die buitenste IPv4-koptekst kos 20, UDP kos 8, en die L2TP-koptekst omtrent 12, wat 1460 vir PPP en sy vrag laat. Om daardie kleiner syfer in PPP te adverteer, is wat keer dat groot pakkette gefragmenteer of stilweg iewers in die middel laat val word.

Die simptoom is 'n tonnel wat gesond lyk totdat werklike verkeer opdaag: pings en beheerboodskappe slaag, 'n lêerkopie hang, niks in die log verduidelik dit nie. Verlaag MTU en MRU saam aan beide kante. Om net die kliënt aan te pas, verander gewoonlik 'n harde vasdraai in 'n afwisselende een, wat moeiliker is om te diagnoseer.

Een poort dra twee gesprekke

UDP 1701 sit onder beide helftes van die protokol, en daardie enkele feit breek meer firewallreëls as enige ander deel van die opstelling. 'n Begin-beheerverbindingversoek en sy antwoord kom eerste; die sessieversoek en -bevestiging wat volg, vestig niks meer as die identifiseerderpaar nie. PPP neem daarna oor, met skakelbeheer, dan verifikasie, dan IP-beheerprotokol om adresse te besleg. Elke stadium het sy eie woordeskat in die log, en nie een daarvan kondig homself as 'n L2TP-fout aan nie.

Om 'n opname in presies daardie volgorde te lees, sê vir jou watter stadium gefaal het, en 'n PPP-verifikasiefout sal nie reggemaak word deur xl2tpd te redigeer nie. Die gedeelde poort verduidelik nog 'n algemene fout: 'n reël wat net die eerste pakkette van 'n vloei toelaat, laat die sessie vestig en blokkeer dan die oordrag. Laat 1701 vir die hele gesprek toe, in beide rigtings.

Maak die tonnel nuttig: aanstuur en NAT

'n Sessie bereik op sigself net die bediener. Kliëntinternettoegang het aanstuur, 'n NAT-reël vir die poel op die uplink, en DNS nodig wat die kliënt werklik kan bevra nadat die skakel op is. Die poel moet ook weg van die LAN-reeks bly, anders word antwoorde wat aan kliënte gerig is, plaaslik afgelewer in plaas daarvan om terug in die tonnel gestoot te word.

Op die bediener, aktiveer aanstuur met sysctl -w net.ipv4.ip_forward=1, vertaal die poel met iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE, en aanvaar dan uitgaande tonnelverkeer met 'n FORWARD-reël vir -i ppp0 -o eth0 en terugkerende verkeer met die spieëlreël plus -m state --state RELATED,ESTABLISHED. Hou daardie reëls oor herlaai heen, want 'n bediener wat sonder hulle terugkom, lyk presies soos 'n stukkende L2TP-konfigurasie.

Om die bediener se eie LAN te bereik, is 'n ander taak: voeg 'n terugroete vir die poel op die LAN-roeteerder by, of proxy-ARP op die bediener. Om kliënte agter NAT weg te steek wanneer iets binne die LAN hulle direk moet aanspreek, skeduleer net 'n tweede ontfoutingsessie vir later.

Wat die kaal stapel nie doen nie, en hoe om te verifieer

Geen deel van hierdie stapel versleutel die PPP-rame nie, en niks daarin verifieer die verre kant as die bediener wat jy werklik gekies het nie. MS-CHAPv2 skerm wel die geloofsbriefwisseling af van 'n luisteraar wat net kyk, maar 'n aanvaller wat in die pad geplaas is, kan steeds met die sessie inmeng. Die Windows-inheemse kliënt bied L2TP net in kombinasie met IPsec, so begroot vir Linux, roeteerderfirmware en derdeparty-kliënte as jou eweknieë. Behandel die kaal konfigurasie as 'n diagnostiese springplank, nooit as die plek om te stop nie.

Verifieer in 'n vaste volgorde: voer xl2tpd -D in die voorgrond uit, kyk na die joernaal vir die PPP-stadium, lees die toegewysde adres van ip addr aan beide kante, en vang dan UDP 1701 om te bevestig dat data vloei nadat die sessie op is. As al vier ooreenstem en verkeer steeds faal, is die fout roetering, NAT of MTU eerder as L2TP self.