Lokal app, VPN-regel: hvorfor din FORWARD-kæde aldrig udløses

Du tilføjer en regel for VPN-trafik i FORWARD-kæden, kører anmodningen fra den samme Linux-boks, og tælleren bliver på nul. Reglen er sandsynligvis korrekt. Pakken tog aldrig den vej, fordi en anmodning, der opstår på maskinen selv, ikke videresendes af den. At følge pakkens liv fra socket til ledning forklarer hvorfor, og hvor reglen i stedet hører til.

Find ud af, hvor pakken blev født

Netfilters hookrækkefølge skiller tre tilfælde, og kun ét af dem involverer FORWARD:

En lokal applikation starter i OUTPUT-stien, fordi kernen allerede har fastslået, at pakken opstår her og aldrig er kandidat til videresendelse. At oprette en tunnel ændrer ikke den klassificering; tunnelen er en enhed, pakken kan forlade gennem, ikke et trin, der gør lokalt output til transit.

To pakker, én historie

Når tunnelen er oppe, er applikationens indre pakke og den krypterede ydre pakke forskellige objekter. Den indre pakke bærer den destination og nyttelast, som appen valgte. Den ydre pakke bærer ciphertext til peerens adresse og port, og det er den, der faktisk krydser den fysiske grænseflade.

Din politik handler om en af dem, og at vælge den forkerte er en almindelig grund til, at en regel ser ud til ikke at gøre noget. En regel, der matcher peerens ydre adresse, ser hver tunnelpakke ens, uanset hvad appen indeni laver. En regel, der matcher en indre destination, ser den trafik, du bekymrer dig om, og den udløses kun, hvis den pakke når det hook, du installerede reglen på.

Namespaces flytter grænsen

En container gør dette sværere uden at ændre princippet. Applikationens anmodning er lokalt output inde i containerens netværksnamespace. Værten modtager den trafik på en virtuel Ethernet-grænseflade og kan videresende den, så en FORWARD-regel på værten kan være meningsfuld, selvom den proces, der skabte anmodningen, aldrig rørte værtens OUTPUT-kæde.

Før du vælger et hook, skal du fastslå, hvor regelsættet og tunnelen faktisk bor. En tunnel inde i containeren, en tunnel på værten med containeren rutet gennem den, og en tunnel i et separat namespace er tre forskellige topologier med tre forskellige regelplaceringer. Læs reglerne inde i det namespace, der ejer enheden, ikke kun i det standard.

Spørg, om du overhovedet har brug for et mærke

Hvis målet er at sende ét destinationspræfiks gennem tunnelen, kan en rute til det præfiks være nok. Kontroller først de effektive ruter, inklusive alt serveren har skubbet: en omdirigeret standardrute sender langt mere trafik gennem VPN’et end den snævre politik, du havde i tankerne, og ingen mængde mærkning får resultatet til at matche hensigten.

Klassificering er nødvendig, når beslutningen afhænger af noget, en rute ikke kan udtrykke, såsom kilden, brugeren eller processen. For modtaget trafik virker mærkning i PREROUTING. For lokal trafik skal mærkningen ske i et output-trin, der kan udløse et nyt ruteopslag, efter mærket er sat. Med nftables er det en kæde af typen route på output-hooket; en almindelig output-filterkæde sætter værdien og lader ruten være uændret.

Med iptables bor ækvivalenten i mangle OUTPUT-ordningen, og samme krav gælder: routingbeslutningen skal genovervejes, efter mærket findes. Derefter skal en politikregel forbruge mærket og pege på en tabel med en brugbar rute. At sætte et conntrack-mærke er en tredje, separat operation; det gemmer en værdi på flowet og sætter ikke i sig selv den værdi på den aktuelle pakke, så routing kan læse den.

Verificér opslaget og tælleren sammen

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

Adressen og mærket er illustrative, og de to ruteopslag besvarer forskellige spørgsmål. Det andet spørger, hvad kernen ville gøre, hvis en pakke bar det mærke; det viser ikke, at dit regelsæt tildeler et. Behandl det som en hypotesetest, ikke som bevis for, at politikken virker.

Kør derefter en uskadelig anmodning og se på to ting på én gang: tælleren på det hook, du valgte, og den udgang, pakken faktisk tog. Hvis tælleren flytter sig, og pakken forlader et andet sted, er mærket eller tabellen forkert. Hvis ingen af dem flytter sig, når pakken slet ikke det hook, og det næste spørgsmål er namespacet eller stien.

Endelig skal testen afgrænses til det, mekanismen kan udtrykke. Én rute til én adresse bliver ikke en permanent politik for en tjeneste, hvis adresser roterer. Fastlæg pakkeomfanget først, og kontroller derefter, om routing- og mærkedesignet kan holde det omfang efter en genopkobling.