L2TP bez IPsec-a na Linuxu: xl2tpd, pppd i NAT

Goli L2TP je PPP u omotnici i ništa više. Prenosi vaše okvire; ne šifrira ih i ne dokazuje tko sjedi na drugoj strani, zbog čega gotovo svako postavljanje pod njega podmeće IPsec. Iskreni razlozi za pokretanje gole verzije još postoje: laboratorijska klupa, korak migracije ili veza koja je već unutar drugog zaštićenog puta.

Ako ipak nastavite, upišite to upozorenje u bilješku o dizajnu i ostavite ga tamo. Ono što slijedi je operativni put koji koristim na hostovima iz obitelji Debian i RHEL: koja datoteka čemu služi, MTU koji sprječava klasično zaglavljivanje i pravila prosljeđivanja koja tunel čine vrijednim.

Tri datoteke dijele posao

xl2tpd prekida kontrolnu vezu i predaje svaku sesiju PPP demonu, pa je konfiguracija raspoređena na dva programa koji nikad ne čitaju datoteke onoga drugoga. Slušatelj živi u /etc/xl2tpd/xl2tpd.conf, unutar odjeljka [lns default] koji imenuje raspon adresa s ip range, stranu poslužitelja s local ip i predaju PPP-u s pppoptfile. Uključite require authentication = yes, ostavite length bit i flow bit omogućene i odaberite raspon koji ništa drugo na hostu već ne koristi.

PPP politika pripada datoteci koju ta opcija navede, obično /etc/ppp/options.xl2tpd: auth, odbijanja za pap, chap i mschap, require-mschap-v2, MTU i MRU od 1460 te DNS adresa koju klijent može dosegnuti nakon podizanja veze. Vjerodajnice su opet treća datoteka, /etc/ppp/chap-secrets, gdje drugo polje mora odgovarati imenu LNS odjeljka, a četvrto može prikvačiti određenu adresu iz raspona.

Zašto se tunel spoji i zatim zaglavi

Ethernet okvir od 1500 bajtova ne stane u put koji već troši bajtove na vlastita zaglavlja. Vanjsko IPv4 zaglavlje košta 20, UDP 8, a L2TP zaglavlje oko 12, što ostavlja 1460 za PPP i njegov teret. Upravo objavljivanje te manje brojke u PPP-u sprječava da veliki paketi budu fragmentirani ili tiho odbačeni negdje u sredini.

Simptom je tunel koji izgleda zdrav dok ne stigne stvarni promet: pingovi i kontrolne poruke prolaze, kopiranje datoteke se zaglavi, ništa u zapisniku ne objašnjava zašto. Smanjite MTU i MRU zajedno na oba kraja. Podešavanje samo klijenta obično pretvara tvrdo zaglavljivanje u povremeno, što je gore za dijagnostiku.

Jedan port nosi dva razgovora

UDP 1701 stoji pod obje polovice protokola, a ta jedna činjenica krši više pravila vatrozida nego bilo koji drugi dio postavke. Prvo dolaze zahtjev za početak kontrolne veze i njegov odgovor; zahtjev za sesiju i potvrda koji slijede ne uspostavljaju ništa više od para identifikatora. Zatim preuzima PPP: kontrola veze, pa autentifikacija, pa protokol za kontrolu IP-a da uskladi adrese. Svaka faza ima svoj rječnik u zapisniku i nijedna se ne predstavlja kao kvar L2TP-a.

Čitanje snimke točno tim redoslijedom kaže vam koja je faza podbacila, a kvar PPP autentifikacije neće se popraviti uređivanjem xl2tpd. Zajednički port objašnjava još jedan čest kvar: pravilo koje dopušta samo prve pakete toka pušta sesiju da se uspostavi, a zatim blokira prijenos. Dopustite 1701 za cijeli razgovor, u oba smjera.

Kako tunel učiniti korisnim: prosljeđivanje i NAT

Sesija sama po sebi doseže samo poslužitelj. Klijentski pristup internetu traži prosljeđivanje, NAT pravilo za raspon na uzlaznoj vezi i DNS koji klijent doista može upitati nakon podizanja veze. Raspon također mora ostati izvan LAN opsega, inače se odgovori upućeni klijentima dostavljaju lokalno umjesto da se gurnu natrag u tunel.

Na poslužitelju uključite prosljeđivanje s sysctl -w net.ipv4.ip_forward=1, prevedite raspon s iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE, pa prihvatite odlazni promet tunela FORWARD pravilom za -i ppp0 -o eth0 i povratni promet zrcalnim pravilom plus -m state --state RELATED,ESTABLISHED. Sačuvajte ta pravila kroz ponovna pokretanja, jer poslužitelj koji se vrati bez njih izgleda točno kao pokvarena L2TP konfiguracija.

Dosezanje vlastitog LAN-a poslužitelja drugi je zadatak: dodajte povratnu rutu za raspon na LAN usmjerivaču ili proxy ARP na poslužitelju. Skrivanje klijenata iza NAT-a kada im nešto unutar LAN-a mora izravno adresirati samo zakazuje drugu sesiju otklanjanja pogrešaka za kasnije.

Što goli sklop ne radi i kako to provjeriti

Nijedan dio ovog sklopa ne šifrira PPP okvire i ništa u njemu ne autentificira drugu stranu kao poslužitelj koji ste doista odabrali. MS-CHAPv2 doista štiti razmjenu vjerodajnica od slušača koji samo promatra, ali napadač smješten na putu ipak može utjecati na sesiju. Izvorni Windows klijent nudi L2TP samo u kombinaciji s IPsec-om, pa računajte na Linux, firmware usmjerivača i klijente trećih strana kao svoje partnere. Tretirajte golu konfiguraciju kao dijagnostičku stepenicu, nikada kao mjesto za zaustavljanje.

Provjerite u fiksnom redoslijedu: pokrenite xl2tpd -D u prednjem planu, promatrajte zapisnik za PPP fazu, pročitajte dodijeljenu adresu iz ip addr na oba kraja, zatim snimite UDP 1701 da potvrdite da podaci teku nakon uspostave sesije. Ako se sva četiri poklope, a promet još uvijek ne prolazi, krivnja je u usmjeravanju, NAT-u ili MTU-u, a ne u samom L2TP-u.