L2TP sen IPsec ĉe Linux: xl2tpd, pppd kaj NAT

Nuda L2TP estas PPP en koverto, kaj nenio alia. Ĝi portas viajn kadrojn; ĝi ne ĉifras ilin kaj ne pruvas, kiu sidas ĉe la alia fino, kaj tial preskaŭ ĉiu deplojo glitas IPsec sub ĝin. Honestaj kialoj uzi la nudan version ankoraŭ ekzistas: laboratoria benko, migra paŝo, aŭ ligo jam ene de alia protektita vojo.

Se vi tamen daŭrigos, skribu tiun averton en la dezajnan noton kaj lasu ĝin tie. Tio, kio sekvas, estas la operacia vojo, kiun mi uzas sur gastigantoj de la familio Debian kaj RHEL: kiu dosiero respondecas pri kio, la MTU, kiu malhelpas la klasikan haltiĝon, kaj la plusendaj reguloj, kiuj igas la tunelon inda.

Tri dosieroj dividas la laboron

xl2tpd finas la stiran konekton kaj transdonas ĉiun seancon al PPP-demono, do la agordo disiĝas inter du programoj, kiuj neniam legas la dosierojn de la alia. La aŭskultanto loĝas en /etc/xl2tpd/xl2tpd.conf, ene de sekcio [lns default], kiu nomas la adresaron per ip range, la servilan finon per local ip, kaj la transdonon al PPP per pppoptfile. Ŝaltu require authentication = yes, lasu length bit kaj flow bit aktivaj, kaj elektu aron, kiun nenio alia sur la gastiganto jam uzas.

PPP-politiko apartenas al tiu dosiero, kiun tiu opcio nomas, kutime /etc/ppp/options.xl2tpd: auth, rifuzoj por pap, chap kaj mschap, require-mschap-v2, MTU kaj MRU de 1460, kaj DNS-adreso, kiun la kliento povas atingi post kiam la ligo leviĝis. La akreditaĵoj estas denove tria dosiero, /etc/ppp/chap-secrets, kie la dua kampo devas kongrui kun la nomo de la LNS-sekcio kaj la kvara povas fiksi specifan adreson el la aro.

Kial la tunelo konektiĝas kaj poste haltas

Ethernet-kadro de 1500 bitokoj ne eniras en vojon, kiu jam elspezas bitokojn por siaj propraj kaplinioj. La ekstera IPv4-kaplinio kostas 20, UDP kostas 8, kaj la L2TP-kaplinio proksimume 12, kio lasas 1460 por PPP kaj ĝia utilaŝarĝo. Anonci tiun pli malgrandan nombron en PPP estas tio, kio malhelpas grandajn pakaĵojn esti fragmentitaj aŭ silente forĵetitaj ie meze.

La simptomo estas tunelo, kiu aspektas sana ĝis reala trafiko alvenas: pingoj kaj stir-mesaĝoj trapasas, dosiera kopio haltas, nenio en la protokolo klarigas ĝin. Malaltigu MTU kaj MRU kune ĉe ambaŭ finoj. Agordi nur la klienton kutime ŝanĝas malmolan haltiĝon en intermitan, kiu estas pli malfacile diagnozebla.

Unu pordo portas du konversaciojn

UDP 1701 kuŝas sub ambaŭ duonoj de la protokolo, kaj tiu unu fakto rompas pli da fajroŝirmilaj reguloj ol iu ajn alia parto de la aranĝo. Unue venas peto pri komenco de stira konekto kaj ĝia respondo; la sea peto kaj konfirmo, kiuj sekvas, establas nenion pli ol la identigilan paron. Poste PPP transprenas: liga kontrolo, tiam aŭtentikigo, tiam IP-kontrola protokolo por interkonsenti adresojn. Ĉiu etapo havas sian propran vortaron en la protokolo, kaj neniu anoncas sin kiel L2TP-malsukceso.

Legi kaptaĵon ĝuste en tiu ordo diras al vi, kiu etapo malsukcesis, kaj PPP-aŭtentikiga malsukceso ne ripariĝos per redaktado de xl2tpd. La komuna pordo klarigas alian oftajn malsukceson: regulo, kiu permesas nur la unuajn pakaĵojn de fluo, lasas la seancon establiĝi kaj poste blokas la transdonon. Permesu 1701 por la tuta konversacio, en ambaŭ direktoj.

Igi la tunelon utila: plusendado kaj NAT

Sesio per si mem atingas nur la servilon. La interreta aliro de klientoj bezonas plusendadon, NAT-regulon por la aro sur la suprenligo, kaj DNS, kiun la kliento povas vere demandi post kiam la ligo leviĝis. La aro ankaŭ devas resti for de la LAN-gamo, alie respondoj adresitaj al klientoj estas liveritaj loke anstataŭ puŝitaj reen en la tunelon.

Sur la servilo, ŝaltu plusendadon per sysctl -w net.ipv4.ip_forward=1, traduku la aron per iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE, poste akceptu elirantan tunelan trafikon per FORWARD-regulo por -i ppp0 -o eth0 kaj revenan trafikon per la spegula regulo plus -m state --state RELATED,ESTABLISHED. Daŭrigu tiujn regulojn trans restartigoj, ĉar servilo, kiu revenas sen ili, aspektas ĝuste kiel rompita L2TP-agordo.

Atingi la propran LAN de la servilo estas alia tasko: aldonu revenan vojon por la aro sur la LAN-vojdirektilo, aŭ proxy ARP sur la servilo. Kaŝi klientojn malantaŭ NAT, kiam io ene de la LAN devas adresi ilin rekte, nur planas duan sencimigan seancon por poste.

Kion la nuda stako ne faras, kaj kiel kontroli

Neniu parto de tiu stako ĉifras la PPP-kadrojn, kaj nenio en ĝi aŭtentikigas la kontraŭan finon kiel la servilon, kiun vi efektive elektis. MS-CHAPv2 ja ŝirmas la interŝanĝon de akreditaĵoj kontraŭ aŭskultanto, kiu nur observas, sed atakanto lokita en la vojo ankoraŭ povas interveni en la seancon. La indiĝena kliento de Windows proponas L2TP nur kune kun IPsec, do kalkulu je Linux, enaĵaro de vojdirektiloj kaj triapartaj klientoj kiel viaj kunuloj. Traktu la nudan agordon kiel diagnostikan ŝtupon, neniam kiel la lokon por halti.

Kontrolu en fiksa ordo: rulu xl2tpd -D en la antaŭo, observu la protokolon por la PPP-etapo, legu la asignitan adreson el ip addr ĉe ambaŭ finoj, poste kaptu UDP 1701 por konfirmi, ke datumoj fluas post kiam la seanco leviĝis. Se ĉiuj kvar kongruas kaj trafiko ankoraŭ malsukcesas, la kulpo estas en enrutigado, NAT aŭ MTU, ne en L2TP mem.