Klient OpenVPN zamrzne, když jeho server běží na stejném hostiteli

Dvě instance OpenVPN na jednom hostiteli se přou o stejný lokální port a směrovací tabulku. Zafixujte port, oddělte zařízení a zkontrolujte, která tabulka vyhraje.

Měl jsem laboratorní stroj, který přijímal tunel ze vzdáleného pracoviště a zároveň se vytáčel do sítě dodavatele. Odchozí profil fungoval týdny. Poté, co byl přidán příchozí server, odchozí se připojil a pak během několika sekund přestal přenášet provoz, nebo odmítl nastartovat s chybou, že adresa je již používána. Konfigurační soubory se nezměnily; hostitel prostě získal druhý proces OpenVPN s vlastním názorem na porty a trasy.

Selhání není náhodné a není to problém autentizace. Dva démoni na jednom stroji soutěží o stejný lokální socket a stejnou směrovací tabulku a ten, kdo nastartuje nebo se znovu připojí jako poslední, obvykle vyhraje. Znalost toho, kterou z těchto dvou kolizí máte, rozhoduje o tom, kam se podívat nejdřív.

Čtěte symptom pozpátku

Začněte tím, kdy tunel umírá. Chyba bind při startu ukazuje na naslouchající stranu: něco už ten port vlastní a OpenVPN odmítne nastartovat, místo aby se o něj podělil. Tunel, který naskočí a pak ztichne, ukazuje na směrování, protože trasu instalovanou druhou instancí může stáhnout pakety vnějšího spojení z jejich cesty.

Oba případy vytvářejí stejnou stížnost uživatele, a proto opakované smyčky a watchdog skripty nic neopraví. Připojují klienta znovu do stejného konfliktu. Užitečná první otázka je, zda proces při zastavení provozu stále běží.

Jeden socket a jedno zařízení na instanci

Naslouchající server váže svůj port; odchozí klient také potřebuje lokální port pro svůj zapouzdřený provoz. Když oba žijí na stejném hostiteli, výchozí chování klienta může kolidovat s portem serveru. Lokální port klienta lze zafixovat a vázání lze přeskočit tam, kde protějšek nepotřebuje pevný zdrojový port:

lport 1195
nobind
dev tun1

Ta čísla jsou příklady, ne požadavek. Důležité je, že klient přestane soutěžit o port serveru a že každá instance dostane samostatné tunelové zařízení. Dva démoni sdílející tun0 si navzájem přepisují stav zařízení, i když se jejich porty liší, takže jedno zařízení na tunel není volitelné.

nobind patří klientské straně. Server stále musí vázat a naslouchat, takže řádek nekopírujte do konfigurace serveru a nevypínejte vázání na klientovi, jehož protějšek filtruje podle pevného zdrojového portu.

Zvolte jednoho vlastníka výchozí trasy

Výchozí trasu může nainstalovat jen jedno připojení. Pokud oba profily přesměrovávají veškerý provoz, druhé připojení tiše nahradí první a první vypadá jako rozbité. Buď ponechte odchozí tunel rozdělený a posílejte jen prefixy dodavatele, nebo mu dejte samostatnou směrovací tabulku.

ip rule add from 10.9.0.2 table 120
ip route add default dev tun1 table 120
ip route get 10.9.0.2

Adresy a číslo tabulky výše jsou zástupné. Ihned po přidání pravidla ověřte, že se vlastní adresa VPN serveru stále překládá přes normální tabulku; tabulka, která zachytí vnější transport, rozbije tunel, který měla chránit, a následná smyčka opětovného připojení vypadá jako nespolehlivý poskytovatel.

Pro nastavení, které musí přežít opětovná připojení a restartování, je síťový namespace pevnější hranicí. Druhý klient běží ve svém vlastním namespace s vlastními rozhraními a trasami a vystaveny jsou jen služby, které musí hranici překročit. Hostitel si drží jednu výchozí trasu a opětovné připojení namespace ji nemůže přepsat.

Ověřujte tabulkou, ne stavovým řádkem

Klient, který hlásí připojení, dokazuje jen svůj řídicí kanál. Zachyťte stav směrování před a po každém připojení a potom se zeptejte jádra, které zařízení by použila skutečná destinace:

ip route show
ip route get 10.40.0.20
ss -lunp | grep 1194

Pokud se zvolené zařízení pro adresu dodavatele změní při startu druhého tunelu, máte kolizi tras. Pokud se oba procesy objeví na stejném lokálním portu, máte kolizi socketů. Oprava prvního bez druhého jen přesune selhání k dalšímu opětovnému připojení.

Zapište porty, zařízení, tabulky a vlastníka trasy do runbooku hostitele. Jinak další člověk, který přidá třetí tunel, znovu objeví stejnou kolizi a jediným viditelným důkazem bude spojení, které funguje, dokud se nerestartuje démon někoho jiného.

Související články