L2TP brez IPsec v Linuxu: xl2tpd, pppd in NAT

Goli L2TP je PPP v ovojnici in nič drugega. Prenaja vaše okvire; ne šifrira jih in ne dokazuje, kdo sedi na drugem koncu, zato skoraj vsaka namestitev pod njega položi IPsec. Iskreni razlogi za golo različico še vedno obstajajo: laboratorijska klop, korak selitve ali povezava, ki že leži znotraj druge zaščitene poti.

Če vseeno nadaljujete, zapišite to opozorilo v opombo o zasnovi in ga pustite tam. Sledi obratovalna pot, ki jo uporabljam na gostiteljih iz družine Debian in RHEL: katera datoteka je za kaj odgovorna, MTU, ki prepreči klasično zataknitev, in pravila posredovanja, zaradi katerih je tunel vreden truda.

Tri datoteke si delijo delo

xl2tpd zaključi krmilno povezavo in vsako sejo preda demonu PPP, zato je konfiguracija razdeljena med dva programa, ki nikoli ne bereta datotek drugega. Poslušalec živi v /etc/xl2tpd/xl2tpd.conf, znotraj razdelka [lns default], ki imenuje nabor naslovov s ip range, stran strežnika s local ip in predajo PPP s pppoptfile. Vklopite require authentication = yes, pustite length bit in flow bit omogočena ter izberite nabor, ki ga nič drugega na gostitelju še ne uporablja.

Politika PPP spada v datoteko, ki jo ta možnost imenuje, običajno /etc/ppp/options.xl2tpd: auth, zavrnitve za pap, chap in mschap, require-mschap-v2, MTU in MRU 1460 ter naslov DNS, ki ga odjemalec doseže po dvigu povezave. Poverilnice so spet tretja datoteka, /etc/ppp/chap-secrets, kjer se mora drugo polje ujemati z imenom razdelka LNS, četrto pa lahko pripne določen naslov iz nabora.

Zakaj se tunel poveže in nato ustavi

Ethernetov okvir velikosti 1500 bajtov se ne prilega v pot, ki že troši bajte za svoje glave. Zunanja glava IPv4 stane 20, UDP 8, glava L2TP pa približno 12, kar pusti 1460 za PPP in njegov tovor. Prav objava te manjše številke v PPP prepreči, da bi se veliki paketi razdrobili ali nekje na sredini tiho izgubili.

Simptom je tunel, ki je videti zdrav, dokler ne pride pravi promet: pingi in krmilna sporočila gredo skozi, kopiranje datoteke se ustavi, nič v dnevniku tega ne pojasni. Znižajte MTU in MRU skupaj na obeh koncih. Nastavljanje samo odjemalca običajno spremeni trdo zataknitev v občasno, ki jo je težje diagnosticirati.

Ena vrata nosijo dva pogovora

UDP 1701 leži pod obema polovicama protokola in to eno dejstvo zlomi več pravil požarnega zidu kot kateri koli drug del nastavitve. Najprej prideta zahteva za začetek krmilne povezave in njen odgovor; zahteva za sejo in potrditev, ki sledita, ne vzpostavita nič več kot par identifikatorjev. Nato prevzame PPP: nadzor povezave, nato overjanje, nato protokol za nadzor IP, da uskladi naslove. Vsaka stopnja ima v dnevniku svoj besednjak in nobena se ne oglasi kot okvara L2TP.

Branje posnetka točno v tem vrstnem redu vam pove, katera stopnja je spodletela, in okvara overjanja PPP se ne popravi z urejanjem xl2tpd. Skupna vrata pojasnijo še eno pogosto okvaro: pravilo, ki dovoli le prve pakete toka, pusti sejo, da se vzpostavi, nato pa blokira prenos. Dovolite 1701 za ves pogovor, v obe smeri.

Kako narediti tunel koristen: posredovanje in NAT

Seja sama doseže le strežnik. Dostop odjemalcev do interneta potrebuje posredovanje, pravilo NAT za nabor na izhodni povezavi in DNS, ki ga odjemalec po dvigu povezave res lahko vpraša. Nabor mora ostati tudi zunaj obsega LAN, sicer se odgovori, naslovljeni na odjemalce, dostavijo lokalno, namesto da bi se potisnili nazaj v tunel.

Na strežniku vklopite posredovanje z sysctl -w net.ipv4.ip_forward=1, prevedite nabor s iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE, nato sprejmite odhodni promet tunela s pravilom FORWARD za -i ppp0 -o eth0 in povratni promet z zrcalnim pravilom plus -m state --state RELATED,ESTABLISHED. Poskrbite, da ta pravila preživijo ponovne zagone, ker je strežnik, ki se vrne brez njih, videti natanko kot pokvarjena konfiguracija L2TP.

Doseči lasten LAN strežnika je druga naloga: dodajte povratno pot za nabor na usmerjevalniku LAN ali proxy ARP na strežniku. Skrivanje odjemalcev za NAT, ko mora nekaj v LAN nanje naslavljati neposredno, samo načrtuje drugo sejo odpravljanja napak za pozneje.

Česa goli sklad ne počne in kako to preveriti

Noben del tega sklada ne šifrira okvirov PPP in nič v njem ne overi oddaljene strani kot strežnika, ki ste ga res izbrali. MS-CHAPv2 res ščiti izmenjavo poverilnic pred poslušalcem, ki samo opazuje, a napadalec na poti lahko še vedno poseže v sejo. Izvorni odjemalec Windows ponuja L2TP le skupaj z IPsec, zato računajte na Linux, strojno programsko opremo usmerjevalnikov in odjemalce tretjih strani kot partnerje. Obravnavajte golo konfiguracijo kot diagnostično stopnico, nikoli kot mesto, kjer se ustavite.

Preverite v ustaljenem vrstnem redu: zaženite xl2tpd -D v ospredju, opazujte dnevnik za stopnjo PPP, preberite dodeljeni naslov iz ip addr na obeh koncih, nato zajemite UDP 1701, da potrdite, da podatki tečejo po dvigu seje. Če se vsi štirje ujemajo in promet še vedno ne deluje, je napaka v usmerjanju, NAT ali MTU in ne v samem L2TP.