L2TP be IPsec sistemoje Linux: xl2tpd, pppd ir NAT

Plynasis L2TP yra PPP voke ir nieko daugiau. Jis perduoda jūsų kadrus; jo nešifruoja ir neįrodo, kas sėdi kitame gale, todėl beveik kiekvienas diegimas po juo pakiša IPsec. Sąžiningų priežasčių naudoti pliką versiją vis dar yra: laboratorinis stendas, migracijos žingsnis arba ryšys, kuris jau yra kito apsaugoto kelio viduje.

Jei vis tiek tęsite, įrašykite tą įspėjimą į dizaino pastabą ir palikite jį ten. Toliau pateikiamas operacinis kelias, kurį naudoju Debian ir RHEL šeimos hostuose: kuris failas už ką atsakingas, MTU, kuris užkerta kelią klasikiniam sustojimui, ir persiuntimo taisyklės, kurios daro tunelį vertą.

Trys failai dalijasi darbu

xl2tpd užbaigia valdymo ryšį ir perduoda kiekvieną sesiją PPP demonui, todėl konfigūracija išskaidyta dviem programoms, kurios niekada neskaito viena kitos failų. Klausytojas gyvena /etc/xl2tpd/xl2tpd.conf, [lns default] skiltyje, kuri adresų telkinį įvardija su ip range, serverio galą su local ip, o perdavimą PPP su pppoptfile. Įjunkite require authentication = yes, palikite length bit ir flow bit įjungtus ir pasirinkite telkinį, kurio dar niekas kitas hoste nenaudoja.

PPP politika priklauso tam failui, kurį nurodo ta parinktis, paprastai /etc/ppp/options.xl2tpd: auth, atmetimai pap, chap ir mschap, require-mschap-v2, 1460 MTU ir MRU bei DNS adresas, kurį klientas pasieks po to, kai ryšys pakils. Prisijungimo duomenys vėl trečias failas, /etc/ppp/chap-secrets, kur antrasis laukas turi atitikti LNS skilties pavadinimą, o ketvirtasis gali prisegti konkretų adresą iš telkinio.

Kodėl tunelis prisijungia ir tada užstringa

1500 baitų Ethernet kadras netelpa į kelią, kuris jau išleidžia baitus savo antraštėms. Išorinė IPv4 antraštė kainuoja 20, UDP - 8, o L2TP antraštė - apie 12, todėl PPP ir jo kroviniui lieka 1460. Būtent šio mažesnio skaičiaus paskelbimas PPP neleidžia dideliems paketams suskaidyti ar tyliai numesti kažkur viduryje.

Simptomas yra tunelis, kuris atrodo sveikas, kol neateina tikras srautas: pingai ir valdymo pranešimai praeina, failo kopijavimas užstringa, niekas žurnale to nepaaiškina. Sumažinkite MTU ir MRU kartu abiejuose galuose. Sureguliavus tik klientą, kietas užstrigimas dažniausiai virsta periodišku, o tai diagnozuoti blogiau.

Vienas prievadas neša du pokalbius

UDP 1701 yra po abiem protokolo pusėmis, ir šis vienas faktas sulaužo daugiau ugniasienės taisyklių nei bet kuri kita sąrankos dalis. Pirmiausia ateina valdymo ryšio pradžios užklausa ir jos atsakymas; po jų einanti sesijos užklausa ir patvirtinimas nesukuria nieko daugiau nei identifikatorių pora. Tada perima PPP: ryšio valdymas, paskui autentifikavimas, paskui IP valdymo protokolas adresams suderinti. Kiekvienas etapas žurnale turi savo žodyną, ir nė vienas jo nepraneša kaip L2TP gedimo.

Skaitymas įrašo tiksliai ta tvarka pasako, kuris etapas nepavyko, o PPP autentifikavimo gedimas nebus ištaisytas redaguojant xl2tpd. Bendras prievadas paaiškina kitą dažną gedimą: taisyklė, leidžianti tik pirmuosius srauto paketus, leidžia sesijai susikurti ir tada blokuoja perdavimą. Leiskite 1701 visam pokalbiui, abiejose kryptyse.

Padarykite tunelį naudingu: persiuntimas ir NAT

Sesija pati savaime pasiekia tik serverį. Klientų interneto prieigai reikia persiuntimo, NAT taisyklės telkiniui išorinėje jungtyje ir DNS, kurio klientas tikrai galėtų paklausti po to, kai ryšys pakyla. Telkinys taip pat turi likti už LAN diapazono ribų, kitaip klientams adresuoti atsakymai pristatomi vietoje, o ne įstumiami atgal į tunelį.

Serveryje įjunkite persiuntimą su sysctl -w net.ipv4.ip_forward=1, išverskite telkinį su iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE, tada priimkite išeinantį tunelio srautą FORWARD taisykle -i ppp0 -o eth0 atveju, o grįžtantį srautą su veidrodine taisykle ir -m state --state RELATED,ESTABLISHED. Padarykite šias taisykles patvarias tarp perkrovimų, nes serveris, kuris grįžta be jų, atrodo lygiai kaip sugedusi L2TP konfigūracija.

Pasiekti paties serverio LAN yra kita užduotis: pridėkite grįžimo maršrutą telkiniui LAN maršrutizatoriuje arba proxy ARP serveryje. Slėpti klientus už NAT, kai kažkas LAN viduje turi kreiptis į juos tiesiogiai, tik suplanuoja antrą derinimo sesiją vėliau.

Ko plikas kamienas nedaro ir kaip tai patikrinti

Nė viena šio kamino dalis nešifruoja PPP kadrų, ir niekas jame neautentifikuoja tolimojo galo kaip serverio, kurį iš tikrųjų pasirinkote. MS-CHAPv2 tikrai apsaugo prisijungimo duomenų mainus nuo stebinčio klausytojo, tačiau kelyje esantis užpuolikas vis tiek gali trukdyti sesijai. Natyvusis Windows klientas siūlo L2TP tik kartu su IPsec, todėl skaičiuokite Linux, maršrutizatorių programinę aparatinę įrangą ir trečiųjų šalių klientus kaip savo partnerius. Traktuokite pliką konfigūraciją kaip diagnostinį laiptelį, niekada kaip vietą sustoti.

Tikrinkite fiksuota tvarka: paleiskite xl2tpd -D priekiniame plane, stebėkite žurnalą dėl PPP etapo, perskaitykite priskirtą adresą iš ip addr abiejuose galuose, tada užfiksuokite UDP 1701, kad patvirtintumėte, jog duomenys teka po to, kai sesija pakilo. Jei visi keturi sutampa, o srautas vis tiek nepraeina, kaltė yra maršrutizavime, NAT arba MTU, o ne pačiame L2TP.