L2TP sûnder IPsec op Linux: xl2tpd, pppd en NAT

Keale L2TP is PPP yn in kûvert, en neat oars. It draacht jo frames; it fersiferet se net en it bewissiget net wa't oan 'e oare kant sit, en dêrom skoot hast elke útrôl IPsec derûnder. Earlike redenen om de keale ferzje te draaien besteane noch: in laboratoariumbank, in migraasjestap, of in ferbining dy't al yn in oare beskerme paad leit.

As jo trochgeane, set dy warskôging dan yn 'e ûntwerpnotysje en lit it dêr. Wat folget is it operasjonele paad dat ik brûk op hosts fan 'e Debian- en RHEL-famylje: hokker bestân wêrfoar ferantwurdlik is, de MTU dy't de klassike fêstloper foarkomt, en de trochstjoerregels dy't de tunnel de muoite wurdich meitsje.

Trije bestannen diele it wurk

xl2tpd beëiniget de kontrôleferbining en jout elke sesje oan in PPP-daemon, sadat de konfiguraasje oer twa programma's ferspraat is dy't nea elkoars bestannen lêze. De harker wennet yn /etc/xl2tpd/xl2tpd.conf, yn in [lns default]-diel dat de adrespul mei ip range beneamt, de serverkant mei local ip, en de oerdracht oan PPP mei pppoptfile. Sette require authentication = yes oan, lit length bit en flow bit ynskeakele, en kies in pul dy't neat oars op 'e host al brûkt.

PPP-belied heart yn it bestân dat dy opsje beneamt, meastentiids /etc/ppp/options.xl2tpd: auth, wegerings foar pap, chap en mschap, require-mschap-v2, in MTU en MRU fan 1460, en in DNS-adres dat de kliïnt berikke kin nei't de ferbining omheech is. De oanmeldgegevens binne wer in tredde bestân, /etc/ppp/chap-secrets, wêr't it twadde fjild by de namme fan 'e LNS-diel passe moat en it fjirde fjild in bepaald adres út 'e pul fêstsette kin.

Wêrom't de tunnel ferbynt en dan fêstlûkt

In Ethernet-frame fan 1500 byte past net yn in paad dat al bytes oan syn eigen headers besteget. De bûtenste IPv4-header kostet 20, UDP kostet 8, en de L2TP-header sawat 12, wat 1460 foar PPP en syn lading oerlit. Krekt dat lytsere getal yn PPP oankundigje hâldt grutte pakketten tsjin om fersnippere of stilwei earne yn 'e midden weilitten te wurden.

It symptoom is in tunnel dy't sûn liket oant echte ferkear komt: pings en kontrôleberjochten geane troch, in bestânskopy hinget, neat yn it loch ferklearret it. Ferleegje MTU en MRU tegearre oan beide kanten. Allinnich de kliïnt oanpasse makket fan in hurde fêstloper meastentiids in tuskenskoftige, wat slimmer te diagnostearjen is.

Ien poarte draacht twa petearen

UDP 1701 sit ûnder beide helten fan it protokol, en dat iene feit brekt mear firewallregels as hokker oar diel fan 'e opset ek. Earst komme in start-kontrôle-ferbiningsoanfraach en syn antwurd; de sesje-oanfraach en befêstiging dy't folgje, festigje neat mear as it identifisearjend pear. Dêrnei nimt PPP it oer: linkkontrôle, dan autentikaasje, dan IP-kontrôleprotokol om adressen te besljochtsjen. Elke faze hat syn eigen wurdskat yn it loch, en net ien fan harren kundiget himsels as in L2TP-flater oan.

In opname krekt yn dy folchoarder lêze fertelt jo hokker faze mislearre is, en in PPP-autentikaasjeflater wurdt net reparearre troch xl2tpd te bewurkjen. De dielde poarte ferklearret noch in faak foarkommende flater: in regel dy't allinnich de earste pakketten fan in stream talit, lit de sesje ûntstean en blokket dan de oerdracht. Lit 1701 foar it hiele petear troch, yn beide rjochtingen.

De tunnel nuttich meitsje: trochstjoering en NAT

In sesje berikt op himsels allinnich de server. Tagong fan kliïnten ta it ynternet freget trochstjoering, in NAT-regel foar de pul op 'e uplink, en DNS dêr't de kliïnt nei't de ferbining omheech is echt oan freegje kin. De pul moat ek bûten it LAN-berik bliuwe, oars wurde antwurden rjochte oan kliïnten lokaal ôflevere ynstee fan werom yn 'e tunnel skood.

Op 'e server, skeakelje trochstjoering oan mei sysctl -w net.ipv4.ip_forward=1, fertaal de pul mei iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE, en akseptearje dan útgeand tunnelferkear mei in FORWARD-regel foar -i ppp0 -o eth0 en weromkommend ferkear mei de spegelregel plus -m state --state RELATED,ESTABLISHED. Hâld dy regels oer werstarts hinne, want in server dy't sûnder harren weromkomt liket krekt as in stikken L2TP-konfiguraasje.

De eigen LAN fan 'e server berikke is in oare taak: foegje in weromrûte foar de pul ta op 'e LAN-rûter, of proxy ARP op 'e server. Kliïnten efter NAT ferstopje wylst eat yn 'e LAN har direkt oansprekke moat, plendat gewoan in twadde debugsesje foar letter.

Wat de keale stapel net docht, en hoe't jo it ferifiearje

Gjint diel fan dizze stapel fersiferet de PPP-frames, en neat deryn autentisearret de fiere kant as de server dy't jo echt keazen hawwe. MS-CHAPv2 beskermet de útwikseling fan oanmeldgegevens wol tsjin in harker dy't allinnich sjocht, mar in oanfaller yn it paad kin noch hieltyd yn 'e sesje bemuoie. De lânseigen Windows-kliïnt biedt L2TP allinnich yn kombinaasje mei IPsec, rekkenje dus op Linux, routerfirmware en tredde-partijkliïnten as jo pearen. Behannelje de keale konfiguraasje as in diagnostyske trede, nea as it plak om te stopjen.

Ferifiearje yn in fêste folchoarder: rin xl2tpd -D yn 'e foargrûn, hâld it loch yn 'e gaten foar de PPP-faze, lês it tawiisde adres út ip addr oan beide kanten, en fang dan UDP 1701 om te befêstigjen dat gegevens streame nei't de sesje omheech is. As alle fjouwer oerienkomme en ferkear dochs mislearret, leit de flater yn routing, NAT of MTU en net yn L2TP sels.