Dva klienti OpenVPN na jedné bráně Linux: rozdělte politiku

Dva démony OpenVPN mohou oba hlásit úspěšný tunel, zatímco brána posílá každého klienta stejným. V handshakei nic nerozhoduje o tom, který tunel klient použije; rozhoduje jádro, paket po paketu, tím, že prochází pravidla politiky a potom tabulku, kterou každé pravidlo pojmenuje. Jakmile se na to podíváte takto, konfigurace přestává být o volbách OpenVPN a stává se směrovací maticí se dvěma vlastníky.

Rozhoduje jádro, ne démon

Předávaný paket dorazí na rozhraní LAN a směrovací kód vyhodnocuje seznam pravidel v pořadí priorit. První pravidlo, jehož selektor odpovídá, pojmenuje tabulku a trasy této tabulky vyberou výstupní zařízení. Pokud tabulka nemá odpovídající trasu, vyhledávání pokračuje dalším pravidlem, a to je detail, který způsobuje, že nedokončené nastavení selhává tiše, nikoli nahlas.

Proces tunelu do toho procházení nemá co mluvit. Vytvoří rozhraní a může instalovat trasy, ale zda paket konkrétního klienta do tohoto rozhraní vstoupí, závisí zcela na tabulce, do které byl odeslán. Dva tunely se stejnými importovanými trasami proto soutěží a poslední zapisující vyhraje pro všechny. Proto může nastavení vypadat v konfiguračních souborech vyváženě a přesto posílat všechny klienty přes jediný démon.

Dejte každé instanci vlastní sadu prostředků

Začněte názvy, protože znovu použité názvy jsou způsob, jakým obě instance omylem začnou sdílet stav. Přidělte odlišná tunelová zařízení, odlišné konfigurační soubory, odlišné přihlašovací údaje a odlišné služební jednotky. Zaznamenejte vnější koncový bod a tunelovou adresu každé instance do stejné tabulky jako matici politiky, aby pozdější změna měla jedno místo, kam se podívat.

dev tun-office
route-nopull
pull-filter ignore "redirect-gateway"

dev tun-lab
route-nopull

route-nopull drží trasy, které server tlačí, mimo místní tabulku, což je přesně to, co chcete, když mají být tabulky politiky explicitní. Zda daný server tlačí také volbu redirect-gateway a zda vaše verze klienta podporuje formu s filtrem, stojí za ověření v manuálu, místo abyste to předpokládali.

Napište matici: zdroj, tabulka, zařízení

Pro každou skupinu klientů přidejte pravidlo, které vybírá tabulku podle zdrojové adresy, a potom do této tabulky vložte zamýšlenou cestu:

ip rule add from 10.8.1.0/24 lookup 100 priority 1000
ip rule add from 10.9.1.0/24 lookup 200 priority 1000
ip route add default dev tun-office table 100
ip route add default dev tun-lab table 200

Tabulka potřebuje cílové trasy, které má skupina mít, plus případné místní nebo správní výjimky, které udrží bránu použitelnou. Tabulka obsahující pouze výchozí trasu je politikou plného tunelu pro tuto skupinu, což může být přesně správné, ale mělo by to být rozhodnutí, nikoli opomenutí.

Vlastní transport tunelu není v klientské skupině

Šifrované pakety každého démona vznikají na samotné bráně a jsou adresovány vnějšímu protějšku. Pravidlo, které odpovídá pouze prefixu zdroje klienta, nechává tyto pakety na pokoji, a proto jsou pravidla omezená na zdroj bezpečnější než pravidla odpovídající na vše. Pravidlo bez selektoru může zachytit vlastní transport tunelu a poslat ho zpět tunelem, a spojení pak selže způsobem, který vypadá jako problém poskytovatele.

Držte místní správní relaci a cestu spodní vrstvy výslovně mimo tabulky politiky. Zapište ty výjimky vedle matice; jsou součástí návrhu, ne náhradním řešením, které je třeba během incidentu znovu objevit.

Volba cesty ji nepovoluje

Povolení předávání je druhé rozhodnutí učiněné později na cestě. Pravidlo firewallu, které přijímá pakety odcházející druhým tunelem, nezpůsobí, že ho směrovací kód vybere, a správná tabulka nedává povolení předávat. Musí existovat obojí a test, který prokáže jen jedno z nich, vás u toho druhého uvede v omyl. Když jedna skupina funguje a druhá ne, zkontrolujte tyto dva kroky odděleně, místo abyste přepisovali tabulky.

Překlad zdroje je třetí rozhodnutí a měl by být omezen na skupinu zdroje a tunelové zařízení, které ho skutečně nese. Přidejte vyhrazený řetěz pro obě instance, místo abyste mazali řetěz postrouting, protože nesouvisející služby zde mohou mít záznamy a smazání je tiše odstraní.

Co se stane, když jeden tunel spadne

Rozhodněte o chování při selhání předem. Když tunelová tabulka ztratí svou trasu, vyhledávání propadne na další pravidlo a provoz skupiny pokračuje druhým tunelem nebo běžným vzestupným spojem bez jakékoli chyby. Pokud to není přijatelné, přidejte ukončovací pravidlo s nižším číslem priority, které pro tento zdroj vrátí nedostupný výsledek, aby ztráta byla viditelná, místo aby byla pohlcena.

Odešlete nový požadavek z každé zdrojové skupiny a zaznamenejte čtyři skutečnosti: zvolenou tabulku, výstupní zařízení, přeložený zdroj a zda se odpověď vrátila stejnou cestou. Potom jeden tunel vypněte a opakujte. Dvě zařízení TUN v seznamu rozhraní dokazují, že oba démoni nastartovali; nic neříkají o tom, který z nich daný klient použil. Druhý běh, s jedním tunelem pryč, je ten, který ukazuje, zda vaše záložní pravidlo dělá to, co jste zamýšleli.