Dokážou na sebe klienti na dvou serverech OpenVPN vzájemně dosáhnout?

Postavení druhého OpenVPN serveru vám dá druhé místo, kam se klienti mohou připojit, a nic víc. Nepřesune ty klienty do sítě prvního serveru a volba client-to-client mění jen přeposílání uvnitř jednoho procesu serveru. Obě sady se stanou jednou sítí, když mezi nimi záměrně směrujete, s vlastníkem pro každý směr. Vše níže předpokládá režim TUN v uživatelském prostoru s vypnutým tímto vnitřním přeposíláním, takže rozhodnutí dělá jádro.

Mýtus: jeden seznam účtů, jedna síť

Autentizace a dostupnost se pletou, protože obojí žije v konfiguraci serveru. Uživatel, který se může přihlásit k kterékoli ze dvou bran, zvenčí vypadá jako uživatel jednoho systému se dvojími dveřmi. Uvnitř každý server přiděluje adresy ze své sady a instaluje trasy jen pro klienty, které ukončuje. Klient na bráně A, který posílá paket klientovi na bráně B, tak žádá cíl, o němž jeho server nikdy neslyšel. Paket jde na výchozí trasu A, opustí tunel a dorazí k firewallu, který nikdy nebyl požádán, aby ho propustil.

Přidání druhého serveru tedy nepřidává redundanci, objevování ani sdílenou broadcastovou doménu. Přidává směrovanou síť, která potřebuje plán, a plán začíná adresováním.

Dejte každé bráně vlastní sadu a tranzitní adresu

Dva rozsahy, které se nesmí překrývat s ničím jiným, plus malé tranzitní propojení mezi hostiteli – to je celý plán adres. Tranzit držte na soukromém segmentu, který ovládáte, a čísla si zapište, než kterýkoli server vydá pronájem.

Odolejte pokušení dát oběma serverům stejnou sadu, aby profily zůstaly totožné. Trasa v jádru nemůže říct, který ze dvou hostitelů právě vlastní libovolnou adresu ve sdíleném rozsahu, takže směrovací tabulka by ukazovala na jednu bránu a klient by mohl být připojen k druhé. Názvy rozhraní jsou místní konvence, ne sdílený stav. Oba hostitelé zde nazývají tunelové zařízení tun0 a tranzitní propojení transit0, což je v pořádku, protože žádný paket tato jména nenese.

Nainstalujte trasu na obou stranách

Každá brána potřebuje trasu k sadě druhé přes tranzitní adresu a přeposílání musí být zapnuté, aby kterákoli mohla působit jako skok. Nejprve potvrďte aktuální tabulku, pak přidejte záznam a uchovejte ho přes síťového správce hostitele, ne přes háček opětovného připojení.

sysctl net.ipv4.ip_forward
ip route add 10.64.20.0/24 via 172.28.44.2 dev transit0
ip route get 10.64.20.37

Zrcadlově to zopakujte na druhém hostiteli s prohozenými sadami. Opakované přidávání stejné trasy z nesouvisejícího skriptu je způsob, jak hostitel skončí s několika kopiemi a záhadnou změnou, až někdo příště tabulku přečte. Je-li tranzitní propojení samo tunelem, trasa ukazuje na topologii toho tunelu a skok musí přežít jeho opětovné připojení. Tranzitní adresa, která zmizí na třicet sekund, s sebou vezme cestu mezi sadami, což je vlastnost návrhu, kterou stojí za to deklarovat, ne objevovat.

Protlačte trasu klienta bez předstírání vlastnictví

Klienti potřebují trasu k vzdálené sadě, jinak jejich vlastní operační systém pošle paket na výchozí bránu a tunel ho nikdy neuvidí. Konfigurace serveru je přirozené místo, kde to doručit.

push "route 10.64.20.0 255.255.255.0"

Vložte zrcadlový řádek do konfigurace druhého serveru, poté znovu připojte testovacího klienta a přečtěte jeho tabulku. Klient, který ignoruje protlačené trasy, potřebuje vlastní schválenou konfiguraci, a trasa, která nikdy nedorazí, není řízení přístupu. Nedávejte klientovi iroute pro celou sadu druhé brány. Tato direktiva existuje pro podsíť za jedním připojeným klientem a její použití k zakrytí chybějící trasy mezi branami vytváří server, který věří, že vlastní adresy, na které nedosáhne.

Dokažte jeden požadavek a jiný odmítněte

Vyberte skutečnou operaci, například HTTPS z klienta na 10.64.10.21 ke službě na 10.64.20.37, a povolte přesně to na obou hostitelích. Každý firewall přijme požadavek na své vstupní straně a sledovanou odpověď na návratové straně; vlastní zásada služby na cíli ho stále musí přijmout.

iptables -A FORWARD -i tun0 -o transit0 -s 10.64.10.21 -d 10.64.20.37 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i transit0 -o tun0 -d 10.64.10.21 -s 10.64.20.37 -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Při vzájemných trasách je NAT zdroje zbytečný a zde aktivně škodlivý: překlad zdroje skryje, který klient požadavek poslal, a maří zásadu založenou na zdroji na straně cíle. Zkontrolujte, zda stávající pravidlo maskarádování pro výstup do internetu nezachytává i tuto cestu. Pak otestujte odmítnutí. Služba, která má zůstat lokální pro sadu B, musí zůstat nedostupná ze sady A, a dvojice klientů na stejné bráně je také třeba testovat, protože zásada přeposílání, kterou jste právě změnili, platí i pro ně.

Ještě jedna oprava mentálního modelu: tranzitní propojení nese dešifrované vnitřní pakety, takže je hranicí důvěry, ne soukromou zárukou. Pokud prochází sítí, kterou neovládáte, chraňte ten skok schváleným šifrovaným tunelem a směrujte přes jeho skutečnou topologii. End-to-end TLS stále samo ověřuje aplikaci, a proto by vnitřní služba měla dál využívat.