L2TP pa IPsec në Linux: xl2tpd, pppd dhe NAT

L2TP i thjeshtë është PPP brenda një zarfi, dhe asgjë tjetër. Mban kornizat tuaja; nuk i kripton dhe nuk vërteton kush rri në skajin tjetër, prandaj pothuajse çdo vendosje vendos IPsec poshtë tij. Arsyet e sinqerta për të përdorur versionin e zhveshur ekzistojnë ende: një stol laboratori, një hap migrimi ose një lidhje që ndodhet tashmë brenda një rruge tjetër të mbrojtur.

Nëse vazhdoni gjithsesi, shkruajeni atë paralajmërim në shënimin e projektimit dhe lëreni atje. Ajo që vijon është rruga operative që përdor në hostet e familjes Debian dhe RHEL: cili skedar është përgjegjës për çfarë, MTU-ja që parandalon ngecjen klasike dhe rregullat e përcjelljes që e bëjnë tunelin të vlefshëm.

Tre skedarë ndajnë punën

xl2tpd përfundon lidhjen e kontrollit dhe i dorëzon çdo sesion një demoni PPP, kështu që konfigurimi ndahet midis dy programeve që nuk lexojnë kurrë skedarët e njëri-tjetrit. Dëgjuesi jeton në /etc/xl2tpd/xl2tpd.conf, brenda një seksioni [lns default] që emërton grupin e adresave me ip range, anën e serverit me local ip dhe dorëzimin te PPP me pppoptfile. Aktivizoni require authentication = yes, lini length bit dhe flow bit të aktivizuara dhe zgjidhni një grup që asgjë tjetër në host nuk e përdor tashmë.

Politika e PPP i takon skedarit që emërton ai opsion, zakonisht /etc/ppp/options.xl2tpd: auth, refuzime për pap, chap dhe mschap, require-mschap-v2, një MTU dhe MRU prej 1460 dhe një adresë DNS të cilën klienti mund ta arrijë pasi lidhja ngrihet. Kredencialet janë përsëri një skedar i tretë, /etc/ppp/chap-secrets, ku fusha e dytë duhet të përputhet me emrin e seksionit LNS dhe fusha e katërt mund të fiksojë një adresë specifike nga grupi.

Pse tuneli lidhet dhe pastaj ngec

Një kornizë Ethernet prej 1500 bajtësh nuk futet brenda një rruge që tashmë shpenzon bajtë për titujt e vet. Titulli i jashtëm IPv4 kushton 20, UDP kushton 8 dhe titulli L2TP rreth 12, gjë që lë 1460 për PPP dhe ngarkesën e tij. Pikërisht shpallja e atij numri më të vogël në PPP është ajo që i mban paketat e mëdha nga fragmentimi ose nga hedhja në heshtje diku në mes.

Simptoma është një tunel që duket i shëndetshëm derisa të vijë trafik i vërtetë: ping-et dhe mesazhet e kontrollit kalojnë, një kopjim skedari ngec, asgjë në regjistër nuk e shpjegon. Ulni MTU-në dhe MRU-në së bashku në të dy skajet. Rregullimi vetëm i klientit zakonisht e shndërron një ngecje të fortë në një të herëpashershme, e cila diagnostikohet më keq.

Një port mbart dy biseda

UDP 1701 qëndron nën të dyja gjysmat e protokollit, dhe ky fakt i vetëm thyen më shumë rregulla firewalls se çdo pjesë tjetër e konfigurimit. Fillimisht vijnë një kërkesë për fillimin e lidhjes së kontrollit dhe përgjigjja e saj; kërkesa e sesionit dhe konfirmimi që vijojnë nuk vendosin asgjë më shumë se çifti i identifikuesve. Pastaj merr drejtimin PPP: kontrolli i lidhjes, pastaj vërtetimi, pastaj protokolli i kontrollit të IP për të dakorduar adresat. Çdo fazë ka fjalorin e vet në regjistër dhe asnjëra nuk shpallet si dështim i L2TP.

Leximi i një kapjeje pikërisht në atë rend ju thotë cila fazë dështoi, dhe një dështim vërtetimi PPP nuk rregullohet duke redaktuar xl2tpd. Porta e përbashkët shpjegon një dështim tjetër të zakonshëm: një rregull që lejon vetëm paketat e para të një rrjedhe e lë sesionin të vendoset dhe pastaj bllokon transferimin. Lejoni 1701 për të gjithë bisedën, në të dy drejtimet.

Ta bësh tunelin të dobishëm: përcjellje dhe NAT

Një sesion më vete arrin vetëm serverin. Aksesi në internet i klientëve kërkon përcjellje, një rregull NAT për grupin në lidhjen lart dhe DNS që klienti mund ta pyesë vërtet pasi lidhja ngrihet. Grupi gjithashtu duhet të mbetet jashtë intervalit të LAN-it, përndryshe përgjigjet e drejtuara klientëve dorëzohen lokalisht në vend që të shtyhen përsëri në tunel.

Në server, aktivizoni përcjelljen me sysctl -w net.ipv4.ip_forward=1, përktheni grupin me iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE, pastaj pranoni trafikun dalës të tunelit me një rregull FORWARD për -i ppp0 -o eth0 dhe trafikun e kthimit me rregullin pasqyrë plus -m state --state RELATED,ESTABLISHED. Bëjini këto rregulla të qëndrueshme mes rinisjeve, sepse një server që kthehet pa to duket pikërisht si një konfigurim L2TP i prishur.

Arritja e LAN-it të vetë serverit është detyrë tjetër: shtoni një rrugë kthimi për grupin në ruterin e LAN-it, ose proxy ARP në server. Fshehja e klientëve pas NAT kur diçka brenda LAN-it duhet t'u drejtohet atyre drejtpërdrejt thjesht planifikon një sesion të dytë korrigjimi për më vonë.

Çfarë nuk bën stivi i zhveshur dhe si ta verifikoni

Asnjë pjesë e këtij stiv nuk i kripton kornizat PPP, dhe asgjë në të nuk e vërteton skajin e largët si serverin që zgjodhët vërtet. MS-CHAPv2 e mbron shkëmbimin e kredencialeve nga një dëgjues që vetëm vëzhgon, por një sulmues i vendosur në rrugë prapë mund të ndërhyjë në sesion. Klienti amtare i Windows ofron L2TP vetëm bashkë me IPsec, prandaj llogaritni Linux, firmware të ruterave dhe klientë të palëve të treta si kundërshtarët tuaj. Trajtoni konfigurimin e zhveshur si një shkallë diagnostike, kurrë si vendin ku ndalohet.

Verifikoni në një rend fiks: ekzekutoni xl2tpd -D në plan të parë, vëzhgoni regjistrin për fazën PPP, lexoni adresën e caktuar nga ip addr në të dy skajet, pastaj kapni UDP 1701 për të konfirmuar se të dhënat rrjedhin pasi sesioni ngrihet. Nëse të katërtat përputhen dhe trafiku prapë dështon, faji është në rrugëzim, NAT ose MTU, jo në vetë L2TP.