Server a klient OpenVPN na jednom hostu: proč klienti odpadávají

Přidejte klientský profil ke stroji, na kterém už běží server VPN, a první obětí bude původní služba. Nový tunel se nemusí vůbec navázat, nebo může naběhnout, zatímco stávající klienti serveru tiše přestanou dostávat odpovědi. Dvě kolize dávají oba výsledky: fond tunelů, který se už používá, a výchozí trasa, kterou nainstaluje nová klientská polovina a která pokrývá celou tabulku. Ani jedna nevyprodukuje chybovou zprávu OpenVPN, a proto se selhání čte jako problém serveru.

Jeden stroj, dvě role a dvě neslučitelné odpovědi na to, kam mají odpovědi směřovat.

Stejný fond, dva servery: kdo vyhraje

Každá instance serveru potřebuje vlastní tunelovou podsíť. Zkopírování řádku jako server 10.8.0.0 255.255.255.0 do druhé konfigurace dá oběma instancím stejný prefix a výsledkem je buď odmítnutí nastartovat, nebo tichý souboj, v němž klienti jednoho serveru dostávají adresy, které ten druhý také považuje za své. Různé porty UDP a různá jména zařízení nepomáhají, protože ani jedno nezasahuje do adresního prostoru. Změňte druhý fond a změňte ho všude, kde ho trasy zmiňují.

Vypište, co je aktivní, než začnete editovat: ip -4 addr show vypíše tunelová zařízení, ss -lunp vypíše naslouchající procesy a systemctl list-units pojmenuje jednotky. Jediný pohled na tunelové adresy rozhodne, zda se fondy srážejí.

Co klientský profil přidává do tabulky

Klientská polovina zapisuje trasy hned po připojení. redirect-gateway def1 rozdělí výchozí trasu na 0.0.0.0/1 plus 128.0.0.0/1, obě směrované přes nové zařízení, společně s hostitelskou trasou ke vzdálenému serveru, která je záměrně připíchnutá k fyzickému rozhraní. Toto připíchnutí existuje proto, aby si tunel udržel cestu pro vlastní transport. Všechno ostatní, včetně odpovědí, které lokální server dluží svým klientům, teď sleduje novou výchozí trasu a odchází přes vzdálené spojení.

Druhá kolize tedy není rozbitý tunel. Je to funkční tunel na špatném místě v tabulce.

Tři způsoby, jak role oddělit

Nejméně invazivní oprava drží výchozí trasu mimo klientský profil: route-nopull plus explicitní řádky route pro vzdálené prefixy, takže se lokální tabulka mění jen tam, kde jste o to požádali. Dalším krokem je pravidlo zásad, které vyjímá lokální tunelovou podsíť a nechá odpovědi lokálním klientům odcházet přes rozhraní, kterým přišly, i když výchozí trasa existuje. Nejdůkladnější je samostatný síťový namespace pro klientskou roli, který sdílenou tabulku úplně odstraní a vyžaduje údržbu druhého směrovacího kontextu.

Ať zvolíte kteroukoli cestu, výjimka musí pojmenovat lokální tunelovou podsíť, nikoli LAN. Odpověď, kterou lokální server posílá, má jako cíl tunelovou adresu, takže výjimka ve tvaru LAN se s ní nikdy neshoduje.

Která z těch dvou instancí je viníkem

Zastavte klientskou instanci a znovu otestujte původní klienty. Okamžité obnovení znamená směrování, ne server. Vraťte klienta a vystopujte jedinou odpověď pomocí ip route get, kterému zadáte zdrojovou i cílovou adresu, což ukáže cestu, kterou by zvolilo jádro, a potom sledujte rozhraní, které pakety skutečně používají, pomocí tcpdump -ni any port 1194. Stavový soubor serveru, zapisovaný každých několik sekund přes direktivu status, obsahuje seznam připojených klientů a bajtové počítadla pro oba směry.

Čtěte tato počítadla proti sobě. Provoz, který odejde a nikdy se nevrátí, je odpověď o směrování, nikoli problém s handshakem.