Jedno Pi, dvě instance OpenVPN: co čte která jednotka
Dva démony OpenVPN na jednom Pi čtou různé konfigurační soubory a vycházejí přes různé háčky. Zmapujte každou instanci a potom odděleně otestujte cestu datového zatížení.
Spočítejte procesy OpenVPN dřív, než se dotknete profilu. Pi, které přijímá roamingové uživatele a zároveň se připojuje k nadřazené službě, spouští dva démony a každý z nich čte konfigurační soubor zvolený názvem instance, který jste zadali. Zabalované šablony pak každému démonu předají vlastní pracovní adresář, vlastní soubor stavu běhu a vlastní tunelové zařízení. Když toto rozdělení pokazíte, strávíte večer změnou správného nastavení v souboru, který běžící proces nikdy neotevře.
Každý název instance volí svůj vlastní soubor
V souborech jednotek dodávaných s OpenVPN 2.6 nesou startovní argumenty zástupný symbol instance, který se vyplní textem za znakem @. Šablona serveru běží z konfiguračního adresáře serveru a svůj argument řeší proti %i.conf tam, zatímco šablona klienta dělá totéž z adresáře klienta. Takže [email protected] čte admits.conf v adresáři serveru a [email protected] čte uplink.conf v adresáři klienta a ani jeden z názvů nemá v druhém adresáři žádný význam.
Ověřte mapování přímo na stroji, místo abyste předpokládali, že balíček zachoval výchozí hodnoty z upstreamu. Dodatek distribuce může pracovní adresář nebo konfigurační argument rovnou nahradit.
systemctl cat [email protected]
systemctl cat [email protected]Přečtěte si řádek WorkingDirectory a konfigurační argument v tomto výstupu, protože povolená jednotka je jediná věc, která rozhoduje, který soubor se načte. Dodatek, který přidá --config k ExecStart, přebije šablonu, i když cesta šablony vypadá správně. Ptejte se na cesty fragmentu a dodatku, když chcete vědět, zda je ve hře místní přepis. Pokud se obě role rozřeší na jeden soubor, máte jeden proces, který se snaží být serverem i klientem, a pozdější volba v tomto souboru tiše vyhraje.
Místní přenos a předávaná zátěž zasahují různé háčky
Šifrované spojení serveru s každým roamingovým uživatelem se vytváří na samotném Pi, takže jeho vnější odpovědi vycházejí přes místní výstupní háček. Spojení klienta s jeho nadřazeným protějškem je také místně vytvořený výstup, i když dosahuje vzdálené sítě. Předávaná zátěž je třetí kategorií a jádro ji přiřadí až poté, co už pro paket zvolilo odchozí zařízení.
| Flow | Hook that sees it | What to inspect |
|---|---|---|
| Roaming user handshakes to the server | Local input and local output | Listener socket, bind address, rule admitting the UDP port |
| User payload leaving through the upstream tunnel | Forward | IPv4 forwarding switch, selected route, permission rule, any translation |
| Pi's own connection to the upstream peer | Local output | Underlay route to the provider endpoint, not the tunnel route |
Pravidlo, které v řetězci předávání odpovídá odchozímu rozhraní, může povolit nebo zahodit paket, který směrování už tomuto rozhraní přiřadilo, ale nikdy rozhraní nevybírá. Když jeden host ukončí jeden tunel a zahájí jiný, politika, která posílá uživatelskou zátěž do nadřazeného tunelu, a politika, která chrání vlastní šifrované odpovědi Pi, jsou samostatná rozhodnutí. Náhodou končí na stejné fyzické síťové kartě, a proto se pletou.
Tento rozdíl vysvětluje časté poloviční selhání. Uživatelé se připojí, handshake se dokončí a jejich provoz přesto odchází špatným směrem, protože handshake byl místní a zátěž se předávala a testovalo se jen jedno z toho.
Importovaná trasa může spolknout odpovědi vašim uživatelům
Nastavení zabezpečení klientského profilu rozhoduje, co smí nadřazená strana vstrčit do směrovací tabulky Pi, a široké přesměrování je volba, která z funkčního hostitele s dvojí rolí udělá rozbitý. Pokud vstrčená trasa pokrývá veřejné adresy roamingových uživatelů, odpovědi, které server vůči nim generuje, mohou následovat novou trasu do nadřazeného tunelu místo toho, aby vyšly přes podkladovou síť. Lidé často potvrdí, že tunel k poskytovateli stále funguje, a tím skončí, protože tento provoz je vlastní přeprava tunelu a dál teče, zatímco všechno ostatní se chová špatně.
Politika založená na zdroji nebo značce je způsob, jak držet oba proudy oddělené. Linuxová volba značky v OpenVPN označí vlastní šifrované pakety démona značkou firewallu, kterou pak směrovací pravidlo může poslat do vyhrazené tabulky. Zdrojové adresy fungují stejně dobře, když vnější odpovědi serveru vždy vycházejí z jedné adresy podkladové sítě. Oba přístupy potřebují platné trasy v tabulce, kterou vyberou, a výjimku pro koncový bod poskytovatele, jinak se tunel sám přestane zvedat.
Než napíšete jakékoli pravidlo, zeptejte se jádra, jakou cestu by odpověď skutečně vzala. Adresy níže jsou zástupné pro adresu podkladové sítě Pi a veřejnou adresu jednoho roamingového uživatele.
ip rule show
ip route get 198.51.100.7 from 192.0.2.10Ověřte rozdělení a pak zastavujte role po jedné
Otestujte tři toky odděleně, protože funkční handshake nic nedokazuje o ostatních dvou. Přijměte nové příchozí spojení, pošlete jednu povolenou aplikaci přes nadřazený výstup a potvrďte, že oba procesy stále dosáhnou na své protějšky.
Potom zastavte roli klienta a sledujte, co si role serveru ponechá. To je nejlevnější způsob, jak najít pravidlo trasy nebo značky, které bylo určeno jedné instanci a použilo se na obě.
systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pagerChcete vidět, že posluchač je stále připoután, tunelové zařízení stále existuje a protokol neobsahuje nové chyby, zatímco je role klienta zastavená. Pokud zastavení klienta přeruší i odpovědi serveru stávajícím uživatelům, obě role sdílejí něco, co mělo být omezeno na jednu z nich. Zaznamenejte, které instance, kterého konfiguračního souboru a kterého vlastníka toku se každá změna dotkla, protože další člověk, který bude tohoto hostitele ladit, jinak zopakuje stejný objev od nuly.