Zwee OpenVPN-Clienten op engem Linux-Host mat fwmark verketten

En zweeten OpenVPN-Client op engem Linux-Host ze stapelen, schléit op enger vun zwou Plazen fehl. Entweder de bannenzege Client kann säin eegene Server net erreechen, well den baussenzege Tunnel deen Transport ageholl huet, oder den zweete Client schreift d'Routentabell ëm an den éischten Tunnel funktionéiert net méi. Béid Problemer leien an der Routing, net an der Verschlësselung, a béid ginn geléist ier den neien Tunnel en Applikatiounstrafic dréit. D'Adressen hei sinn illustrativ: tun0 ass den baussenzege Tunnel, 203.0.113.9 ass de bannenzege Server, an TCP 9999 ass de Flux deen de bannenzege Wee benotze muss.

Zwou Fehlermodalitéiten, eng Routentabell

E bannenzege Client mécht en UDP-Socket op säi Server op, an dee Socket follegt der aktueller Routentabell wéi all aneren. Wann den baussenzegen Tunnel schonn d'Standardroute huet, ginn d'Handshake-Paketen an den baussenzegen Tunnel. Dat funktionéiert just wann de baussenzege Server de bannenzege Server erreeche kann an déi aner Säit averstan ass de Flux ze droen; soss stoppt den Handshake an de Client probéiert nach eng Kéier.

Den zweete Fehler kënnt vum Push vum Server. Den üblechen Push ass redirect-gateway def1, deen 0.0.0.0/1 an 128.0.0.0/1 installéiert amplaz d'Standardroute z'ersetzen. Zwee Clienten déi all säin eegent /1-Puer installéieren, kollidéieren dofir, an dat neist Puer gewënnt fir bal all Destinatioun. Kuckt an der Tabell no deenen zwee Prefixen wann en Tunnel stierft nodeems den zweete sech verbonnen huet, well d'Standardroute selwer vläicht ni geännert huet.

Markéiert de Flux a gitt him eng Tabell

Steiert den ausgewielten Trafic andeems Dir en an der mangle-Tabell markéiert an d'Mark an enger Politikregel entsprécht. D'Regel weist op eng dedizéiert Tabell där hir Standardroute dat bannenzegt Apparat ass, sou datt just markéiert Pakete de bannenzege Wee huelen.

iptables -t mangle -A PREROUTING -p tcp -m multiport --dport 9999 -j MARK --set-mark 0x9999
ip rule add fwmark 0x9999 table 200 pref 1000
ip route add default dev tun1 table 200

Déi meescht Fehler an dësem Regelset komme vun zwee Feeler. De Markwäert deen d'Firewall setzt an de Wäert deen d'Regel entsprécht musse gläich sinn, well en Ënnerscheed weder Feeler nach Effekt gëtt. An PREROUTING gesäit just Paketen déi vu bausse kommen, also brauch eng Verbindung déi op dësem Host ugefaang gouf eng OUTPUT-Regel mat der selwechter Entspriechung ier se iwwerhaapt markéiert gëtt.

Hëlt d'Routeneigentum vum zweete Client ewech

Zwou Optiounen halen den zweete Client dovun of d'Tabell ze änneren, a si wierken op verschiddenen Punkten. route-nopull ignoréiert déi gepushte Routeoptiounen, also gëtt näischt installéiert. route-noexec akzeptéiert déi gepushte Optiounen an der Ëmwelt vum Client, mee léisst d'Tabellännerung engem Hook, an dat ass wat Dir wëllt wann Dir musst gesinn wat de Server ugebueden huet.

Den Hook leeft mat de gepushte Wäerter an senger Ëmwelt, an en soll just d'Entréeë bäisetzen déi Dir guttgeheescht hutt. Maacht en idempotent: eidel d'Tabell déi en huet aus ier Dir se rëm opbaut, an huelt net un datt dee virege Laf en proppere Zoustand hannerlooss huet. Eng Reconnect rufft den Hook rëm un, an en Hook deen derbäisetzt ouni ze eidelen sammelt duebel Routen.

Wielt een Proprietär a schreift en op. E Profil deen zwou Optiounen setzt, oder en Hook dee mat engem manuelle Skript konkurréiert, produzéiert eng Tabell déi kee méi spéit erkläre kann.

Fixéiert béid Serveradressen

De bannenzege Server brauch eng Hostroute iwwer dat baussenzegt Apparat ier de bannenzege Client sech verbënnt. Déi Entrée ass et déi den bannenzege Transport am baussenzege Tunnel hält amplaz en der Standardroute follege ze loossen.

ip route add 203.0.113.9/32 dev tun0
ip route get 203.0.113.9

Setzt och eng entspriechend Hostroute fir de baussenzege Server an der Haapttabell derbäi, soss kann eng Reconnect den Transport vum baussenzege Client selwer an säin eegenen Tunnel router. D'Reiefolleg ass net fakultativ: setzt dës Entréeën derbäi nodeems de relevante Interface existéiert, also en Hook oder e Skript dee no der Verbindung leeft. Eng Route déi op en Apparat weist deen aus ass gëtt ewechgeholl oder ignoréiert, also iwwerlieft eng Entrée déi beim Start geschriwwe gouf déi Reiefolleg déi Dir ugeholl hutt net.

Kuckt d'Ufro un amplaz d'ganz Tabell ze liesen. D'Ausgab vun der Routeufro nennt den Apparat an d'Quelladress déi de Kernel benotze wäert, an dat ass genee dat wat de Client kritt wann en säi Socket opmécht.

Test d'Kette a maacht de Fehler sichtbar

Fanckt um baussenzege Interface wärend de bannenzege Client sech verbënnt. Den bannenzege Handshake soll als verschlësselte Payload am baussenzege Tunnel erschéngen; wann en als einfachen UDP op 203.0.113.9 erschéngt, fehlt d'Hostroute an d'Kette gouf ni gebaut.

Eng Kette déi roueg op den physikaleschen Uplink zréckfällt ass dat schlëmmst Resultat, well den Interface-Zoustand näischt annoncéiert an den bannenzege Trafic vun der falscher Quelladress fortgeet. Wann den zweete Client sech direkt rëm verbinne kann wann den baussenzegen Tunnel fällt, deaktivéiert dee Wee oder bënnt en un den baussenzegen Interface sou datt de Fehler sichtbar ass.

Schléisst mat zwee Flëss an engem Regel-Dump of: eng markéiert Verbindung an eng onmarkéiert sollten verschidde Weeër huelen, an ip rule show sollt d'Prioritéit ophuele déi Dir gemengt hutt. Wann béid Flëss dee selwechte Wee huelen, gëtt d'Mark net ugewannt wou Dir mengt.