Aparta eliro: VPN-baseno sur usb0, enirporda trafiko sur eth0

Klientoj konektiĝas kaj aŭtentikiĝas, poste ilia trafiko eliras per la malĝusta suprenligo, ĉar la sola defaŭlta vojo en la maŝino apartenas al la enirpordo mem. Anstataŭigi tiun defaŭltan vojon rompus la proprajn ĝisdatigojn kaj administran aliron de la maŝino, do la elekto devas esti pli mallarĝa ol «la tuta trafiko». La laborebla formo estas politika regulo bazita sur la interna fontadreso de la klienta baseno, kiu montras al dua enkursiga tabelo posedanta la alternativan WAN. De tie la kontrolisto temas pri kompleteco kaj malsukcesa konduto, ne pri la regulo mem.

Konfirmu, ke la fontadreso postvivas ĝis la enkursiga decido

Politika regulo, kiu kongruas kun fonta gamo, ekagas nur kiam la pako ankoraŭ portas tiun fonton ĉe la serĉmomento. Plusendita klienta trafiko faras tion, kondiĉe ke io pli supre ne reverkis ĝin antaŭ enkursigado. Trafiko generita de la enirpordo ne faras tion, kaj ĝuste tial la propra defaŭlta vojo de la enirpordo povas resti kie ĝi estas.

Ĉi tie lokaj testoj misgvidas. Kuri curl sur la enirpordo estas loke generita fluo kun la adreso de la enirpordo, do ĝi prenas la ĉefan tabelon kaj pruvas nenion pri la klienta vojo. Testu de konektita kliento, aŭ generu trafikon kun fonto, kiu efektive apartenas al la baseno.

Komencu skribante la realajn valorojn: la basena prefikso, la tunela interfaco, kiu portas ĝin, la adreso kaj sekva salteto de la dua WAN, kaj la tabelnumero, kiun vi intencas uzi. Forigu la malnovajn regulojn de iu ajn antaŭa provo antaŭ ol aldoni novajn, ĉar duobligitaj reguloj ĉe malsamaj prioritatoj produktas malsukcesojn, kiuj aspektas hazardaj.

Konstruu elektitan tabelon, kiu estas kompleta

Tabelo ne estas defaŭlta vojo kun amiko. Ĝi bezonas sufiĉe da vojoj, ke ĉiu serĉo solviĝu ene de ĝi, inkluzive la konektitan vojon por la WAN-subreto, por ke la sekva salteto estu atingebla. Por baseno 10.77.0.0/24 sur tun1, WAN-adreso 203.0.113.20/24 kun sekva salteto 203.0.113.1, kaj tabelo 600:

ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600

La regulo sidas ĉe prioritato sub ĉiu ekzistanta ĉion-kapta regulo, do kongruaj klientoj unue trafas tabelon 600 kaj ĉio alia falas al la ĉefa tabelo. La ip-rule-referenco plene priskribas la ordigitan serĉmodelon kaj la selektilan sintakson.

Poste pripensu, kion la tabelo ne enhavas. Celoj, kiuj havas vojon nur en la ĉefa tabelo, ekzemple administra subreto atingebla tra eth0, ne troviĝos en tabelo 600 kaj ne refalos al la ĉefa, post kiam ekzistas defaŭlta vojo tie. Se tiuj vojoj gravas, aldonu ilin eksplicite al la elektita tabelo, kio kutime estas la ĝusta respondo por VPN-elira tabelo.

Tenu la propran trafikon de la aŭskultanto ekster la politiko

La OpenVPN-aŭskultanto havas propran eksteran konekton, portatan per tiu suprenligo, per kiu la kliento atingis ĝin. Tiu trafiko devas konservi la revenan vojon, kun kiu ĝi alvenis, kaj larĝa regulo kovranta la publikan adreson de la servilo aŭ la tutan tunelan interfacon povas treni ĝin en la alternativan tabelon. Limigu la regulon al la interna baseno kaj al nenio alia.

