Povežite dva odjemalca OpenVPN na enem gostitelju Linux s fwmark

Dodajanje drugega odjemalca OpenVPN na enega gostitelja Linux spodleti na enem od dveh mest. Bodisi notranji odjemalec ne doseže svojega strežnika, ker je zunanji tunel prevzel ta promet, bodisi drugi odjemalec prepiše tabelo poti in prvi tunel preneha delovati. Oba problema sta v usmerjanju, ne v šifriranju, in oba se rešita preden novi tunel prenese kakšen aplikacijski promet. Naslovi tukaj so ponazoritveni: tun0 je zunanji tunel, 203.0.113.9 je notranji strežnik, TCP 9999 pa je tok, ki mora uporabiti notranjo pot.

Dva načina odpovedi, ena tabela poti

Notranji odjemalec odpre vtičnico UDP do svojega strežnika in ta vtičnica sledi trenutni tabeli poti kot vsaka druga. Če ima zunanji tunel že privzeto pot, gredo paketi rokovanja v zunanji tunel. To deluje le, ko lahko zunanji strežnik doseže notranjega in druga stran privoli v prenos toka; sicer se rokovanje ustavi in odjemalec poskusi znova.

Druga odpoved pride iz push sporočila strežnika. Običajni push je redirect-gateway def1, ki namesti 0.0.0.0/1 in 128.0.0.0/1, namesto da bi zamenjal privzeto pot. Zato se dva odjemalca, ki vsak namesti svoj par /1, zaletita, in najnovejši par zmaga za skoraj vsak cilj. V tabeli poiščite ta dva predznaka, ko tunel umre po tem, ko se poveže drugi, ker se sama privzeta pot morda nikoli ni spremenila.

Označite tok in mu dajte tabelo

Usmerite izbrani promet tako, da ga označite v tabeli mangle in oznako ujamete v pravilu politike. Pravilo kaže na namensko tabelo, katere privzeta pot je notranja naprava, zato le označeni paketi gredo po notranji poti.

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

Večina odpovedi v tem naboru pravil izhaja iz dveh napak. Vrednost oznake, ki jo nastavi požarni zid, in vrednost, s katero se ujema pravilo, morata biti enaki, ker nesklad ne daje niti napake niti učinka. In PREROUTING vidi le pakete, ki pridejo od zunaj, zato povezava, začeta na tem gostitelju, potrebuje pravilo OUTPUT z enakim ujemanjem, preden je sploh označena.

Odvzemite lastništvo poti drugemu odjemalcu

Dve možnosti preprečita, da bi drugi odjemalec urejal tabelo, in delujeta na različnih mestih. route-nopull prezre poslane možnosti poti, zato se nič ne namesti. route-noexec sprejme poslane možnosti v okolje odjemalca, a spremembo tabele prepusti hooku, in to je tisto, kar želite, ko morate videti, kaj je strežnik ponudil.

Hook teče s poslanimi vrednostmi v svojem okolju in naj doda samo vnose, ki ste jih odobrili. Naredite ga idempotentnega: izpraznite tabelo, ki jo ima v lasti, preden jo obnovite, in ne predpostavljajte, da je prejšnji zagon pustil čisto stanje. Ponovna povezava znova pokliče hook, hook, ki dodaja brez čiščenja, pa kopiči podvojene poti.

Izberite enega lastnika in ga zapišite. Profil, ki nastavi obe možnosti, ali hook, ki tekmuje z ročnim skriptom, ustvari tabelo, ki je pozneje nihče ne zna razložiti.

Pritrdite oba naslova strežnikov

Notranji strežnik potrebuje pot do gostitelja prek zunanje naprave, preden se notranji odjemalec poveže. Ta vnos ohranja notranji promet znotraj zunanjega tunela, namesto da bi mu dovolil slediti privzeti poti.

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

V glavno tabelo dodajte tudi ustrezno pot do gostitelja za zunanji strežnik, sicer lahko ponovna povezava usmeri promet samega zunanjega odjemalca v njegov lastni tunel. Vrstni red ni neobvezen: te vnose dodajte po tem, ko ustrezni vmesnik obstaja, torej hook ali skript, ki se izvede po povezavi. Pot, ki kaže na izklopljeno napravo, se odstrani ali prezre, zato vnos, zapisan ob zagonu, ne preživi zaporedja, ki ste ga predpostavili.

Preverite iskanje, namesto da bi brali celotno tabelo. Izpis iskanja poti navaja napravo in izvorni naslov, ki ju bo uporabil kernel, in to je natanko tisto, kar odjemalec dobi, ko odpre svojo vtičnico.

Preizkusite verigo in naredite odpoved vidno

Zajemajte na zunanjem vmesniku, medtem ko se notranji odjemalec povezuje. Notranje rokovanje se mora prikazati kot šifrirani tovor znotraj zunanjega tunela; če se prikaže kot navaden UDP proti 203.0.113.9, pot do gostitelja manjka in veriga ni bila nikoli zgrajena.

Veriga, ki se tiho vrne na fizični uplink, je najslabši izid, ker stanje vmesnika ničesar ne naznani in notranji promet odide z napačnega izvornega naslova. Če se drugi odjemalec lahko neposredno znova poveže, ko zunanji tunel pade, onemogočite to pot ali jo privežite na zunanji vmesnik, da bo odpoved vidna.

Končajte z dvema tokovoma in enim izpisom pravil: označena in neoznačena povezava naj bi šli po različnih poteh, ip rule show pa naj bi navedel predvideno prednost. Če gresta oba tokova po isti poti, se oznaka ne uporablja tam, kjer mislite.