Ĉeni du OpenVPN-klientojn sur unu Linux-gastiganto per fwmark

Stakigi duan OpenVPN-klienton sur unu Linux-gastiganto malsukcesas en unu el du lokoj. Aŭ la interna kliento ne povas atingi sian propran servilon ĉar la ekstera tunelo kaptis tiun transporton, aŭ la dua kliento reverkas la vojtablon kaj la unua tunelo ĉesas funkcii. Ambaŭ problemoj estas en vojigo, ne en ĉifrado, kaj ambaŭ solviĝas antaŭ ol la nova tunelo portas ajnan aplikaĵan trafikon. La adresoj ĉi tie estas ilustraj: tun0 estas la ekstera tunelo, 203.0.113.9 estas la interna servilo, kaj TCP 9999 estas la fluo, kiu devas uzi la internan vojon.

Du fiaskmanieroj, unu vojtablo

Interna kliento malfermas UDP-ingon al sia servilo, kaj tiu ingo sekvas la nunan vojtablon kiel ĉiu alia. Se la ekstera tunelo jam posedas la defaŭltan vojon, la manpremaj pakaĵoj eniras la eksteran tunelon. Tio funkcias nur kiam la ekstera servilo povas atingi la internan servilon kaj la alia flanko konsentas porti la fluon; alie la manpremo haltas kaj la kliento reprovas.

La dua fiasko venas de la puŝo de la servilo. La kutima puŝo estas redirect-gateway def1, kiu instalas 0.0.0.0/1 kaj 128.0.0.0/1 anstataŭ anstataŭigi la defaŭltan vojon. Du klientoj, kiuj ĉiu instalas sian propran /1-paron, do kolizias, kaj la plej nova paro venkas por preskaŭ ĉiu celo. Serĉu tiujn du prefiksojn en la tabelo kiam tunelo mortas post kiam la dua konektiĝas, ĉar la defaŭlta vojo mem eble neniam ŝanĝiĝis.

Marku la fluon kaj donu al ĝi tabelon

Direktu la elektitan trafikon markante ĝin en la mangle-tabelo kaj kongruigante la markon en politika regulo. La regulo montras al dediĉita tabelo, kies defaŭlta vojo estas la interna aparato, do nur markitaj pakaĵoj prenas la internan vojon.

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

Plej multaj fiaskoj en ĉi tiu regulsaro venas de du eraroj. La markvaloro, kiun starigas la fajroŝirmilo, kaj la valoro, kiun kongruigas la regulo, devas esti identaj, ĉar malkongruo produktas nek eraron nek efikon. Kaj PREROUTING vidas nur pakaĵojn, kiuj alvenas de ekstere, do konekto komencita sur ĉi tiu gastiganto bezonas OUTPUT-regulon kun la sama kongruo antaŭ ol ĝi entute estos markita.

Forprenu la posedon de la vojoj de la dua kliento

Du opcioj malhelpas la duan klienton redakti la tabelon, kaj ili agas en malsamaj punktoj. route-nopull ignoras la puŝitajn vojopciojn, do nenio instaliĝas. route-noexec akceptas la puŝitajn opciojn en la medion de la kliento sed lasas la tabelŝanĝon al hoko, kio estas ĝuste tio, kion vi volas kiam vi bezonas vidi, kion la servilo proponis.

La hoko ruliĝas kun la puŝitaj valoroj en sia medio, kaj ĝi devus aldoni nur la rikordojn, kiujn vi aprobis. Faru ĝin idempotenta: malplenigu la tabelon, kiun ĝi posedas, antaŭ ol rekonstrui, kaj ne supozu, ke la antaŭa rulo lasis puran staton. Rekonekto denove vokas la hokon, kaj hoko, kiu aldonas sen purigi, amasigos duobligitajn vojojn.

Elektu unu posedanton kaj skribu ĝin. Profilo, kiu starigas ambaŭ opciojn, aŭ hoko, kiu konkurigas kun mana skripto, produktas tabelon, kiun neniu povas klarigi poste.

Fiksu ambaŭ serviladresojn

La interna servilo bezonas gastigantan vojon tra la ekstera aparato antaŭ ol la interna kliento konektiĝas. Tiu rikordo estas tio, kio tenas la internan transporton ene de la ekstera tunelo anstataŭ lasi ĝin sekvi la defaŭltan vojon.

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

Aldonu ankaŭ kongruan gastigantan vojon por la ekstera servilo en la ĉefa tabelo, alie rekonekto povas direkti la propran transporton de la ekstera kliento en ĝian propran tunelon. La ordo ne estas laŭvola: aldonu ĉi tiujn rikordojn post kiam la koncerna interfaco ekzistas, tio signifas hokon aŭ skripton, kiu ruliĝas post la konekto. Vojo montranta al aparato, kiu estas malsupre, estas forigita aŭ ignorita, do rikordo skribita ĉe la starto ne postvivas la sinsekvon, kiun vi supozis.

Kontrolu la serĉon anstataŭ legi la tutan tabelon. La eligo de la voja serĉo nomas la aparaton kaj fontadreson, kiujn la kerno uzos, kio estas ĝuste tio, kion la kliento ricevas kiam ĝi malfermas sian ingon.

Testu la ĉenon kaj igi la fiaskon videbla

Kaptu sur la ekstera interfaco dum la interna kliento konektiĝas. La interna manpremo devus aperi kiel ĉifrita ŝarĝo ene de la ekstera tunelo; se ĝi aperas kiel ordinara UDP al 203.0.113.9, mankas la gastiganta vojo kaj la ĉeno neniam estis konstruita.

Ĉeno, kiu silente refalas al la fizika uplink, estas la plej malbona rezulto, ĉar la stato de la interfaco anoncas nenion kaj la interna trafiko eliras de la malĝusta fontadreso. Se la dua kliento povas rekte rekonekti kiam la ekstera tunelo falas, malŝaltu tiun vojon aŭ ligi ĝin al la ekstera interfaco por ke la fiasko estu videbla.

Finu per du fluoj kaj unu regul-eligo: markita konekto kaj nemarkita devus preni malsamajn vojojn, kaj ip rule show devus listigi la prioritaton, kiun vi intencis. Se ambaŭ fluoj prenas la saman vojon, la marko ne aplikiĝas tie, kie vi pensas.