Server a klient OpenVPN na jednom hoste: prečo klienti vypadávajú

Pridajte klientsky profil k stroju, na ktorom už beží server VPN, a prvou obeťou bude pôvodná služba. Nový tunel sa nemusí vôbec nadviazať, alebo môže nabehnúť, zatiaľ čo existujúci klienti servera potichu prestanú dostávať odpovede. Dve kolízie dávajú oba výsledky: fond tunelov, ktorý sa už používa, a predvolená trasa, ktorú nainštaluje nová klientska polovica a ktorá pokrýva celú tabuľku. Ani jedna nevyprodukuje chybové hlásenie OpenVPN, a preto sa zlyhanie číta ako problém servera.

Jeden stroj, dve roly a dve nezlučiteľné odpovede na to, kam majú odpovede smerovať.

Rovnaký fond, dva servery: kto vyhrá

Každá inštancia servera potrebuje vlastnú tunelovú podsieti. Skopírovanie riadku ako server 10.8.0.0 255.255.255.0 do druhej konfigurácie dá obom inštanciám rovnaký prefix, a výsledkom je buď odmietnutie naštartovať, alebo tichý súboj, v ktorom klienti jedného servera dostávajú adresy, ktoré ten druhý tiež považuje za svoje. Rôzne porty UDP a rôzne názvy zariadení nepomáhajú, pretože ani jedno nezasahuje do adresného priestoru. Zmeňte druhý fond a zmeňte ho všade, kde ho trasy spomínajú.

Vypíšte, čo je aktívne, než začnete upravovať: ip -4 addr show vypíše tunelové zariadenia, ss -lunp vypíše počúvajúce procesy a systemctl list-units pomenuje jednotky. Jediný pohľad na tunelové adresy rozhodne, či sa fondy prekrývajú.

Čo klientsky profil pridáva do tabuľky

Klientska polovica zapisuje trasy hneď po pripojení. redirect-gateway def1 rozdelí predvolenú trasu na 0.0.0.0/1 plus 128.0.0.0/1, obe smerované cez nové zariadenie, spolu s hostiteľskou trasou k vzdialenému serveru, ktorá je zámerne pripnutá k fyzickému rozhraniu. Toto pripnutie existuje preto, aby si tunel udržal cestu pre vlastnú dopravu. Všetko ostatné, vrátane odpovedí, ktoré lokálny server dlhuje svojim klientom, teraz sleduje novú predvolenú trasu a odchádza cez vzdialené spojenie.

Druhá kolízia teda nie je pokazený tunel. Je to funkčný tunel na nesprávnom mieste v tabuľke.

Tri spôsoby, ako roly oddeliť

Najmenej invazívna oprava drží predvolenú trasu mimo klientskeho profilu: route-nopull plus explicitné riadky route pre vzdialené prefixy, takže sa lokálna tabuľka mení len tam, kde ste o to požiadali. Ďalším krokom je pravidlo politiky, ktoré vyjme lokálnu tunelovú podsieti a nechá odpovede lokálnym klientom odchádzať cez rozhranie, ktorým prišli, aj keď existuje predvolená trasa. Najdôkladnejšie je samostatný sieťový namespace pre klientsku rolu, ktorý zdieľanú tabuľku úplne odstráni a vyžaduje údržbu druhého smerovacieho kontextu.

Nech vyberiete akúkoľvek cestu, výnimka musí pomenovať lokálnu tunelovú podsieti, nie LAN. Odpoveď, ktorú lokálny server posiela, má ako cieľ tunelovú adresu, takže výnimka v tvare LAN sa s ňou nikdy nezhoduje.

Ktorá z tých dvoch inštancií je vinná

Zastavte klientsku inštanciu a znova otestujte pôvodných klientov. Okamžité obnovenie znamená smerovanie, nie server. Vráťte klienta a vystopujte jedinú odpoveď pomocou ip route get, ktorému zadáte zdrojovú aj cieľovú adresu, čo ukáže cestu, ktorú by zvolilo jadro, a potom sledujte rozhranie, ktoré pakety skutočne používajú, pomocou tcpdump -ni any port 1194. Stavový súbor servera, zapisovaný každých niekoľko sekúnd cez direktívu status, obsahuje zoznam pripojených klientov a bajtové počítadlá v oboch smeroch.

Čítajte tieto počítadlá proti sebe. Prevádzka, ktorá odíde a nikdy sa nevráti, je odpoveď o smerovaní, nie problém s handshakeom.