Aplicație locală, regulă VPN: de ce lanțul FORWARD nu se activează niciodată

Adaugi o regulă pentru traficul VPN în lanțul FORWARD, rulezi cererea de pe aceeași mașină Linux, iar contorul rămâne la zero. Regula este probabil corectă. Pachetul nu a urmat niciodată acel drum, pentru că o cerere generată pe mașina însăși nu este redirecționată de ea. Urmărirea vieții pachetului de la socket la cablu explică de ce, și unde ar trebui să stea regula în schimb.

Află unde s-a născut pachetul

Ordinea cârligelor din Netfilter separă trei cazuri, și doar unul dintre ele implică FORWARD:

O aplicație locală începe pe calea OUTPUT, pentru că nucleul a stabilit deja că pachetul provine de aici și nu este niciodată candidat pentru redirecționare. Crearea unui tunel nu schimbă această clasificare; tunelul este un dispozitiv prin care pachetul poate ieși, nu o etapă care transformă ieșirea locală în tranzit.

Două pachete, o poveste

După ce tunelul este ridicat, pachetul interior al aplicației și pachetul exterior criptat sunt obiecte diferite. Pachetul interior poartă destinația și încărcătura alese de aplicație. Pachetul exterior poartă text cifrat către adresa și portul partenerului, și el este cel care traversează efectiv interfața fizică.

Politica ta privește unul dintre ele, iar alegerea celui greșit este o cauză frecventă pentru care o regulă pare să nu facă nimic. O regulă care corespunde adresei externe a partenerului vede fiecare pachet al tunelului la fel, indiferent ce face aplicația din interior. O regulă care corespunde unei destinații interne vede traficul care te interesează, și se va declanșa doar dacă acel pachet ajunge la cârligul pe care ai instalat regula.

Spațiile de nume mută granița

Un container face acest lucru mai dificil fără a schimba principiul. Cererea aplicației este ieșire locală în interiorul spațiului de nume de rețea al containerului. Gazda primește acel trafic pe o interfață Ethernet virtuală și îl poate redirecționa, deci o regulă FORWARD pe gazdă poate avea sens chiar dacă procesul care a generat cererea nu a atins niciodată lanțul OUTPUT al gazdei.

Înainte de a alege un cârlig, stabilește unde trăiesc de fapt setul de reguli și tunelul. Un tunel în interiorul containerului, un tunel pe gazdă cu containerul rutat prin el și un tunel într-un spațiu de nume separat sunt trei topologii diferite cu trei plasări diferite ale regulilor. Citește regulile din interiorul spațiului de nume care deține dispozitivul, nu doar din cel implicit.

Întreabă dacă ai nevoie de un marcaj

Dacă scopul este să trimiți un prefix de destinație prin tunel, o rută pentru acel prefix poate fi suficientă. Verifică mai întâi rutele efective, inclusiv tot ce a împins serverul: o rută implicită redirecționată trimite mult mai mult trafic prin VPN decât politica îngustă pe care o aveai în minte, și nicio cantitate de marcare nu va face rezultatul să corespundă intenției.

Clasificarea este necesară când decizia depinde de ceva ce o rută nu poate exprima, cum ar fi sursa, utilizatorul sau procesul. Pentru traficul primit, marcarea în PREROUTING funcționează. Pentru traficul local, marcarea trebuie să aibă loc într-o etapă de ieșire care poate declanșa o nouă căutare de rută după ce marcajul este setat. Cu nftables aceasta este un lanț de tip route pe cârligul de ieșire; un lanț obișnuit de filtrare la ieșire va seta valoarea și va lăsa ruta neschimbată.

Cu iptables, echivalentul trăiește în aranjamentul mangle OUTPUT, și se aplică aceeași cerință: decizia de rutare trebuie reevaluată după ce marcajul există. Apoi o regulă de politică trebuie să consume marcajul și să indice o tabelă care conține o rută utilizabilă. Setarea unui marcaj conntrack este o a treia operație, separată; ea stochează o valoare pe flux și nu pune de la sine acea valoare pe pachetul curent pentru ca rutarea să o citească.

Verifică împreună căutarea și contorul

nft list ruleset
ip route get 198.51.100.25
ip route get 198.51.100.25 mark 0x1

Adresa și marcajul sunt ilustrative, iar cele două interogări de rută răspund la întrebări diferite. A doua întreabă ce ar face nucleul dacă un pachet ar purta acel marcaj; nu arată că setul tău de reguli atribuie unul. Trateaz-o ca pe un test de ipoteză, nu ca pe o dovadă că politica funcționează.

Apoi rulează o cerere inofensivă și urmărește două lucruri simultan: contorul de pe cârligul ales și ieșirea pe care pachetul a luat-o efectiv. Dacă contorul se mișcă și pachetul iese în altă parte, marcajul sau tabela sunt greșite. Dacă niciunul nu se mișcă, pachetul nu ajunge deloc la acel cârlig, iar următoarea întrebare este spațiul de nume sau calea.

În final, limitează testul la ce poate mecanismul să exprime. O rută pentru o adresă nu devine o politică permanentă pentru un serviciu ale cărui adrese se rotesc. Decide mai întâi sfera pachetelor, apoi verifică dacă proiectul de rutare și marcare poate păstra acea sferă după o reconectare.