Kënnen d’Cliente vun zwee OpenVPN-Serveren sech géigesäiteg erreechen?

En zweeten OpenVPN Server opzesetzen gëtt Iech eng zweet Plaz, wou sech Cliente verbannen, a méi net. Et setzt déi Cliente net op d’Netz vum éischte Server, an d’Optioun mam Numm client-to-client ännert just d’Weiderschécken bannent engem eenzegen Serverprozess. Déi zwee Poolen ginn een Netz, wann Dir bewosst tëschent hinnen rout, mat engem Responsabele fir all Richtung. Alles hei drënner geet vum TUN-Modus am Benotzerraum aus, mat där interner Weiderschéckung ausgeschalt, sou datt de Kernel d’Decisioun hëlt.

De Mythos: eng Kontolëscht, een Netz

Authentifikatioun a Erreechbarkeet gi verwiesselt, well béides an der Serverkonfiguratioun lieft. En Benotzer, dee sech op béide Gateways alogge kann, gesäit vun dobaussen aus wéi en Benotzer op engem System mat zwou Dieren. Bannen deelt all Server Adressen aus sengem eegene Pool a setzt just Routen fir d’Cliente, déi en terminéiert. Sou freet e Client um Gateway A, dee e Paket un e Client um Gateway B schéckt, eng Destinatioun, vun där säin eegene Server ni héieren huet. De Paket geet op d’Standardroute vun A, verléisst den Tunnel a kënnt bei enger Firewall un, déi ni gefrot gouf, en duerchzeloossen.

En zweeten Server dobäizesetzen bäimécht also keng Redundanz, keng Entdeckung an engem gemeinsame Broadcast-Domaine. Et bäimécht en geroutten Netz, dat e Plang brauch, an de Plang fänkt mat der Adresséierung un.

Gitt all Gateway säin eegene Pool an eng Transitadress

Zwee Beräicher, déi sech mat näischt anescht iwwerdecke kënnen, plus eng kleng Transitverbindung tëschent den Hosts, dat ass de ganzen Adressplang. Hält den Transit op engem private Segment, dat Dir kontrolléiert, a schreift d’Zuelen op, ier en iergendeen Server eng Lease vergëtt.

Widderstitt der Versuchung, béide Serveren dee selwechte Pool ze ginn, sou datt d’Profiler identesch bleiwen. Eng Kernelroute kann net soen, wéi vun zwee Hosts elo eng arbiträr Adress bannent engem gedeelte Beräich besëtzt, dofir géif d’Routingtabelle op ee Gateway weisen an de Client kéint um aneren hänken. Interface-Nimm sinn lokal Konventiounen, net gedeelte Staat. Béid Hosts hei nennen den Tunnelapparat tun0 an d’Transitverbindung transit0, wat ka gemaach ginn, well kee Paket dës Nimm dréit.

Installéiert d’Route op béide Säiten

All Gateway brauch eng Route fir de Pool vum aneren iwwer d’Transitadress, an d’Weiderschécken muss un sinn, fir datt ee vun hinne kann als Hop handelen. Bestätegt als éischt déi aktuell Tabell, setzt dann den Agang dobäi a maacht en dauerhaft iwwer den Netzwierkmanager vum Host amplaz vun engem Reconnect-Hook.

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

Spillt dat um aneren Host mat vertauschte Poolen. D’selwecht Route widderholl aus engem onofhängege Skript bäizesetzen ass de Wee, wéi en Host e puer Kopien an eng rätselhaft Ännerung kritt, wann ee fir d’nächst Kéier d’Tabell liest. Wann d’Transitverbindung selwer en Tunnel ass, weist d’Route op d’Topologie vun deem Tunnel an den Hop muss säin Reconnect iwwerliewe. Eng Transitadress, déi drësseg Sekonnen verschwënnt, hëlt de Wee tëschent de Poolen mat, wat eng Designeegenschaft ass, déi ee besser deklaréiert wéi entdeckt.

Dréckt d’Clientroute duerch, ouni Eigentum ze fälschen

D’Cliente brauchen eng Route fir de wäite Pool, soss schéckt hiren eegene Betribssystem de Paket op säin Standardgateway an den Tunnel gesäit en ni. D’Serverkonfiguratioun ass déi natierlech Plaz, fir dat ze liwweren.

push "route 10.64.20.0 255.255.255.0"

Setzt d’Spigellinn an d’Konfiguratioun vum aneren Server, verbënnt dann en Testclient nei a liest seng Tabell. E Client, dee gedréckt Route ignoréiert, brauch seng eegen ugeholl Konfiguratioun, an eng Route, déi ni ukommt, ass keng Zougangskontroll. Gitt engem Client keng iroute fir de ganze Pool vum aneren Gateway. Déi Direktiv existéiert fir en Subnet hannert engem verbonnenen Client, an se benotzen, fir eng fehlend Route tëschent de Gateways ze iwwerdecken, produzéiert en Server, deen gleeft, Adressen ze besetzen, déi en net erreech kann.

Beweist eng Ufro a refuséiert eng aner

Wielt eng richteg Operatioun, zum Beispill HTTPS vun engem Client op 10.64.10.21 zu engem Service op 10.64.20.37, a erlaabt genee dat op béide Hosts. All Firewall hëlt d’Ufro op senger agaangener Säit an déi verfollegt Äntwert op der Récksäit un; d’Servicepolitik vun der Destinatioun muss se awer nach akzeptéieren.

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

Mat géigesäitege Route ass Quell-NAT onnéideg an hei aktiv schiedlech: d’Quell ze iwwersetzen verstoppt, wéi e Client d’Ufro gemaach huet, an ënnergrueft quellbaséiert Politik op der Destinatiounssäit. Préift, ob eng bestoend Masquerade-Regel fir den Internetsexit och dëse Wee fänkt. Test dann d’Refus. En Service, dee lokal am Pool B bleiwe soll, muss aus dem Pool A onerreechbar bleiwen, an och Clientkoppelen um selwechte Gateway musse getest ginn, well d’Weiderschéckungspolitik, déi Dir just geännert hutt, och fir si gëllt.

Nach eng Korrektur um mentale Modell: d’Transitverbindung dréit entschlësselte bannenzeg Paketen, also ass et eng Vertrauensgrenz an net eng privat Garantie. Wa se en Netz duerchkräizt, dat Dir net kontrolléiert, schützt deen Hop mat engem ugehollen verschlësselten Tunnel a rout iwwer seng richteg Topologie. End-to-end TLS authentifizéiert d’Applikatioun nach ëmmer selwer, dofir soll de bannenzegen Service et weider benotzen.