L2TP fără IPsec pe Linux: xl2tpd, pppd și NAT

Simplul L2TP este PPP într-un plic, și nimic altceva. Transportă cadrele tale; nu le criptează și nu dovedește cine stă la celălalt capăt, motiv pentru care aproape fiecare implementare bagă IPsec dedesubt. Motive oneste pentru varianta goală încă există: un stand de laborator, un pas de migrare sau un link care se află deja într-o altă cale protejată.

Dacă totuși mergi înainte, scrie acel avertisment în nota de proiectare și lasă-l acolo. Ce urmează este calea operațională pe care o folosesc pe gazde din familia Debian și RHEL: ce fișier răspunde de ce, MTU-ul care împiedică blocajul clasic și regulile de redirecționare care fac tunelul util.

Trei fișiere împart munca

xl2tpd încheie conexiunea de control și predă fiecare sesiune unui demon PPP, așa că configurația este împărțită între două programe care nu citesc niciodată fișierele celuilalt. Ascultătorul locuiește în /etc/xl2tpd/xl2tpd.conf, într-o secțiune [lns default] care numește bazinul de adrese cu ip range, capătul serverului cu local ip și predarea către PPP cu pppoptfile. Activează require authentication = yes, lasă length bit și flow bit activate și alege un bazin pe care nimic altceva de pe gazdă nu îl folosește deja.

Politica PPP aparține fișierului pe care îl numește acea opțiune, de obicei /etc/ppp/options.xl2tpd: auth, refuzuri pentru pap, chap și mschap, require-mschap-v2, un MTU și un MRU de 1460 și o adresă DNS la care clientul poate ajunge după ce linkul urcă. Credențialele sunt din nou un al treilea fișier, /etc/ppp/chap-secrets, unde al doilea câmp trebuie să corespundă numelui secțiunii LNS, iar al patrulea poate fixa o adresă anume din bazin.

De ce tunelul se conectează și apoi se blochează

Un cadru Ethernet de 1500 de octeți nu încape într-o cale care deja cheltuie octeți pe propriile antete. Antetul IPv4 exterior costă 20, UDP costă 8, iar antetul L2TP aproximativ 12, ceea ce lasă 1460 pentru PPP și încărcătura lui. Tocmai anunțarea acelui număr mai mic în PPP împiedică pachetele mari să fie fragmentate sau aruncate în tăcere undeva la mijloc.

Simptomul este un tunel care pare sănătos până când sosește trafic real: pingurile și mesajele de control trec, copierea unui fișier se blochează, nimic din jurnal nu explică asta. Scade MTU și MRU împreună la ambele capete. Ajustarea doar a clientului transformă de obicei un blocaj dur într-unul intermitent, care este mai greu de diagnosticat.

Un port duce două conversații

UDP 1701 stă sub ambele jumătăți ale protocolului, iar acest singur fapt încalcă mai multe reguli de firewall decât orice altă parte a configurației. Mai întâi vin o cerere de începere a conexiunii de control și răspunsul ei; cererea de sesiune și confirmarea care urmează nu stabilesc nimic mai mult decât perechea de identificatori. Apoi preia PPP: controlul linkului, apoi autentificarea, apoi protocolul de control IP pentru a conveni adresele. Fiecare etapă are vocabularul ei în jurnal, iar niciuna nu se anunță ca o defecțiune L2TP.

Citirea unei capturi exact în această ordine îți spune care etapă a eșuat, iar o defecțiune de autentificare PPP nu se repară editând xl2tpd. Portul partajat explică o altă defecțiune frecventă: o regulă care permite doar primele pachete ale unui flux lasă sesiunea să se stabilească și apoi blochează transferul. Permite 1701 pentru toată conversația, în ambele sensuri.

Cum facem tunelul util: redirecționare și NAT

O sesiune în sine ajunge doar la server. Accesul la internet al clienților are nevoie de redirecționare, de o regulă NAT pentru bazin pe legătura superioară și de DNS pe care clientul chiar îl poate interoga după ce linkul urcă. Bazinul trebuie să rămână și în afara intervalului LAN, altfel răspunsurile adresate clienților sunt livrate local în loc să fie împinse înapoi în tunel.

Pe server, activează redirecționarea cu sysctl -w net.ipv4.ip_forward=1, tradu bazinul cu iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE, apoi acceptă traficul ieșit din tunel cu o regulă FORWARD pentru -i ppp0 -o eth0 și traficul de întoarcere cu regula oglindă plus -m state --state RELATED,ESTABLISHED. Fă aceste reguli persistente între reporniri, pentru că un server care revine fără ele arată exact ca o configurație L2TP stricată.

A ajunge în LAN-ul propriu al serverului este altă sarcină: adaugă o rută de întoarcere pentru bazin pe routerul LAN, sau proxy ARP pe server. A ascunde clienții în spatele NAT atunci când ceva din LAN trebuie să li se adreseze direct doar programează o a doua sesiune de depanare pentru mai târziu.

Ce nu face stivul gol și cum verifici

Nicio parte a acestui stiv nu criptează cadrele PPP și nimic din el nu autentifică capătul îndepărtat ca serverul pe care l-ai ales cu adevărat. MS-CHAPv2 protejează schimbul de credențiale de un ascultător care doar observă, dar un atacator plasat pe cale poate încă perturba sesiunea. Clientul nativ Windows oferă L2TP doar împreună cu IPsec, așa că ia în calcul Linux, firmware-ul routerelor și clienții terți ca parteneri. Tratează configurația goală ca pe o treaptă de diagnostic, niciodată ca locul unde te oprești.

Verifică într-o ordine fixă: rulează xl2tpd -D în prim-plan, urmărește jurnalul pentru etapa PPP, citește adresa atribuită din ip addr la ambele capete, apoi capturează UDP 1701 pentru a confirma că datele circulă după ce sesiunea urcă. Dacă toate patru se potrivesc și traficul tot eșuează, vina este în rutare, NAT sau MTU, nu în L2TP însuși.