L2TP bez IPsec v Linuxe: xl2tpd, pppd a NAT

Holé L2TP je PPP v obálke a nič iné. Prenáša vaše rámce; nešifruje ich a nedokazuje, kto sedí na druhom konci, preto takmer každé nasadenie pod neho podsúva IPsec. Úprimné dôvody prevádzkovať holú verziu stále existujú: laboratórny stôl, krok migrácie alebo prepojenie, ktoré už leží vnútri inej chránenej cesty.

Ak do toho napriek tomu idete, zapíšte toto upozornenie do poznámky k návrhu a nechajte ho tam. Nasleduje prevádzková cesta, ktorú používam na hostoch z rodiny Debian a RHEL: ktorý súbor za čo zodpovedá, MTU, ktoré bráni klasickému zaseknutiu, a pravidlá presmerovania, vďaka ktorým má tunel zmysel.

Tri súbory si delia prácu

xl2tpd ukončuje riadiace spojenie a každú reláciu odovzdáva démonovi PPP, takže konfigurácia sa rozkladá medzi dva programy, ktoré nikdy nečítajú súbory toho druhého. Poslucháč sídli v /etc/xl2tpd/xl2tpd.conf, v sekcii [lns default], ktorá pomenúva fond adries pomocou ip range, stranu servera pomocou local ip a odovzdanie do PPP pomocou pppoptfile. Zapnite require authentication = yes, ponechajte length bit a flow bit zapnuté a vyberte fond, ktorý na hostiteľovi ešte nič iné nepoužíva.

Zásady PPP patria do súboru, ktorý táto voľba uvedie, zvyčajne /etc/ppp/options.xl2tpd: auth, odmietnutia pre pap, chap a mschap, require-mschap-v2, MTU a MRU 1460 a adresa DNS, na ktorú sa klient po nadviazaní spojenia dostane. Prihlasovacie údaje sú opäť tretí súbor, /etc/ppp/chap-secrets, kde druhé pole musí zodpovedať názvu sekcie LNS a štvrté môže pripnúť konkrétnu adresu z fondu.

Prečo sa tunel pripojí a potom zasekne

Rámec Ethernetu s veľkosťou 1500 bajtov sa nezmestí do cesty, ktorá už spotrebúva bajty na vlastné hlavičky. Vonkajšia hlavička IPv4 stojí 20, UDP 8 a hlavička L2TP asi 12, čo necháva 1460 pre PPP a jeho užitočné zaťaženie. Práve inzerovanie tohto menšieho čísla v PPP bráni tomu, aby sa veľké pakety fragmentovali alebo niekde v strede potichu zahodili.

Príznakom je tunel, ktorý vyzerá zdravo, kým nepríde skutočná prevádzka: pingy a riadiace správy prechádzajú, kopírovanie súboru sa zasekne, nič v protokole to nevysvetľuje. Znížte MTU a MRU spoločne na oboch koncoch. Úprava iba klienta zvyčajne premení tvrdé zaseknutie na občasné, ktoré sa diagnostikuje horšie.

Jeden port nesie dva rozhovory

UDP 1701 leží pod oboma polovicami protokolu a tento jediný fakt porušuje viac pravidiel brány firewall než ktorákoľvek iná časť nastavenia. Najprv prichádza žiadosť o začatie riadiaceho spojenia a jej odpoveď; žiadosť o reláciu a potvrdenie, ktoré nasledujú, neustanovujú nič viac než dvojicu identifikátorov. Potom preberá riadenie PPP: riadenie spojenia, potom autentifikácia, potom protokol riadenia IP na dohodnutie adries. Každá fáza má v protokole svoj slovník a žiadna sa neohlási ako zlyhanie L2TP.

Čítanie záznamu presne v tomto poradí vám povie, ktorá fáza zlyhala, a zlyhanie autentifikácie PPP sa opravou xl2tpd nespraví. Zdieľaný port vysvetľuje ďalšiu častú poruchu: pravidlo, ktoré povolí len prvé pakety toku, nechá reláciu vzniknúť a potom zablokuje prenos. Povoľte 1701 pre celý rozhovor, v oboch smeroch.

Ako urobiť tunel užitočným: presmerovanie a NAT

Relácia sama o sebe dosiahne len server. Klientsky prístup na internet potrebuje presmerovanie, pravidlo NAT pre fond na odchádzajúcom spoji a DNS, na ktoré sa klient po nadviazaní spojenia skutočne môže opýtať. Fond tiež musí zostať mimo rozsahu LAN, inak sa odpovede adresované klientom doručujú lokálne, namiesto toho aby sa vtlačili späť do tunela.

Na serveri zapnite presmerovanie pomocou sysctl -w net.ipv4.ip_forward=1, preložte fond pomocou iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE, potom prijmite odchádzajúcu prevádzku tunela pravidlom FORWARD pre -i ppp0 -o eth0 a spiatočnú prevádzku zrkadlovým pravidlom plus -m state --state RELATED,ESTABLISHED. Uchovajte tieto pravidlá cez reštarty, pretože server, ktorý sa vráti bez nich, vyzerá presne ako pokazená konfigurácia L2TP.

Dosiahnuť vlastnú LAN servera je iná úloha: pridajte spätnú trasu pre fond na routeri LAN, alebo proxy ARP na serveri. Skrývať klientov za NAT, keď na nich niečo v LAN musí adresovať priamo, len plánuje druhú ladiacu reláciu na neskôr.

Čo holý zásobník nerobí a ako to overiť

Žiadna časť tohto zásobníka nešifruje rámce PPP a nič v ňom neautentizuje vzdialenú stranu ako server, ktorý ste skutočne zvolili. MS-CHAPv2 síce chráni výmenu prihlasovacích údajov pred poslucháčom, ktorý len prizerá, ale útočník umiestnený na ceste môže do relácie stále zasiahnuť. Natívny klient Windows ponúka L2TP len v spojení s IPsec, preto počítajte s Linuxom, firmvérom routerov a klientmi tretích strán ako protistranami. Berte holú konfiguráciu ako diagnostický medzistupeň, nikdy ako miesto, kde sa zastaviť.

Overujte v pevnom poradí: spustite xl2tpd -D na popredí, sledujte protokol kvôli fáze PPP, prečítajte pridelenú adresu z ip addr na oboch koncoch a potom zachyťte UDP 1701, aby ste potvrdili, že dáta tečú po nadviazaní relácie. Ak všetky štyri sedia a prevádzka napriek tomu zlyháva, chyba je v smerovaní, NAT alebo MTU, nie v samotnom L2TP.