Dva klienti na jednom serveru si vyměňují soubory, přenos uspěje a každé pravidlo přesměrování, které namíříte na tunel, hlásí nula paketů. Pravidla nejsou rozbitá a řetězec není na špatném místě. Když je zapnuté přesměrování mezi protějšky, paket se doručí uvnitř procesu serveru a zásobník hostitele se nikdy nestane routerem, takže jaderný firewall nemá co počítat. Pochopení tohoto rozdělení rozhoduje o tom, zda si zkratku ponecháte, nebo cestu znovu postavíte přes jádro.

Sledujte jeden paket skrz server

Ve směrovaném tunelu předá démon dešifrovaný paket každého klienta tunelovému zařízení. Odtud ho hostitel směruje, spustí se háček přesměrování a pravidlo, které odpovídá tunelovému zařízení, může provoz počítat nebo zahazovat. To je cesta, kterou předpokládá většina příkladů firewallu.

Forwarding pathWho decidesWhat the host firewall sees
Kernel routing between clientsHost routing table and forward rulesEvery inner packet, with interface names
Peer forwarding inside the server processThe VPN daemon's own peer tableOnly the outer encrypted transport

Zkratka odstraňuje hostitele ze středu. Dešifrovaný paket jedné relace se předá jiné relaci uvnitř démona a vnitřní paket se nikdy nevysílá na tunelové zařízení ani ho hostitel nesměruje. Zapouzdřený provoz stále prochází fyzickým rozhraním, takže vnější odchyt vypadá zaneprázdněně, zatímco vnitřní pravidla mlčí. Odchyt pořízený na tunelovém zařízení neukazuje vůbec nic, což překvapí každého, kdo tam očekává sledování přenosu. Tato asymetrie je nejrychlejší způsob, jak zkratku rozpoznat zvenčí démona.

Test s počítadlem, který rozhodne, která cesta proběhla

Připojte počítadlo k pravidlu, které by se mělo uplatnit, spusťte přenos mezi dvěma klienty, které by toto pravidlo mělo zablokovat, a potom počítadlo přečtěte.

sudo nft list ruleset
sudo nft add rule inet filter forward iifname "tun0" oifname "tun0" counter accept
sudo nft list chain inet filter forward

Pokud přenos uspěje a počítadlo zůstane na nule, jádro ty pakety nikdy nezpracovalo a žádné úpravy pravidel to nezmění. Zopakujte stejný test proti službě na samotném serveru, protože tento tok zásobníkem hostitele skutečně prochází a jeho počítadlo se hýbe. Právě srovnání obou výsledků dává odpověď.

Dva detaily brání chybnému čtení. Název rozhraní zapsaný ve štítku řetězce sám o sobě nic nefiltruje, protože shoda probíhá na polích rozhraní uvnitř pravidel. A přemostěný návrh vrstvy 2 se chová zase jinak: klienti tam sdílejí jednu broadcast doménu, takže objevování protějšků je očekávané, a ne závada směrování.

Přepínač není seznam přístupu

Tohle je ta část, která stojí odpoledne. Přesměrování mezi protějšky je jediné nastavení zapnuto nebo vypnuto, a dokud je zapnuté, démon je jediným bodem přesměrování. Firewall hostitele nedokáže vyjádřit, kdo se ke komu dostane, a soubory po klientech nepřemění přepínač v matici zásad.

Pokud potřebujete pravidla po protějšcích, volba je mezi vzdáním se zkratky a vzdáním se firewallu hostitele jako nástroje řízení. Vypnutí obnoví přesměrování přes jádro, což vyžaduje zapnuté IP přesměrování na serveru a výslovná pravidla pro toky, které chcete. Ponechání zapnuté znamená, že zásada žije v konfiguraci démona, což je v praxi buď všechny protějšky, nebo žádný.

Oddělené serverové procesy s vlastními fondy adres a porty jsou schůdná střední cesta. Každý proces nese právě jedno rozhodnutí o přístupu, takže dvě skupiny mohou mít různá pravidla bez matice zásad. Hostitel může mezi fondy směrovat, když je to zamýšlené, a firewall pak tyto toky vidí, protože procházejí hostitelem. Cenou jsou porty navíc, certifikáty navíc a profil pro každou skupinu.

Volba bodu přesměrování

Zvolte přesměrování přes jádro, když je firewall motorem zásad, když potřebujete protokolování po tocích nebo když záleží na účtování. Cenou je propustnost přes zásobník hostitele a více pravidel k údržbě. Přínosem je, že každý existující nástroj, od počítadel po exportéry toků, znovu popisuje provoz. Na malém serveru je tato cena neviditelná; na vytíženém relé není.

Zvolte přesměrování uvnitř procesu, když je provoz mezi protějšky buď celý povolený, nebo celý zakázaný a server je na to dimenzovaný. Cenou je, že počítadla, disciplíny fronty a sledování spojení už vnitřní toky nepopisují; to je přijatelné jen tehdy, když se na ně později nikdo nespoléhá.

Ať zvolíte cokoli, zapište to vedle pravidel firewallu. Sada pravidel, která vypadá, že provoz mezi protějšky povoluje, zatímco démon stejně rozhoduje, mate dalšího člověka, který bude ladit neúspěšný přenos. Kdo čte jen pravidla, bude předpokládat, že branou je jádro.

Co zkontrolovat před změnou pravidel

Přečtěte konfiguraci, kterou server skutečně načetl, ne soubor, který si pamatujete jako upravený, a ověřte, zda je volba pro protějšky přítomná. Pokud jste ji změnili, ujistěte se, že se služba znovu načetla, a ne jen přepsala soubor na disku.

Potom zopakujte test s tokem od klienta k serveru, abyste dokázali, že pravidlo vůbec odpovídá, a zkontrolujte odeslané trasy, protože chybějící trasa vypadá ze strany klienta přesně jako blokace firewallem. Pořadí pravidel měňte až poté, co víte, který bod přesměrování rozhodnutí vlastní.

Související články