Prečo vaše pravidlo iptables nikdy nevidí prevádzku VPN cez most

Dva virtuálne stroje na tom istom hostiteľovi dosiahnu LAN cez most a pravidlo umiestnené v reťazci ip forward ukazuje čítač, ktorý sa nikdy nepohne. Rámce sú skutočné, prevádzka prechádza a pravidlo jednoducho nie je na jej ceste. Porovnanie dvoch spôsobov, akými Linux vystavuje prevádzku cez most, vysvetľuje to ticho a vysvetľuje aj to, prečo je načítanie jedného legacy modulu horšia odpoveď, než sa zdá.

Dve cesty cez jedného hostiteľa

Paket môže opustiť tohto hostiteľa dvoma veľmi odlišnými spôsobmi a rozdiel rozhoduje o tom, ktoré hooky ho uvidia. Ak je cieľ za fyzickým portom a rámec sa prepína medzi dvoma portmi mostu, hostiteľ preposiela Ethernetový rámec; smerovací kód sa nevolá a nedochádza k žiadnemu smerovanému skoku. Ak je cieľom sám hostiteľ alebo sieť dostupná cez tunelové rozhranie, paket sa smeruje a hooky IP vrstvy sa skutočne uplatnia. Majte toto rozvetvenie na pamäti, pretože každá ďalšia otázka o reťazcoch a rodinách vychádza z toho, ktorú z dvoch ciest rámec zvolí.

Tento rozdiel je celý príbeh pravidla, ktoré nič nepočíta. Rámec cez most z veth9a1 do enp3s0 prechádza most, nie IP zásobník, takže reťazec ip forward nevidí nič na porovnanie. Názvy rozhraní v staršom príklade nerozhodujú, ktorú cestu máte, a preto je prvým krokom pozrieť sa na topológiu, nie na sadu pravidiel.

Tunel pridáva tretí prípad, ktorý stojí za pomenovanie. Zariadenie TUN odovzdáva IP pakety hostiteľovi, takže sa smerujú a skutočne prechádzajú cez IP reťazce, zatiaľ čo zariadenie TAP pripojené k mostu odovzdáva rámce a správa sa ako prípad mostu. Rozhoduje typ zariadenia, nie názov produktu.

Porovnajte dve rodiny, ktoré vidia rámec cez most

Linux podporuje natívne filtrovanie mostu cez rodinu bridge v nftables a nepotrebuje žiadny legacy modul na kontrolu a zahadzovanie rámcov za letu. Vlastná dokumentácia mostu jadra to odporúča priamo, čo stojí za to vedieť skôr, než vám výsledok hľadania povie načítať modul.

Použitie príkazu nft namiesto iptables samo o sebe neumiestni pravidlo do správnej rodiny. Reťazec deklarovaný v rodine bridge vidí rámce; reťazec deklarovaný v ip, ip6 alebo inet ich nevidí, bez ohľadu na to, ktorý binárny súbor ho vytvoril. Rodina je vlastnosť reťazca, nie nástroja, ktorý ho napísal.

Legacy cesta funguje inak, a práve preto sa oplatí porovnávať, a nie vyberať si stranu zo zvyku. Načítanie br_netfilter a zapnutie nastavení bridge-nf-call znova vystaví prevádzku IPv4 a IPv6 cez most cez hooky IP vrstvy, takže bežné pravidlo iptables mu konečne môže zodpovedať. Rámce sa nemenia; mení sa sada hookov, ktorými prechádzajú, čo znamená, že každé existujúce pravidlo hostiteľa má teraz nové publikum.

Prečítajte si účinnú cestu, než pridáte pravidlo

Tri príkazy určia, kde ste: k čomu je most pripojený, či je legacy modul aktívny a aké reťazce už v rodine bridge existujú. Spustite ich skôr, než čokoľvek napíšete, pretože odpoveď rozhoduje, ktorý z dvoch návrhov rozširujete. Preskočenie tohto kroku je spôsob, akým správne pravidlo skončí v reťazci, ktorým nič neprechádza.

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

Výstup prípady čisto oddeľuje. Porty uvedené pod mostom vám povedia, ktoré rozhrania sa prepínajú; prázdny výsledok lsmod znamená žiadnu viditeľnosť rámcov cez most na IP vrstve; existujúci reťazec forward rodiny bridge znamená, že vlastník politiky už existuje a vaše pravidlo patrí tam, nie do nového vlastného reťazca.

Potom pridajte jedno pravidlo, ktoré sa dá ľahko prečítať späť, s čítačom a bez zmeny verdiktu, a pošlite mostom jeden reprezentatívny tok. Čítač, ktorý sa hýbe, dokazuje, že rámec dosiahol pravidlo. To je všetko, čo dokazuje, preto ho nasledujte aj zakázanou cestou, keďže politika, ktorá prijíma všetko, tiež vytvára pohybujúci sa čítač.

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

Kde legacy modul mení správanie

Zapnutie legacy cesty na bežiacom moste nie je neutrálny akt pridania viditeľnosti. Pravidlá, ktoré boli predtým nedosiahnuteľné pre prevádzku cez most, sa stanú dosiahnuteľnými, vrátane pravidiel hostiteľa písaných pre iné rozhranie, a predvolená politika drop v reťazci ip forward môže zrazu platiť pre rámce, ktoré predtým prechádzali nedotknuté. Na hostiteľovi spravovanom cez tento most je výsledkom uzamknutie bez konzoly. To nie je hypotetický režim zlyhania; je to bežný dôsledok rozšírenia sady hookov na stroji, ku ktorému sa dostávate cestou, ktorú ste práve rozšírili.

Bezpečnejší postup je rozhodnúť, ktorá rodina vlastní politiku, napísať pravidlá tam a ponechať nezávislú cestu obnovy skôr, než zmeníte akýkoľvek sysctl. Ak pravidlá držia obe rodiny, zdokumentujte, ktorá je autoritatívna; dve prekrývajúce sa politiky sú spôsob, akým je paket prijatý na jednom mieste a zahodený na inom bez jediného súboru na prečítanie.

Izolácia sama ešte potrebuje úplný návrh. Povolenie jedného zdroja k jednému cieľu dokazuje len to, že jeden tok funguje, zatiaľ čo požiadavka zvyčajne je, aby VM nemohla dosiahnuť svojich susedov ani hostiteľa. Čítače na pravidlách odmietnutia sú dôležitejšie než čítač na pravidle prijatia, pretože čítač prijatia je ten, o ktorom ste už očakávali, že sa pohne.

Nakoniec držte prípad vstupu hostiteľa oddelene. Prevádzka adresovaná vlastnej IP mostu prichádza na input, nie na forward, a pravidlo vo forward ho nikdy neuvidí, nech zvolíte akúkoľvek rodinu. Tri prípady, dve rodiny, jedna lekcia: cesta rozhoduje o hooku a hook rozhoduje o tom, či vaše pravidlo vôbec existuje.