Dva klienti OpenVPN na jednom hostiteli Linux: kdo vlastní trasu?

Oba profily hlásí připojení a jeden z nich tiše přenáší provoz určený druhému. Dva klienti na jednom hostiteli jsou podporované uspořádání; dva klienti bez vlastníka pro každý prefix ne. Práce je méně o zvednutí druhého tunelu a více o rozhodnutí, který proces si smí nárokovat kterou trasu. Projděte to v pořadí níže a konfigurace vyplyne z odpovědí.

Začněte otázkou, k čemu je druhý tunel

Tři situace vypadají na stavovém řádku stejně a potřebují různá řešení. Rozdělení podle destinací posílá jeden prefix přes kancelářský profil a druhý přes laboratorní, přičemž ani jeden si nenárokuje výchozí trasu. Rozdělení podle aplikací obvykle drží jeden plný tunel a konkrétní provoz směruje pravidly zásad. Přepnutí na záložní režim drží zapnutý přesně jeden tunel najednou, což znamená, že druhý nesmí startovat automaticky.

Zapište případ, než otevřete jakýkoli konfigurační soubor, protože tato odpověď určuje vše po něm.

Nejčastější rozbité uspořádání jsou dva plné tunely, které oba protlačily výchozí trasu, kde vyhraje ten, kdo se připojil poslední, a první předstírá dál. Takový stav vypadá na stavovém řádku záměrně a promrhá den z routovací tabulky. Když případ pojmenujete první, stane se nemožným, ne jen nepravděpodobným.

Podívejte se na pooly dřív než na trasy

Dva servery snadno přidělují adresy z jednoho privátního rozsahu, a když to udělají, klient skončí se dvěma rozhraními v jediném prefixu. Žádnou destinaci pak nelze přiřadit rozhraní podle adresy, protože obě vypadají stejně správně. Přečíslujte jeden pool, místo abyste vymýšleli pravidlo na rozbití remízy.

Zkontrolujte i místní síť, protože domácí nebo kancelářská LAN překrývající rozsah tunelu vytváří stejnou nejednoznačnost z druhé strany. Porovnejte adresy na hostiteli s oběma konfiguracemi serveru, než obviníte klienta. Změna poolu na laboratorním serveru je pětiminutová oprava, zatímco obchvat s routováním podle zásad pro překrývající se prefix je trvalá daň pro každého, kdo konfiguraci později čte. Rozhodněte, co z toho chcete, než zvolíte, kam zasáhnout.

Dvě adresní rodiny znamenají dvě kola této kontroly. Pooly IPv6 kolidují stejně tiše jako IPv4.

Dejte každému profilu vlastníka

Jedna instance na profil, jeden konfigurační soubor na instanci a jedno jméno, které dvojici identifikuje. V balení ve stylu Debian vybírá soubor jméno za znakem @, a proto dva profily sdílející jméno instance nikdy nemohou fungovat oba. Ověřte mapování z nainstalované jednotky, ne z návodu.

systemctl cat [email protected]
ip -4 addr show

Pak rozhodněte, kdo instaluje trasy, což je otázka zásad, ne syntaxe.

Když dva servery protlačí nekompatibilní sady, buď přidejte route-nopull a vypište jen prefixy, které každý profil potřebuje, nebo nechte jednomu jeho výchozí trasu a zbytek směrujte pravidlem zásad. Dva procesy, které oba instalují výchozí trasu, skončí s jediným vítězem a nikdo nedokáže říct proč. Jakmile dva tunely nesou provoz pro různé zdroje, odpověď může vyjít nesprávným z nich, a vzor, který vydrží, je značka spojení obnovená na odpovědích a směrovaná do vlastní tabulky. Omezte značky tak, aby jim vlastní šifrované pakety tunelů nikdy neodpovídaly.

Ověřte každý tunel, pak jeden zastavte

Když jsou oba nahoře, vezměte tři odečty: adresu na každém tunelovém zařízení, trasu k hostiteli, který žije za každým z nich, a cestu, kterou by vzala destinace mimo oba. Obyčejný výpis tras přestane popisovat konečné hledání, jakmile vstoupí do hry pravidla, takže se zeptejte jádra, co by skutečně zvolilo. Pak zastavte jednu instanci a sledujte, co zmizí. Když zastavení první naruší druhou, něco je mezi nimi stále sdílené: trasa, jméno zařízení nebo pravidlo firewallu, které nikdo neoddělil.

ip rule show
ip route get 203.0.113.9

Vraťte zastavený profil a zopakujte stejné kontroly, protože tunel, který po restartu funguje jednou a pak už nikdy, je chyba životního cyklu oblečená do kostýmu routování.

Zapište do nasazovacích poznámek, který profil vlastní který prefix, vedle rozsahů poolů. Dva tunely jsou záměrné uspořádání a další čtenář potřebuje vidět hranici, než se dotkne kteréhokoli profilu. Bez té poznámky hranici znovu objeví ten, kdo bude mít službu, až se sdílený prefix nakonec rozbije.