Server alebo klient: ktorá jednotka OpenVPN na Pi s dvojitou rolou

Na Pi bežia dva procesy OpenVPN, ktoré zároveň prijímajú roamingových používateľov a dosahujú nadradeného poskytovateľa, a okrem hardvéru nezdieľajú takmer nič. Jeden počúva prichádzajúce tunely, druhý vytáča spojenie von. Každý číta svoj vlastný adresár a každý má svoj vlastný režim zlyhania. Reštartovanie toho nesprávneho je najčastejší spôsob, ako oprava klienta namiesto toho rozhádže poslucháča.

Zlaďte názov jednotky s adresárom, ktorý načítava

Upstream 2.6 dodáva dve šablónové jednotky, [email protected] a [email protected]. Šablóna servera štartuje v /etc/openvpn/server a odtiaľ načítava %i.conf. Šablóna klienta štartuje v /etc/openvpn/client. Inštancia s názvom roaming môže existovať na oboch miestach súčasne, ako server aj ako klient, s dvoma nesúvisiacimi konfiguráciami a bez akéhokoľvek spojenia medzi nimi okrem reťazca.

Pýtajte sa systemd, nie súborového systému, pretože tvorcovia balíkov pridávajú ďalšie súbory, ktoré môžu zmeniť pracovný adresár alebo argumenty, ktoré binárka dostáva.

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

Prvý príkaz vypíše každú vytvorenú jednotku, vrátane tých, ktoré zlyhali a zostali načítané. Druhý vypíše súbor jednotky spolu s akýmkoľvek prepisom. Tretí je najrýchlejší spôsob, ako vidieť dve skutočnosti, ktoré rozhodujú otázku: adresár, v ktorom proces štartuje, a cestu ku konfigurácii, ktorá mu bola odovzdaná.

Rozhodujte podľa smeru paketov, nie podľa názvu rozhrania

Inštancia servera vlastní počúvajúci socket a prijíma spojenia. Jej šifrovaný transport je lokálny vstup a lokálny výstup na Pi, zatiaľ čo prevádzka, ktorú preposiela pre používateľov, sleduje cestu preposielania a riadi sa inou sadou pravidiel. Inštancia klienta v tomto zmysle nemá poslucháča: vytáča partnera, preto je jej šifrovaný transport lokálny výstup smerom k podkladovej vrstve.

Tento rozdiel vám hovorí, kam pravidlo patrí. Pravidlo zodpovedajúce rozhraniu v rámci preposielacej reťaze iba povoľuje prevádzku, ktorú smerovanie už vybralo; nikdy samotnú cestu nevyberá. Keď pakety roamingového používateľa vychádzajú nesprávnou cestou, reťaz, ktorú treba preskúmať, je forward, nie output.

Pozrite sa na sockety predtým, než začnete teoretizovať. Server naviazaný na udp/1194 ukazuje počúvajúci socket. Klient ukazuje asociáciu s adresou poskytovateľa a nič, čo by počúvalo.

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

Predvolená trasa jednej inštancie môže zachytiť odpovede druhej

redirect-gateway pretlačený nadradeným klientom nainštaluje predvolenú trasu, ktorá konkuruje všetkému ostatnému na stroji, vrátane odpovedí, ktoré server posiela roamingovým používateľom. OpenVPN si vyhradzuje výnimku pre vlastnú adresu partnera, aby tunel zostal dostupný, ale táto výnimka nič nehovorí o telefóne v hotelovej sieti.

Príznak je zvyčajne asymetrický. Handshake sa dokončí, klient hlási pripojenie a prevádzka po prvom odpovednom pakete zomrie. Smerovanie politík založené na zdroji alebo značka paketu nastavená na inštancii servera pomocou --mark drží oba toky oddelené; ani jedno samo o sebe nie je úplná sada pravidiel a obe potrebujú platné trasy v tabuľke, ktorú si vyberú.

Testujte lokálne rozhodnutie, nie stav tunela, pretože jadro vyberá zdroj a rozhranie skôr, než OpenVPN paket uvidí.

ip route get 203.0.113.44
ip rule show

Reštartujte jednu rolu a dokážte, že druhá prežila

Poradie je dôležité, keď obe roly závisia od tej istej podkladovej vrstvy. Reštartujte klienta ako prvého, ak nadradená trasa musí existovať predtým, než možno preposielať používateľskú prevádzku, a reštartujte server ako prvý, keď meníte iba jeho poslucháča alebo jeho fond. V každom prípade potom potvrďte obe jednotky, pretože neúspešný reštart môže nechať druhú rolu bežať so zastaraným stavom.

Zapíšte si podmienku zastavenia pred zmenou: zablokuje strata nadradeného tunela roamingových používateľov, alebo sa vráti na vlastný uplink Pi? DNS a IPv6 tiež potrebujú jasnú odpoveď, pretože pretlačený resolver často prežije trasu, ktorá ho urobila užitočným.

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

Zmenu prijmite len vtedy, keď platia tri veci súčasne: nové prichádzajúce spojenie sa dokončí, preposielaná aplikácia dosiahne svoj cieľ zamýšľaným výstupom a oba procesy stále hlásia svojho očakávaného partnera. Ak jedna z troch zlyhá, zmenili ste nesprávnu inštanciu alebo nesprávnu trasu a ďalším krokom je znova prečítať jednotku, nie reštartovať niečo iné.