Ločen izhod: bazen VPN na usb0, promet prehoda na eth0

Odjemalci se povežejo in overijo, nato pa njihov promet odide po napačni navzgornji povezavi, ker edina privzeta pot na napravi pripada prehodu samemu. Zamenjava te privzete poti bi pokvarila lastne posodobitve naprave in dostop za upravljanje, zato mora biti izbor ožji od »ves promet«. Delujoča oblika je pravilo politike, vezano na notranji izvorni naslov bazena odjemalcev, ki kaže na drugo usmerjevalno tabelo, ki ima alternativni WAN. Od tam naprej kontrolni seznam govori o popolnosti in vedenju ob napaki, ne o pravilu samem.

Potrdite, da izvorni naslov preživi do odločitve o usmerjanju

Pravilo politike, ki se ujema z razponom vira, se sproži le, ko paket ob iskanju še nosi ta vir. Posredovani odjemalski promet to počne, dokler ga nič višje ni prepisalo pred usmerjanjem. Promet, ki ga ustvari prehod sam, tega ne počne, in prav zato lahko njegova lastna privzeta pot ostane tam, kjer je.

Tu lokalni testi zavajajo. curl, zagnan na prehodu, je lokalno ustvarjen tok z naslovom prehoda, zato vzame glavno tabelo in ne dokaže ničesar o poti odjemalca. Testirajte s povezanega odjemalca ali ustvarite promet z virom, ki res pripada bazenu.

Začnite tako, da zapišete resnične vrednosti: predpono bazena, predpono tunelskega vmesnika, ki ga nosi, naslov in naslednji skok drugega WAN ter številko tabele, ki jo nameravate uporabiti. Preden dodate nova pravila, počistite stara pravila iz vsakega prejšnjega poskusa, ker podvojena pravila z različnimi prioritetami povzročajo napake, ki izgledajo naključne.

Zgradite izbrano tabelo, ki je popolna

Tabela ni privzeta pot s prijateljem. Potrebuje dovolj poti, da se vsako iskanje razreši znotraj nje, vključno s povezano potjo za podomrežje WAN, da je naslednji skok dosegljiv. Za bazen 10.77.0.0/24 na tun1, naslov WAN 203.0.113.20/24 z naslednjim skokom 203.0.113.1 in 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

Pravilo stoji na prioriteti pod vsakim obstoječim pravilom, ki ujame vse, zato ujemajoči odjemalci najprej zadenejo tabelo 600, vse ostalo pa pade v glavno tabelo. Referenca ip-rule v celoti opisuje model urejenega iskanja in sintakso selektorja.

Nato pomislite, česa tabela ne vsebuje. Cilj, ki ima pot le v glavni tabeli, na primer podomrežje za upravljanje, dosegljivo prek eth0, ne bo najden v tabeli 600 in se ne bo vrnil v glavno, ko tam obstaja privzeta pot. Če so te poti pomembne, jih izrecno dodajte v izbrano tabelo, kar je običajno pravilen odgovor za tabelo izhoda VPN.

Držite lastni promet poslušalca zunaj politike

Poslušalec OpenVPN ima svojo zunanjo povezavo, nošeno po tisti navzgornji povezavi, po kateri ga je odjemalec dosegel. Ta promet mora ohraniti povratno pot, s katero je prišel, in široko pravilo, ki pokriva javni naslov strežnika ali celoten tunelski vmesnik, ga lahko potegne v alternativno tabelo. Omejite pravilo na notranji bazen in na nič drugega.

Filtriranje povratne poti si zasluži pogled iz istega razloga. Ko odgovori odjemalcem odhajajo prek usb0, medtem ko je zahteva prišla po drugi povezavi, lahko stroga nastavitev rp_filter zavrže pakete, ki jih usmerjevalna politika šteje za veljavne. Preverite veljavne vrednosti sysctl na obeh vmesnikih, preden sklepate, da je pravilo spodletelo.

Vrstni red je pomemben tudi glede na vse drugo na napravi. Docker mostovi, drugi VPN in vsa že obstoječa pravila iz slike ponudnika dodajajo prioritete, zato preberite celoten seznam pravil, namesto da predpostavljate, da je prioriteta 100 sama.

Uskladite posredovanje in prevajanje s potjo

Usmerjanje izbere navzgornjo povezavo; ne daje dovoljenja za posredovanje. Jedro mora imeti omogočeno posredovanje IPv4, požarni zid pa mora sprejeti smer od odjemalca do WAN in povratni promet. Pravilna tabela z verigo FORWARD, ki tok zavrže, daje enak simptom kot manjkajoča pot, zato se oba preverita v istem prehodu.

Če drugi WAN ne bo usmerjal zasebnega bazena nazaj k vam, prevedite vir na tem izhodu. Za vmesnik z dinamičnim naslovom je običajna izbira ozko pravilo masquerade, omejeno na bazen in vmesnik:

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

Tu je obseg pomembnejši od cilja. Pravilo masquerade, ki se ujema s katerim koli izhodnim vmesnikom, bo prepisalo tudi promet, ki pravilno odhaja prek eth0, in to skriva napake usmerjanja, namesto da bi jih odpravilo. Prevajanje se izvaja po odločitvi o usmerjanju, zato nikoli ne more popraviti paketa, poslanega na napačno navzgornjo povezavo.

Tudi stroški tunela zahtevajo pozornost, ko se poti razlikujejo. Če se odjemalci dogovorijo za velik TCP MSS in ima alternativni WAN nižji MTU ali tunel v sebi, se veliki segmenti ustavijo, medtem ko majhni delujejo. Omejevanje MSS na poti posredovanja to spremeni v predvidljivo vedenje namesto občasnega zatikanja.

Odločite, kaj se zgodi, ko usb0 izgine

Prazna tabela ni stanje zaprtja ob napaki. Če ujemajoča pot izgine, se iskanje nadaljuje po naslednjem pravilu, doseže glavno tabelo in vzame privzeto pot eth0. Promet, ki bi moral oditi po drugem WAN, tiho odide po prvem, kar je pri postavitvi z usmerjanjem po politiki običajno rezultat, ki si ga želite najmanj.

Kjer je tak umik nesprejemljiv, dodajte v tabelo 600 izrecno končno pot, na primer privzeto pot blackhole, ali zavrzite bazen v požarnem zidu, dokler je vmesnik izklopljen. Katera koli od obeh je odločitev, ki jo lahko zapišete; molk ni.

Trajnost je zadnja postavka. Kdor ima obe povezavi, naj bo to upravitelj omrežja, skripta pošiljatelja ali življenjski cikel povezave, mora ob vsakem ponovnem povezovanju znova ustvariti poti in pravilo, ne da bi dodajal dvojnike. Preverite z zahtevo pravega odjemalca in ločeno zahtevo s prehoda, potrdite opaženi izhod pri obeh, nato izvlecite drugi WAN in opazujte, kateri od dveh načrtovanih izidov se dejansko zgodi. IPv6 potrebuje svojo tabelo, pravilo in prevajanje; zgornje pravilo IPv4 o tem ne pove ničesar.