Server, nebo klient: která jednotka OpenVPN na Pi s dvojí rolí

Na Pi běží dva procesy OpenVPN, které zároveň přijímají roamingové uživatele a dosahují nadřazeného poskytovatele, a kromě hardwaru nesdílejí téměř nic. Jeden naslouchá příchozím tunelům, zatímco druhý vytáčí spojení ven. Každý čte svůj vlastní adresář a každý má svůj vlastní způsob selhání. Restartování toho špatného je nejčastější způsob, jak oprava klienta místo toho rozhodí posluchače.

Slaďte název jednotky s adresářem, který načítá

Upstream 2.6 dodává dvě šablonové jednotky, [email protected] a [email protected]. Šablona serveru startuje v /etc/openvpn/server a odtud načítá %i.conf. Šablona klienta startuje v /etc/openvpn/client. Instance pojmenovaná roaming může existovat na obou místech současně, jako server i jako klient, se dvěma nesouvisejícími konfiguracemi a bez jakéhokoli spojení mezi nimi kromě řetězce.

Ptejte se systemd, ne souborového systému, protože správci balíčků přidávají další soubory, které mohou změnit pracovní adresář nebo argumenty, které binárka dostává.

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

První příkaz vypíše každou vytvořenou jednotku, včetně těch, které selhaly a zůstaly načtené. Druhý vypíše soubor jednotky spolu s jakýmkoli přepsáním. Třetí je nejrychlejší způsob, jak vidět dvě skutečnosti, které rozhodují otázku: adresář, ve kterém proces startuje, a cestu ke konfiguraci, která mu byla předána.

Rozhodujte podle směru paketů, ne podle názvu rozhraní

Instance serveru vlastní naslouchající socket a přijímá spojení. Její šifrovaný transport je lokální vstup a lokální výstup na Pi, zatímco provoz, který přeposílá pro uživatele, sleduje cestu přeposílání a řídí se jinou sadou pravidel. Instance klienta v tomto smyslu žádného posluchače nemá: vytáčí protějšek, takže její šifrovaný transport je lokální výstup směrem k podkladové vrstvě.

Tento rozdíl vám říká, kam pravidlo patří. Pravidlo odpovídající rozhraní uvnitř přeposílacího řetězce pouze povoluje provoz, který směrování už vybralo; nikdy samo cestu nevybírá. Když pakety roamingového uživatele odejdou špatnou cestou, řetězec k prozkoumání je forward, ne output.

Podívejte se na sockety dřív, než začnete teoretizovat. Server navázaný na udp/1194 ukazuje naslouchající socket. Klient ukazuje asociaci s adresou poskytovatele a nic, co by naslouchalo.

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

Výchozí trasa jedné instance může zachytit odpovědi druhé

redirect-gateway protlačený nadřazeným klientem nainstaluje výchozí trasu, která soutěží se vším ostatním na stroji, včetně odpovědí, které server posílá roamingovým uživatelům. OpenVPN si vyhrazuje výjimku pro vlastní adresu protějšku, aby tunel zůstal dostupný, ale tato výjimka nic neříká o telefonu v hotelové síti.

Příznak je obvykle asymetrický. Handshake se dokončí, klient hlásí připojení a provoz po prvním odpovědním paketu umře. Směrování politik založené na zdroji nebo značka paketu nastavená na instanci serveru pomocí --mark drží oba toky oddělené; ani jedno samo o sobě není úplná sada pravidel a obojí potřebuje platné trasy v tabulce, kterou si vybere.

Testujte lokální rozhodnutí, ne stav tunelu, protože jádro vybírá zdroj a rozhraní dřív, než OpenVPN paket uvidí.

ip route get 203.0.113.44
ip rule show

Restartujte jednu roli a dokažte, že druhá přežila

Pořadí je důležité, když obě role závisí na stejné podkladové vrstvě. Restartujte klienta jako první, pokud nadřazená trasa musí existovat dřív, než lze přeposílat uživatelský provoz, a restartujte server jako první, když měníte jen jeho posluchače nebo jeho fond. V každém případě potom potvrďte obě jednotky, protože neúspěšný restart může nechat druhou roli běžet se zastaralým stavem.

Zapište si podmínku zastavení před změnou: zablokuje ztráta nadřazeného tunelu roamingové uživatele, nebo se provoz vrátí na vlastní uplink Pi? DNS a IPv6 také potřebují jasnou odpověď, protože protlačený resolver často přežije trasu, která ho učinila užitečným.

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

Změnu přijměte jen tehdy, když platí tři věci současně: nové příchozí spojení se dokončí, přeposílaná aplikace dosáhne svého cíle zamýšleným východem a oba procesy stále hlásí svůj očekávaný protějšek. Pokud jedna ze tří selže, změnili jste špatnou instanci nebo špatnou trasu a dalším krokem je znovu přečíst jednotku, ne restartovat něco jiného.