Inversvoja filtrado meritas rigardon pro la sama kialo. Kiam respondoj al klientoj eliras per usb0 dum la peto alvenis per alia ligilo, severa rp_filter-agordo povas forĵeti pakojn, kiujn la enkursiga politiko konsideras validaj. Kontrolu la efektivajn sysctl-valorojn sur ambaŭ interfacoj antaŭ ol konkludi, ke la regulo fiaskis.

Ankaŭ la ordo gravas rilate al ĉio alia en la maŝino. Docker-pontoj, dua VPN, kaj iuj antaŭekzistantaj reguloj el provizanta bildo ĉiuj aldonas prioritatojn, do legu la plenan reguloliston anstataŭ supozi, ke prioritato 100 estas sola.

Akkordigu plusendadon kaj tradukadon kun la vojo

Enkursigado elektas suprenligon; ĝi ne donas permeson plusendi. La kerno devas havi IPv4-plusendadon ŝaltitan, kaj la fajroŝirmilo devas akcepti la direkton de kliento al WAN kaj la revenan trafikon. Ĝusta tabelo kun FORWARD-ĉeno, kiu forĵetas la fluon, produktas la saman simpton kiel mankanta vojo, tial ambaŭ kontroliĝas en la sama trairo.

Se la dua WAN ne enkursigos privatan basenon reen al vi, traduku la fonton ĉe tiu eliro. Por interfaco kun dinamika adreso, la kutima elekto estas mallarĝa masquerade-regulo limigita al la baseno kaj la interfaco:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE

La amplekso gravas pli ol la celo ĉi tie. Masquerade-regulo, kiu kongruas kun iu ajn elira interfaco, ankaŭ reverkos trafikon, kiu ĝuste eliras per eth0, kaj tio kaŝas enkursigajn erarojn anstataŭ ripari ilin. Tradukado ruliĝas post la enkursiga decido, do ĝi neniam povas ripari pakon senditan al la malĝusta suprenligo.

Ankaŭ tunela superŝarĝo bezonas atenton, kiam la vojoj malsamas. Se klientoj interkonsentas grandan TCP-MSS kaj la alternativa WAN havas pli malaltan MTU aŭ tunelon ene, grandaj segmentoj haltas dum malgrandaj funkcias. Kunpremi MSS sur la plusenda vojo igas tion antaŭvidebla konduto anstataŭ intermita ŝtopiĝo.

Decidu, kio okazas, kiam usb0 malaperas

Malplena tabelo ne estas fiask-ferma stato. Se la kongrua vojo malaperas, la serĉo daŭras al la sekva regulo, atingas la ĉefan tabelon kaj prenas la eth0-defaŭlton. Trafiko, kiu devis eliri per la dua WAN, eliras kviete per la unua, kio por politike enkursigita starigo kutime estas la rezulto, kiun vi plej malmulte volas.

Kie tiu refalo estas neakceptebla, aldonu eksplicitan finan vojon en tabelo 600, ekzemple blackhole-defaŭlton, aŭ forĵetu la basenon en la fajroŝirmilo dum la interfaco estas malsupre. Ambaŭ elektoj estas decido, kiun vi povas skribi; silento ne estas.

Daŭreco estas la lasta punkto. Kiu ajn posedas ambaŭ ligilojn, ĉu la retadministranto, ĉu dissendoskripto, ĉu la vivociklo de la konekto, devas rekrei la vojojn kaj la regulon ĉe ĉiu rekonekto sen aldoni duoblaĵojn. Kontrolu per peto de reala kliento kaj aparta peto de la enirpordo, konfirmu la observitan eliron ĉe ambaŭ, poste eltiru la duan WAN kaj rigardu, kiu el la du rezultoj, kiujn vi dizajnis, efektive okazas. IPv6 bezonas sian propran tabelon, regulon kaj tradukon; la supra IPv4-regulo diras nenion pri ĝi.