L2TP bez IPsec na Linuxu: xl2tpd, pppd a NAT

Holé L2TP je PPP v obálce a nic jiného. Přenáší vaše rámce; nešifruje je a nedokazuje, kdo sedí na druhém konci, a proto téměř každé nasazení pod něj podsouvá IPsec. Poctivé důvody provozovat holou verzi stále existují: laboratorní stůl, krok migrace nebo propojení, které už leží uvnitř jiné chráněné cesty.

Pokud do toho přesto jdete, zapište toto upozornění do poznámky k návrhu a nechte ho tam. Co následuje, je provozní cesta, kterou používám na hostech z rodiny Debian a RHEL: který soubor za co odpovídá, MTU, které brání klasickému zaseknutí, a pravidla přesměrování, díky nimž má tunel smysl.

Tři soubory si dělí práci

xl2tpd ukončuje řídicí spojení a každou relaci předává démonu PPP, takže se konfigurace rozkládá mezi dva programy, které nikdy nečtou soubory toho druhého. Posluchač sídlí v /etc/xl2tpd/xl2tpd.conf, uvnitř sekce [lns default], která pojmenovává fond adres pomocí ip range, stranu serveru pomocí local ip a předání do PPP pomocí pppoptfile. Zapněte require authentication = yes, ponechte length bit a flow bit zapnuté a vyberte fond, který na hostiteli ještě nic jiného nepoužívá.

Zásady PPP patří do souboru, který tato volba uvede, obvykle /etc/ppp/options.xl2tpd: auth, odmítnutí pro pap, chap a mschap, require-mschap-v2, MTU a MRU 1460 a adresa DNS, na kterou se klient po navázání spojení dostane. Přihlašovací údaje jsou opět třetí soubor, /etc/ppp/chap-secrets, kde druhé pole musí odpovídat názvu sekce LNS a čtvrté může připnout konkrétní adresu z fondu.

Proč se tunel připojí a pak zasekne

Rámec Ethernetu o 1500 bajtech se nevejde do cesty, která už spotřebovává bajty na vlastní hlavičky. Vnější hlavička IPv4 stojí 20, UDP 8 a hlavička L2TP asi 12, což nechává 1460 pro PPP a jeho užitečné zatížení. Právě inzerování tohoto menšího čísla v PPP brání tomu, aby se velké pakety fragmentovaly nebo byly někde uprostřed tiše zahozeny.

Příznakem je tunel, který vypadá zdravě, dokud nepřijde skutečný provoz: pingy a řídicí zprávy procházejí, kopírování souboru se zasekne, nic v protokolu to nevysvětluje. Snižte MTU a MRU společně na obou koncích. Úprava pouze klienta obvykle promění tvrdé zaseknutí v občasné, které se diagnostikuje hůř.

Jeden port nese dva rozhovory

UDP 1701 leží pod oběma polovinami protokolu a tento jediný fakt porušuje více pravidel brány firewall než kterákoli jiná část nastavení. Nejprve přichází žádost o zahájení řídicího spojení a její odpověď; žádost o relaci a potvrzení, které následují, neustavují nic víc než dvojici identifikátorů. Poté přebírá řízení PPP: řízení spojení, pak autentizace, pak protokol řízení IP, aby dohodl adresy. Každá fáze má v protokolu svůj slovník a žádná se neohlásí jako selhání L2TP.

Čtení záznamu přesně v tomto pořadí vám řekne, která fáze selhala, a selhání autentizace PPP se opravou xl2tpd nespraví. Sdílený port vysvětluje další častou závadu: pravidlo, které povolí jen první pakety toku, nechá relaci vzniknout a potom zablokuje přenos. Povolte 1701 pro celý rozhovor, v obou směrech.

Jak udělat tunel užitečným: přesměrování a NAT

Relace sama o sobě dosáhne jen serveru. Klientský přístup k internetu potřebuje přesměrování, pravidlo NAT pro fond na odchozím spoji a DNS, na které se klient po navázání spojení skutečně může dotázat. Fond také musí zůstat mimo rozsah LAN, jinak se odpovědi adresované klientům doručují lokálně, místo aby se vtlačily zpět do tunelu.

Na serveru zapněte přesměrování pomocí sysctl -w net.ipv4.ip_forward=1, přeložte fond pomocí iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE, potom přijměte odchozí provoz tunelu pravidlem FORWARD pro -i ppp0 -o eth0 a zpětný provoz zrcadlovým pravidlem plus -m state --state RELATED,ESTABLISHED. Uchovejte tato pravidla přes restartování, protože server, který se vrátí bez nich, vypadá přesně jako rozbitá konfigurace L2TP.

Dosáhnout na vlastní LAN serveru je jiný úkol: přidejte zpětnou trasu pro fond na routeru LAN, nebo proxy ARP na serveru. Skrývání klientů za NAT, když na ně něco v LAN musí adresovat přímo, jen plánuje druhou ladicí relaci na později.

Co holý stoh neumí a jak to ověřit

Žádná část tohoto stohu nešifruje rámce PPP a nic v něm neautentizuje vzdálenou stranu jako server, který jste skutečně zvolili. MS-CHAPv2 sice chrání výměnu přihlašovacích údajů před posluchačem, který jen přihlíží, ale útočník umístěný na cestě může do relace stále zasáhnout. Nativní klient Windows nabízí L2TP jen ve spojení s IPsec, takže počítejte s Linuxem, firmwarem routerů a klienty třetích stran jako protějšky. Berte holou konfiguraci jako diagnostický mezistupeň, nikdy jako místo, kde se zastavit.

Ověřujte v pevném pořadí: spusťte xl2tpd -D na popředí, sledujte protokol kvůli fázi PPP, přečtěte přidělenou adresu z ip addr na obou koncích a potom zachyťte UDP 1701, abyste potvrdili, že data tečou po navázání relace. Pokud všechny čtyři kroky sedí a provoz přesto selhává, chyba je ve směrování, NAT nebo MTU, ne v samotném L2TP.