Kvifor iptables-regelen din aldri ser VPN-trafikk over ei bru

To virtuelle maskinar på same vert når LAN-et gjennom ei bru, og ein regel i ip forward-kjeda viser ein teljar som aldri flyttar seg. Rammer er ekte, trafikken går gjennom, og regelen er rett og slett ikkje på vegen. Å samanlikne dei to måtane Linux eksponerer trafikk over ei bru på forklarer denne stilla, og det forklarer òg kvifor det å laste éin gammal modul er eit dårlegare svar enn det ser ut som.

To vegar gjennom éin vert

Ein pakke kan forlate denne verten på to svært ulike måtar, og skilnaden avgjer kva krokar som ser han. Viss målet ligg bak ein fysisk port og ramma vert svitsja mellom to bruportar, videresender verten ei Ethernet-ramme; rutekoden vert ikkje spurt, og det skjer ingen ruta hopp. Viss målet er verten sjølv, eller eit nettverk som ein når gjennom eit tunellgrensesnitt, vert pakken ruta, og krokane på IP-laget gjeld faktisk. Ha denne gaffelen i tankane, for kvart seinare spørsmål om kjeder og familiar følgjer av kva av dei to vegane ei ramme tar.

Den skilnaden er heile historia bak ein regel som ikkje tel noko. Ei ramme over bru frå veth9a1 til enp3s0 kryssar brua, ikkje IP-stakken, så ei ip forward-kjede ser ingenting å matche. Grensesnittnamn i eit eldre døme avgjer ikkje kva veg du har, og difor er første steg å sjå på topologien i staden for regelverket.

Ein tunell legg til eit tredje tilfelle som fortener eit namn. Ei TUN-eining leverer IP-pakkar til verten, så dei vert ruta og går faktisk gjennom IP-kjeder, medan ei TAP-eining knytt til ei bru leverer rammer og oppfører seg som brutilfellet. Det er einingstypen, ikkje produktnamnet, som avgjer.

Samanlikn dei to familiane som kan sjå ei ramme over ei bru

Linux støttar innebygd brufiltrering gjennom bridge-familien til nftables, og treng ingen gammal modul for å inspisere og forkaste rammer undervegs. Kernelen sin eigen brudokumentasjon gir den tilrådinga direkte, noko det er verdt å vite før eit søkjeresultat fortel deg å laste ein modul.

Å bruke nft-kommandoen i staden for iptables plasserer ikkje i seg sjølv ein regel i rett familie. Ei kjede som er deklarert i bridge-familien ser rammer; ei kjede som er deklarert i ip, ip6 eller inet ser dei ikkje, uansett kva binærfil som oppretta henne. Familien er ein eigenskap ved kjeda, ikkje ved verktøyet som skreiv henne.

Den gamle vegen verkar annleis, og det er grunnen til å samanlikne i staden for å velje side av vane. Å laste br_netfilter og slå på bridge-nf-call-innstillingane eksponerer igjen IPv4- og IPv6-trafikk over bru gjennom krokane på IP-laget, slik at ein vanleg iptables-regel endeleg kan matche han. Rammene endrar seg ikkje; settet med krokar dei passerer, endrar seg, noko som betyr at kvar eksisterande vertsregel no har eit nytt publikum.

Les den effektive vegen før du legg til ein regel

Tre kommandoar fastslår kvar du er: kva brua er knytt til, om den gamle modulen er aktiv, og kva kjeder som alt finst i bridge-familien. Køyr dei før du skriv noko, fordi svaret avgjer kva av dei to designa du utvidar. Å hoppe over dette steget er måten ein korrekt regel endar opp i ei kjede som ingenting går gjennom.

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

Utdata skil tilfella reint. Portar som er lista under brua fortel kva grensesnitt som vert svitsja; eit tomt lsmod-resultat betyr inga synlegheit på IP-laget av rammer over bru; ei eksisterande forward-kjede i bridge-familien betyr at det alt finst ein policyeigar og at regelen din høyrer heime der i staden for i ei ny kjede for seg sjølv.

Legg så til éin regel som er lett å lese tilbake, med ein teljar og utan å endre avgjerda, og send éin representativ straum gjennom brua. Ein teljar som flyttar seg beviser at ramma nådde regelen. Det er alt han beviser, så følg opp med den avviste vegen òg, sidan ein policy som godtar alt òg gir ein teljar som flyttar seg.

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

Kvar den gamle modulen endrar åtferd

Å slå på den gamle vegen på ei bru som køyrer er ikkje ei nøytral handling med å leggje til synlegheit. Reglar som tidlegare var utilgjengelege for trafikk over bru vert tilgjengelege, inkludert vertsreglar skrivne for eit anna grensesnitt, og ein standard drop-policy i ip forward-kjeda kan plutseleg gjelde for rammer som før passerte urørt. På ein vert som vert administrert over den brua, er resultatet ei utestenging utan konsoll. Dette er ikkje ein hypotetisk feilmodus; det er den vanlege konsekvensen av å utvide eit sett med krokar på ein maskin du når gjennom vegen du nettopp utvida.

Den sikrare rekkjefølgja er å avgjere kva familie som eig policyen, skrive reglane der, og halde ein uavhengig gjenopprettingsveg før du endrar nokon sysctl. Viss to familiar båe har reglar, dokumenter kva som er autoritativ; to overlappande policyar er måten ein pakke vert godteken på eitt stad og forkasta på eit anna utan éi einaste fil å lese.

Isolasjonen sjølv treng framleis eit fullstendig design. Å tillate éi kjelde til éin destinasjon beviser berre at éin straum verkar, medan kravet vanlegvis er at ein VM ikkje kan nå naboane sine eller verten. Teljarar på avvisingsreglane betyr meir enn teljaren på godtakingsregelen, fordi godtakingsteljaren er den du alt forventa ville flytte seg.

Til slutt, hald vertsinndata-tilfellet åtskilt. Trafikk adressert til brua si eiga IP kjem inn på input, ikkje på forward, og ein regel i forward vil aldri sjå han, uansett kva familie du vel. Tre tilfelle, to familiar, éin lærdom: vegen avgjer kroken, og kroken avgjer om regelen din i det heile finst.