Lokalna aplikacija, VPN pravilo: zašto vam FORWARD lanac nikad ne reaguje

Dodate pravilo za VPN saobraćaj u FORWARD lanac, pokrenete zahtjev sa iste Linux mašine, a brojač ostane na nuli. Pravilo je vjerovatno ispravno. Paket nikad nije išao tim putem, jer zahtjev nastao na samoj mašini ona ne prosljeđuje. Praćenje života paketa od socketa do žice objašnjava zašto je tako i gdje pravilo zapravo pripada.

Nađite gdje je paket rođen

Redoslijed kuka u Netfilteru razdvaja tri slučaja, a samo jedan od njih uključuje FORWARD:

Lokalna aplikacija počinje u OUTPUT putu, jer je kernel već utvrdio da paket nastaje ovdje i nikad nije kandidat za prosljeđivanje. Stvaranje tunela ne mijenja tu klasifikaciju; tunel je uređaj kroz koji paket može izaći, a ne faza koja lokalni izlaz pretvara u tranzit.

Dva paketa, jedna priča

Kad je tunel podignut, unutrašnji paket aplikacije i šifrovani vanjski paket su različiti objekti. Unutrašnji paket nosi odredište i korisni teret koje je aplikacija odabrala. Vanjski paket nosi šifrat na adresu i port peera, i upravo on stvarno prelazi fizički interfejs.

Vaša politika tiče se jednog od njih, a odabir pogrešnog čest je razlog zašto se čini da pravilo ne radi ništa. Pravilo koje odgovara vanjskoj adresi peera vidi svaki paket tunela jednako, šta god aplikacija unutra radila. Pravilo koje odgovara unutrašnjem odredištu vidi saobraćaj koji vas zanima, i reagovat će samo ako taj paket stigne do kuke na koju ste pravilo postavili.

Imenski prostori pomjeraju granicu

Kontejner to otežava ne mijenjajući princip. Zahtjev aplikacije je lokalni izlaz unutar mrežnog imenskog prostora kontejnera. Host taj saobraćaj prima na virtuelnom Ethernet interfejsu i može ga proslijediti, pa FORWARD pravilo na hostu može imati smisla iako proces koji je stvorio zahtjev nikad nije dotakao OUTPUT lanac hosta.

Prije nego odaberete kuku, utvrdite gdje skup pravila i tunel zaista žive. Tunel unutar kontejnera, tunel na hostu s kontejnerom rutiranim kroz njega i tunel u zasebnom imenskom prostoru tri su različite topologije s tri različita smještaja pravila. Čitajte pravila unutar imenskog prostora koji posjeduje uređaj, ne samo u podrazumijevanom.

Pitajte je li vam oznaka uopće potrebna

Ako je cilj poslati jedan prefiks odredišta kroz tunel, ruta za taj prefiks može biti dovoljna. Prvo provjerite efektivne rute, uključujući sve što je server gurnuo: preusmjerena podrazumijevana ruta šalje mnogo više saobraćaja kroz VPN nego uska politika koju ste imali na umu, i nikakva količina označavanja neće uskladiti rezultat s namjerom.

Klasifikacija je potrebna kad odluka zavisi od nečega što ruta ne može izraziti, poput izvora, korisnika ili procesa. Za primljeni saobraćaj označavanje u PREROUTING radi. Za lokalni saobraćaj oznaka se mora postaviti u izlaznoj fazi koja može pokrenuti novo traženje rute nakon što oznaka postoji. U nftablesu to je lanac tipa route na izlaznoj kuki; običan izlazni filtarski lanac postavit će vrijednost i ostaviti rutu nepromijenjenom.

U iptablesu ekvivalent živi u mangle OUTPUT rasporedu, i isti zahtjev vrijedi: odluka o rutiranju mora se preispitati nakon što oznaka postoji. Zatim pravilo politike mora potrošiti oznaku i pokazati na tablicu koja sadrži upotrebljivu rutu. Postavljanje conntrack oznake treća je, zasebna operacija; ona pamti vrijednost na toku i sama po sebi ne stavlja tu vrijednost na trenutni paket da bi je rutiranje pročitalo.

Provjerite traženje i brojač zajedno

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

Adresa i oznaka su ilustrativne, a dva upita rute odgovaraju na različita pitanja. Drugi pita šta bi kernel uradio kad bi paket nosio tu oznaku; on ne pokazuje da vaš skup pravila neku dodjeljuje. Tretirajte ga kao test hipoteze, ne kao dokaz da politika radi.

Zatim pokrenite bezopasan zahtjev i gledajte dvije stvari istovremeno: brojač na kuki koju ste odabrali i izlaz koji je paket stvarno uzeo. Ako se brojač pomjeri a paket izađe negdje drugdje, oznaka ili tablica je pogrešna. Ako se ni jedno ne pomjeri, paket uopće ne stiže do te kuke, i sljedeće pitanje je imenski prostor ili put.

Na kraju, ograničite test na ono što mehanizam može izraziti. Jedna ruta za jednu adresu ne postaje trajna politika za servis čije se adrese mijenjaju. Prvo odlučite obuhvat paketa, pa provjerite može li dizajn rutiranja i označavanja zadržati taj obuhvat nakon ponovnog povezivanja.