Môžu sa klienti na dvoch serveroch OpenVPN navzájom dosiahnuť?

Postavenie druhého OpenVPN servera vám dá druhé miesto, kam sa klienti môžu pripojiť, a nič viac. Nepresúva týchto klientov do siete prvého servera a možnosť s názvom client-to-client mení len preposielanie vnútri jedného procesu servera. Oba pulty sa stanú jednou sieťou, keď medzi nimi zámerne smerujete, s vlastníkom pre každý smer. Všetko nižšie predpokladá režim TUN v používateľskom priestore s vypnutým týmto vnútorným preposielaním, takže rozhoduje jadro.

Mýtus: jeden zoznam účtov, jedna sieť

Autentifikácia a dosiahnuteľnosť sa zamieňajú, pretože obe sídlia v konfigurácii servera. Používateľ, ktorý sa môže prihlásiť na ktorúkoľvek z dvoch brán, vyzerá zvonku ako používateľ jedného systému s dvojimi dverami. Vnútri každý server prideľuje adresy zo svojho pultu a inštaluje trasy len pre klientov, ktorých ukončuje. Takže klient na bráne A, ktorý posiela paket klientovi na bráne B, žiada cieľ, o ktorom jeho vlastný server nikdy nepočul. Paket ide na predvolenú trasu A, opustí tunel a dorazí k firewallu, ktorý nikdy nebol požiadaný, aby ho povolil.

Pridanie druhého servera teda nepridáva redundanciu, objavovanie ani spoločnú broadcastovú doménu. Pridáva smerovanú sieť, ktorá potrebuje plán, a plán začína adresovaním.

Dajte každej bráne vlastný pult a tranzitnú adresu

Dva rozsahy, ktoré sa nesmú prekrývať s ničím iným, plus malé tranzitné prepojenie medzi hosťami, je celý plán adries. Držte tranzit na súkromnom segmente, ktorý kontrolujete, a zapíšte čísla skôr, než ktorýkoľvek server pridelí lease.

Odolajte pokušeniu dať obom serverom rovnaký pult, aby profily zostali rovnaké. Trasa jadra nedokáže povedať, ktorý z dvoch hostov momentálne vlastní ľubovoľnú adresu v zdieľanom rozsahu, takže tabuľka smerovania by ukazovala na jednu bránu a klient môže byť pripojený k druhej. Názvy rozhraní sú lokálne konvencie, nie zdieľaný stav. Oba hosty tu nazývajú tunelové zariadenie tun0 a tranzitné prepojenie transit0, čo je v poriadku, pretože žiadny paket tieto názvy nenesie.

Nainštalujte trasu na oboch stranách

Každá brána potrebuje trasu k pultu druhej cez tranzitnú adresu a preposielanie musí byť zapnuté, aby ktorákoľvek mohla pôsobiť ako hop. Najprv potvrďte aktuálnu tabuľku, potom pridajte záznam a urobte ho trvalým cez správcu siete hosta, nie cez hák opätovného pripojenia.

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

Zrkadlite to na druhom hoste s vymenenými pultmi. Opakované pridávanie tej istej trasy z nesúvisiaceho skriptu je spôsob, akým host skončí s niekoľkými kópiami a záhadnou zmenou, keď niekto nabudúce prečíta tabuľku. Ak je tranzitné prepojenie samo tunelom, trasa ukazuje na topológiu tohto tunela a hop musí prežiť jeho opätovné pripojenie. Tranzitná adresa, ktorá zmizne na tridsať sekúnd, so sebou vezme cestu medzi pultmi, čo je vlastnosť návrhu, ktorú sa oplatí vysloviť, nie objaviť.

Pošlite trasu klienta bez predstierania vlastníctva

Klienti potrebujú trasu k vzdialenému pultu, inak ich vlastný operačný systém pošle paket na predvolenú bránu a tunel ho nikdy neuvidí. Konfigurácia servera je prirodzené miesto, kde ju doručiť.

push "route 10.64.20.0 255.255.255.0"

Vložte zrkadlový riadok do konfigurácie druhého servera, potom znovu pripojte testovacieho klienta a prečítajte jeho tabuľku. Klient, ktorý ignoruje posielané trasy, potrebuje vlastnú schválenú konfiguráciu, a trasa, ktorá nikdy nepríde, nie je riadenie prístupu. Nedávajte klientovi iroute pre celý pult druhej brány. Tá direktíva existuje pre podsieť za jedným pripojeným klientom a jej použitie na prekrytie chýbajúcej trasy medzi bránami vytvára server, ktorý verí, že vlastní adresy, ku ktorým sa nedostane.

Dokážte jednu požiadavku a odmietnite inú

Vyberte skutočnú operáciu, napríklad HTTPS od klienta na 10.64.10.21 k službe na 10.64.20.37, a povoľte presne to na oboch hostoch. Každý firewall prepustí požiadavku na vstupnej strane a sledovanú odpoveď na návratovej strane; politika samotnej cieľovej služby ju musí stále prijať.

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

Pri vzájomných trasách je zdrojový NAT zbytočný a tu aktívne škodlivý: preklad zdroja skrýva, ktorý klient požiadavku poslal, a ničí politiku založenú na zdroji na strane cieľa. Skontrolujte, či existujúce pravidlo masquerade pre výstup do internetu nezachytáva aj túto cestu. Potom otestujte odmietnutie. Služba, ktorá má zostať lokálna v pulte B, musí zostať nedosiahnuteľná z pultu A, a treba otestovať aj dvojice klientov na tej istej bráne, keďže politika preposielania, ktorú ste práve zmenili, platí aj pre nich.

Ešte jedna oprava mentálneho modelu: tranzitné prepojenie prenáša dešifrované vnútorné pakety, takže je hranicou dôvery, nie súkromnou zárukou. Ak prechádza sieťou, ktorú nekontrolujete, chráňte ten hop schváleným šifrovaným tunelom a smerujte cez jeho skutočnú topológiu. End-to-end TLS stále samo autentifikuje aplikáciu, preto by ju vnútorná služba mala naďalej používať.