Dva tunely OpenVPN na jednom hostiteli Linux: komu patří trasa?

Dva profily jsou připojené a jeden z nich tiše nese provoz určený druhému. Hostitel Linux dokáže spustit oba klienty OpenVPN najednou bez potíží. Co nedokáže, je rozhodnout za vás, který proces si smí nárokovat který prefix. To rozhodnutí je třeba učinit dřív, než druhý tunel nastartuje, ne až poté, co nějaký prostředek přestane odpovídat.

Začněte úkolem, který musí druhé spojení splnit

Kancelář dostupná přes jeden profil a laboratoř dostupná přes druhý vyžadují, aby oba tunely běžely a žádný z nich si nenárokoval všechno. Jedna zarputilá aplikace, která musí odcházet přes druhý profil, potřebuje pravidlo zásad, ne druhou výchozí trasu. Záložní spojení potřebuje jen jeden tunel běžící v danou chvíli, takže rezerva by neměla startovat spolu se strojem.

To jsou tři různé konfigurace a pletou se proto, že všechny tři začínají stejně: druhý profil a úspěšné připojení. Nejprve si zapište zamýšlené uspořádání, potom k němu konfigurujte. Jedna věta o záměru ušetří hodinu zachytávání paketů.

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

První příkaz vypíše běžící instance, včetně těch spuštěných ručně mimo správce. Druhý vypíše aktuální nárok na výchozí trasu, což je stav, který budete muset později vysvětlit.

Překrývající se pooly se rozbijí dřív než směrování

Dva servery ochotně přidělí adresy ze stejného 10.8.0.0/24. Klient pak drží dvě rozhraní v jednom prefixu a nic neříká, které cílové adrese patří které, a výsledné chování vypadá jako porucha směrování, ale ve skutečnosti je to porucha číslování. Přečíslování poolu stojí jednu úpravu konfigurace; každé následné směrovací obejití stojí celý víkend. Podívejte se na pool dřív, než k němu přidáte trasu.

Podívejte se i na místní LAN. Domácí LAN s číslem 192.168.1.0/24, kterou jeden tunel také vystavuje, vytváří stejnou nejednoznačnost a příznakem je název hostitele, který se přeloží, ale spojení se nikdy nedokončí. Vypadá to jako porucha překladu názvů, dokud nevypíšete trasy.

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

Porovnejte oba výstupy se dvěma konfiguracemi serverů, než se dotknete klienta. Pokud se prefixy překrývají, zastavte se a přečíslujte, protože je nerozdělí žádné množství restartů.

Dejte každému profilu vlastní jednotku a každému prefixu vlastníka

Každý profil dostane vlastní název instance a vlastní konfigurační soubor, takže instance s názvem office načítá office.conf, zatímco instance s názvem lab načítá lab.conf. Potvrďte toto mapování přes správce služeb, místo abyste věřili výpisu adresáře, protože drop-in může změnit, který soubor se načte. Špatné mapování znamená, že ladíte profil, který neběží.

Pak rozhodněte, kdo instaluje trasy. Když servery protlačují nekompatibilní sady, buď protlačení odmítněte a vypište prefixy sami, nebo nechte jeden profil držet výchozí trasu a druhý veďte pravidly zásad. Dva procesy, které oba instalují výchozí trasu, skončí tichým vítězem a bez písemného záznamu o rozhodnutí.

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

První ukazuje jednotku s jakýmkoli přepsáním, které mění její argumenty. Druhá ukazuje, zda profil vůbec přijímá protlačené trasy, což je přepínač, který určuje všechno další.

Značky udržují odpovědi na rozhraní, ze kterého přišly

Když každý tunel obsluhuje jiné zdroje, odpověď může odejít špatným spojením a spojení po prvním paketu umře. Vzor, který vydrží, je označit příchozí pakety podle vstupního rozhraní, obnovit tuto značku na odpovědi a dát každé značce tabulku s vlastní výchozí bránou.

Volné filtrování zpětné cesty se obvykle musí pro dotčená rozhraní uvolnit, protože odpověď legitimně přichází spojením, které by hlavní tabulka nikdy nevybrala. Držte značky úzké, aby nikdy nezachytily vlastní šifrovaný provoz tunelů, což by poslalo tunel sám sebou.

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

Přečtěte si existující pravidla, než přidáte další. Duplicitní priority a zapomenuté tabulky jsou obvyklým důvodem, proč se politika značek zdá zcela bez účinku.

Dokažte izolaci zastavením jednoho spojení

S oběma tunely nahoru si zapište adresu každého rozhraní, trasu k jednomu hostiteli za každým tunelem a cestu, kterou se vydá nesouvisející cíl. Požádejte jádro o vyhledání, místo abyste četli jednu tabulku, protože jedna tabulka nikdy neukáže konečné rozhodnutí.

Potom zastavte jednu instanci a sledujte, jak její rozhraní a trasy mizí, zatímco druhá pokračuje. Přerušení v přeživší znamená, že oba stále sdílejí název zařízení, trasu nebo pravidlo firewallu, které nikdo neoddělil.

Vraťte zastavený profil a zopakujte stejné kontroly. Když tunel přežije jen první start po restartu, díváte se na vadu životního cyklu, ne na návrh směrování.