Proč vaše pravidlo iptables nikdy nevidí provoz VPN přes most

Dva virtuální stroje na stejném hostiteli dosáhnou LAN přes most a pravidlo umístěné v řetězci ip forward ukazuje čítač, který se nikdy nehne. Rámce jsou skutečné, provoz prochází a pravidlo prostě není na jeho cestě. Srovnání dvou způsobů, jakými Linux vystavuje provoz přes most, vysvětluje to ticho a vysvětluje i to, proč je načtení jednoho legacy modulu horší odpověď, než se zdá.

Dvě cesty přes jednoho hostitele

Paket může tohoto hostitele opustit dvěma velmi odlišnými cestami a rozdíl rozhoduje o tom, které hooky ho uvidí. Pokud je cíl za fyzickým portem a rámec se přepíná mezi dvěma porty mostu, hostitel přeposílá Ethernetový rámec; směrovací kód se nevolá a nedochází k žádnému směrovanému skoku. Pokud je cílem sám hostitel nebo síť dostupná přes tunelové rozhraní, paket se směruje a hooky IP vrstvy se skutečně uplatní. Mějte toto rozcestí na paměti, protože každá další otázka o řetězcích a rodinách vychází z toho, kterou z těch dvou cest rámec zvolí.

Tento rozdíl je celý příběh pravidla, které nic nepočítá. Rámec přes most z veth9a1 do enp3s0 přechází most, ne IP zásobník, takže řetězec ip forward nevidí nic k porovnání. Názvy rozhraní ve starším příkladu nerozhodují, kterou cestu máte, a proto je prvním krokem podívat se na topologii, nikoli na sadu pravidel.

Tunel přidává třetí případ, který stojí za pojmenování. Zařízení TUN předává IP pakety hostiteli, takže se směrují a skutečně procházejí IP řetězci, zatímco zařízení TAP připojené k mostu předává rámce a chová se jako případ s mostem. Rozhoduje typ zařízení, ne název produktu.

Porovnejte dvě rodiny, které mohou vidět rámec přes most

Linux podporuje nativní filtrování mostu prostřednictvím rodiny bridge v nftables a nepotřebuje žádný legacy modul, aby zkoumal a zahazoval rámce za letu. Vlastní dokumentace mostu jádra to doporučuje přímo, což stojí za to vědět dřív, než vám výsledek hledání řekne, abyste modul načetli.

Použití příkazu nft místo iptables samo o sobě neumístí pravidlo do správné rodiny. Řetězec deklarovaný v rodině bridge vidí rámce; řetězec deklarovaný v ip, ip6 nebo inet je nevidí, ať ho vytvořil jakýkoli binární soubor. Rodina je vlastnost řetězce, ne nástroje, který ho napsal.

Legacy cesta funguje jinak, a proto je důvod porovnávat, místo abyste si ze zvyku vybírali stranu. Načtení br_netfilter a zapnutí nastavení bridge-nf-call znovu vystaví provoz IPv4 a IPv6 přes most skrze hooky IP vrstvy, takže běžné pravidlo iptables mu konečně může odpovídat. Rámce se nemění; mění se sada hooků, kterými procházejí, což znamená, že každé stávající pravidlo hostitele má nyní nové publikum.

Přečtěte si efektivní cestu, než přidáte pravidlo

Tři příkazy určí, kde jste: k čemu je most připojen, zda je legacy modul aktivní a jaké řetězce už v rodině bridge existují. Spusťte je dřív, než cokoli napíšete, protože odpověď rozhoduje, který ze dvou návrhů rozšiřujete. Přeskočení tohoto kroku je způsob, jak správné pravidlo skončí v řetězci, kterým nic neprochází.

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

Výstup případy čistě odděluje. Porty uvedené pod mostem vám řeknou, která rozhraní se přepínají; prázdný výsledek lsmod znamená žádnou viditelnost rámců přes most na IP vrstvě; existující forward řetězec rodiny bridge znamená, že vlastník politiky už existuje a vaše pravidlo patří tam, ne do nového vlastního řetězce.

Potom přidejte jedno pravidlo, které lze snadno přečíst zpět, s čítačem a beze změny verdiktu, a pošlete mostem jeden reprezentativní tok. Čítač, který se hýbe, dokazuje, že rámec dosáhl pravidla. To je všechno, co dokazuje, proto ho následujte i zakázanou cestou, protože politika, která přijímá vše, také vytváří pohybující se čítač.

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

Kde legacy modul mění chování

Zapnutí legacy cesty na běžícím mostu není neutrální akt přidání viditelnosti. Pravidla, která byla dříve nedosažitelná pro provoz přes most, se stanou dosažitelnými, včetně pravidel hostitele psaných pro jiné rozhraní, a výchozí politika drop v řetězci ip forward může najednou platit pro rámce, které dřív procházely nedotčené. Na hostiteli spravovaném přes tento most je výsledkem uzamčení bez konzole. To není hypotetický režim selhání; je to běžný důsledek rozšíření sady hooků na stroji, ke kterému se dostáváte cestou, kterou jste právě rozšířili.

Bezpečnější postup je rozhodnout, která rodina vlastní politiku, napsat pravidla tam a ponechat nezávislou cestu pro obnovu dřív, než změníte jakýkoli sysctl. Pokud pravidla drží obě rodiny, zdokumentujte, která je autoritativní; dvě překrývající se politiky jsou způsob, jak je paket přijat na jednom místě a zahozen na jiném bez jediného souboru k přečtení.

Izolace sama stále potřebuje úplný návrh. Povolení jednoho zdroje k jednomu cíli dokazuje jen to, že jeden tok funguje, zatímco požadavek obvykle je, aby VM nemohla dosáhnout na své sousedy ani na hostitele. Čítače na pravidlech zamítnutí jsou důležitější než čítač na pravidle přijetí, protože čítač přijetí je ten, u kterého jste už očekávali, že se pohne.

Nakonec držte případ vstupu hostitele odděleně. Provoz adresovaný vlastní IP mostu přichází na input, ne na forward, a pravidlo ve forward ho nikdy neuvidí, ať zvolíte jakoukoli rodinu. Tři případy, dvě rodiny, jedna lekce: cesta rozhoduje o hooku a hook rozhoduje o tom, zda vaše pravidlo vůbec existuje.