Ketting twee OpenVPN-kliënte op een Linux-gasheer met fwmark

Om ’n tweede OpenVPN-kliënt op een Linux-gasheer te stapel, misluk op een van twee plekke. Óf die binneste kliënt kan nie sy eie bediener bereik nie omdat die buitenste tonnel daardie vervoer oorgeneem het, óf die tweede kliënt herskryf die roetetabel en die eerste tonnel hou op werk. Albei probleme lê in roetering, nie in enkripsie nie, en albei word opgelos voordat die nuwe tonnel enige toepassingsverkeer dra. Die adresse hier is illustratief: tun0 is die buitenste tonnel, 203.0.113.9 is die binneste bediener, en TCP 9999 is die vloei wat die binneste pad moet gebruik.

Twee foutmodusse, een roetetabel

’n Binneste kliënt open ’n UDP-sok aan sy bediener, en daardie sok volg die huidige roetetabel soos enige ander. As die buitenste tonnel reeds die verstek besit, gaan die handdrukpakke in die buitenste tonnel in. Dit werk net wanneer die buitenste bediener die binneste bediener kan bereik en die oorkant instem om die vloei te dra; anders staan die handdruk en probeer die kliënt weer.

Die tweede fout kom van die bediener se stoot. Die gewone stoot is redirect-gateway def1, wat 0.0.0.0/1 en 128.0.0.0/1 installeer eerder as om die verstekroete te vervang. Twee kliënte wat elk hul eie /1-paar installeer, bots dus, en die nuutste paar wen vir byna elke bestemming. Soek daardie twee prefikse in die tabel wanneer ’n tonnel sterf nadat die tweede een konnekteer, want die verstekroete self het dalk nooit verander nie.

Merk die vloei en gee dit ’n tabel

Stuur die gekose verkeer deur dit in die mangle-tabel te merk en die merk in ’n beleidsreël te pas. Die reël wys na ’n toegewyde tabel wie se verstekroete die binneste toestel is, sodat net gemerkte pakke die binneste pad neem.

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

Die meeste foute in hierdie reëlstel kom van twee foute. Die merkwaarde wat die firewall stel en die waarde wat die reël pas, moet identies wees, want ’n wanverhouding lewer geen fout en geen effek nie. En PREROUTING sien net pakke wat van buite aankom, so ’n verbinding wat op hierdie gasheer begin het, het ’n OUTPUT-reël met dieselfde passing nodig voordat dit enigsins gemerk word.

Neem roete-eienaarskap van die tweede kliënt weg

Twee opsies keer dat die tweede kliënt die tabel wysig, en hulle tree op verskillende punte op. route-nopull ignoreer die gestote roete-opsies, so niks word geïnstalleer nie. route-noexec aanvaar die gestote opsies in die kliënt se omgewing maar laat die tabelverandering aan ’n haak oor, wat is wat jy wil hê wanneer jy moet sien wat die bediener aangebied het.

Die haak loop met die gestote waardes in sy omgewing, en dit moet net die inskrywings byvoeg wat jy goedgekeur het. Maak dit idempotent: spoel die tabel wat dit besit voordat dit herbou, en moenie aanneem die vorige lopie het ’n skoon toestand gelaat nie. ’n Herverbinding roep die haak weer op, en ’n haak wat byvoeg sonder om te skrap, sal duplikaatroetes opbou.

Kies een eienaar en skryf dit neer. ’n Profiel wat albei opsies stel, of ’n haak wat met ’n handmatige skrip meeding, lewer ’n tabel wat niemand later kan verduidelik nie.

Pen albei bedieneradresse vas

Die binneste bediener het ’n gasheerroete deur die buitenste toestel nodig voordat die binneste kliënt konnekteer. Daardie inskrywing is wat die binneste vervoer binne die buitenste tonnel hou eerder as om dit die verstek te laat volg.

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

Voeg ook ’n pasende gasheerroete vir die buitenste bediener in die hooftabel by, anders kan ’n herverbinding die buitenste kliënt se eie vervoer in sy eie tonnel instuur. Die volgorde is nie opsioneel nie: voeg hierdie inskrywings by nadat die betrokke koppelvlak bestaan, wat ’n haak of ’n skrip beteken wat ná die verbinding loop. ’n Roete wat na ’n toestel wys wat af is, word verwyder of geïgnoreer, so ’n inskrywing wat by die selflaai geskryf is, oorleef nie die volgorde wat jy aanvaar het nie.

Kontroleer die opsoek in plaas van om die hele tabel te lees. Die roete-opsoek-uitset noem die toestel en bronadres wat die kern sal gebruik, wat presies is wat die kliënt kry wanneer dit sy sok oopmaak.

Toets die ketting en maak faling sigbaar

Vang op die buitenste koppelvlak terwyl die binneste kliënt konnekteer. Die binneste handdruk behoort as geënkripteerde vrag binne die buitenste tonnel te verskyn; as dit as gewone UDP na 203.0.113.9 verskyn, ontbreek die gasheerroete en is die ketting nooit gebou nie.

’n Ketting wat stilweg na die fisiese opvoerlyn terugval, is die slegste uitkoms, want die koppelvlaktoestand kondig niks aan nie en die binneste verkeer vertrek van die verkeerde bronadres. As die tweede kliënt direk kan herkonnekteer wanneer die buitenste tonnel val, deaktiveer daardie pad of bind dit aan die buitenste koppelvlak sodat die faling sigbaar is.

Eindig met twee vloeie en een reël-dump: ’n gemerkte verbinding en ’n ongemerkte een behoort verskillende paaie te neem, en ip rule show behoort die voorkeur te lys wat jy bedoel het. As albei vloeie dieselfde pad neem, word die merk nie toegepas waar jy dink nie.