Hvorfor din iptables-regel aldrig ser VPN-trafik over en bro

To virtuelle maskiner på samme vært når LAN'et gennem en bro, og en regel i ip forward-kæden viser en tæller, der aldrig flytter sig. Rammede er virkelige, trafikken passerer, og reglen er ganske enkelt ikke på dens vej. At sammenligne de to måder, Linux udstiller trafik over en bro på, forklarer tavsheden, og det forklarer også, hvorfor indlæsning af ét gammelt modul er et dårligere svar, end det ser ud.

To veje gennem én vært

En pakke kan forlade denne vært på to meget forskellige måder, og forskellen afgør, hvilke hooks der ser den. Hvis destinationen ligger bag en fysisk port, og rammen svitsjes mellem to broporte, videresender værten en Ethernet-ramme; routingkoden konsulteres ikke, og der sker ikke noget rutet hop. Hvis destinationen er værten selv eller et netværk, der nås gennem en tunnelgrænseflade, routes pakken, og IP-lagets hooks gælder faktisk. Hold den forgrening i tankerne, for hvert senere spørgsmål om kæder og familier følger af, hvilken af de to veje en ramme tager.

Den skelnen er hele historien bag en regel, der ikke tæller noget. En ramme over bro fra veth9a1 til enp3s0 krydser broen, ikke IP-stakken, så en ip forward-kæde ser intet at matche. Grænsefladenavne i et ældre eksempel afgør ikke, hvilken vej du har, og derfor er første skridt at se på topologien i stedet for på regelsættet.

En tunnel tilføjer et tredje tilfælde, der er værd at navngive. En TUN-enhed leverer IP-pakker til værten, så de routes og gennemløber faktisk IP-kæder, mens en TAP-enhed tilsluttet en bro leverer rammer og opfører sig som bro-tilfældet. Det er enhedstypen, ikke produktnavnet, der afgør det.

Sammenlign de to familier, der kan se en ramme over en bro

Linux understøtter indbygget brofiltrering gennem nftables' bridge-familie, og den har ikke brug for noget gammelt modul for at inspicere og droppe rammer undervejs. Kernens egen brodokumentation giver den anbefaling direkte, hvilket er værd at vide, før et søgeresultat fortæller dig at indlæse et modul.

At bruge nft-kommandoen i stedet for iptables placerer ikke i sig selv en regel i den rigtige familie. En kæde, der er deklareret i bridge-familien, ser rammer; en kæde, der er deklareret i ip, ip6 eller inet, gør ikke, uanset hvilken binær der oprettede den. Familien er en egenskab ved kæden, ikke ved værktøjet, der skrev den.

Den gamle vej virker anderledes, og det er grunden til at sammenligne i stedet for at vælge side af vane. Indlæsning af br_netfilter og aktivering af bridge-nf-call-indstillingerne udstiller igen IPv4- og IPv6-trafik over bro gennem IP-lagets hooks, så en almindelig iptables-regel endelig kan matche den. Rammerne ændrer sig ikke; sættet af hooks, de passerer, gør, hvilket betyder, at hver eksisterende værtsregel nu har et nyt publikum.

Læs den effektive vej, før du tilføjer en regel

Tre kommandoer fastslår, hvor du er: hvad broen er tilsluttet, om det gamle modul er aktivt, og hvilke kæder der allerede findes i bridge-familien. Kør dem, før du skriver noget, fordi svaret afgør, hvilket af de to designs du udvider. At springe dette skridt over er måden, hvorpå en korrekt regel ender i en kæde, som intet gennemløber.

bridge link show
lsmod | grep br_netfilter
nft list ruleset | grep -A4 "chain forward"

Outputtet adskiller tilfældene rent. Porte, der er listet under broen, fortæller, hvilke grænseflader der svitsjes; et tomt lsmod-resultat betyder ingen synlighed på IP-laget af rammer over bro; en eksisterende forward-kæde i bridge-familien betyder, at der allerede findes en politiksejer, og at din regel hører til der i stedet for i en ny kæde for sig selv.

Tilføj derefter én regel, der er let at læse tilbage, med en tæller og uden at ændre afgørelsen, og send én repræsentativ strøm gennem broen. En tæller, der flytter sig, beviser, at rammen nåede reglen. Det er alt, hvad den beviser, så følg op med den afviste vej også, da en politik, der accepterer alt, også giver en tæller, der flytter sig.

nft add rule bridge filter forward iifname "veth9a1" oifname "enp3s0" counter accept

Hvor det gamle modul ændrer adfærd

At aktivere den gamle vej på en kørende bro er ikke en neutral handling med at tilføje synlighed. Regler, der tidligere var uopnåelige for trafik over bro, bliver opnåelige, inklusive værtsregler skrevet til en anden grænseflade, og en standard drop-politik i ip forward-kæden kan pludselig gælde for rammer, der plejede at passere urørt. På en vært, der administreres over den bro, er resultatet en udelukkelse uden konsol. Det er ikke en hypotetisk fejltilstand; det er den almindelige konsekvens af at udvide et sæt hooks på en maskine, du når gennem den vej, du netop har udvidet.

Den sikrere rækkefølge er at beslutte, hvilken familie der ejer politikken, skrive reglerne der og beholde en uafhængig gendannelsesvej, før du ændrer nogen sysctl. Hvis to familier begge har regler, så dokumentér, hvilken der er autoritativ; to overlappende politikker er måden, hvorpå en pakke accepteres ét sted og droppes et andet uden en enkelt fil at læse.

Isolation kræver stadig et fuldstændigt design. At tillade én kilde til én destination beviser kun, at én strøm virker, mens kravet normalt er, at en VM ikke kan nå sine naboer eller værten. Tællere på afvisningsreglerne betyder mere end tælleren på acceptreglen, fordi accepttælleren er den, du allerede forventede ville flytte sig.

Til sidst skal du holde værtsinput-tilfældet adskilt. Trafik rettet mod broens egen IP ankommer til input, ikke til forward, og en regel i forward vil aldrig se den, uanset hvilken familie du vælger. Tre tilfælde, to familier, én lektie: vejen afgør hooket, og hooket afgør, om din regel overhovedet findes.