Geskeide uitgang: VPN-poel op usb0, poortverkeer op eth0

Kliënte koppel en verifieer, en dan verlaat hul verkeer die verkeerde opvoer, want die enigste standaardroete op die masjien behoort aan die poort self. Om daardie standaard te vervang sou die masjien se eie opdaterings en bestuurstoegang breek, so die seleksie moet smaller wees as “alle verkeer”. Die werkbare vorm is ’n beleidsreël wat op die kliëntpoel se binneste bronadres geskoei is en na ’n tweede roetertabel wys wat die alternatiewe WAN besit. Van daar af gaan die kontrolelys oor volledigheid en foutgedrag, nie oor die reël self nie.

Bevestig dat die bronadres tot by die roeteringsbesluit oorleef

’n Beleidsreël wat op ’n bronreeks pas, werk net wanneer die pakkie daardie bron nog by opsoektyd dra. Geforwardeerde kliëntverkeer doen dit, solank niks stroomop dit voor roetering herskryf het nie. Verkeer wat die poort self genereer, doen dit nie, en dit is juis waarom die poort se eie standaard kan bly waar dit is.

Dit is waar plaaslike toetse mislei. ’n curl-loop op die poort is ’n plaaslik gegenereerde vloei met die poort se adres, so dit neem die hoof-tabel en bewys niks oor die kliëntpad nie. Toets vanaf ’n gekoppelde kliënt, of genereer verkeer met ’n bron wat werklik aan die poel behoort.

Begin deur die werklike waardes neer te skryf: die poelvoorvoegsel, die tonnelkoppelvlak wat dit dra, die tweede WAN se adres en volgende sprong, en die tabelnommer wat jy wil gebruik. Vee die ou reëls van enige vorige poging uit voordat jy nuwes byvoeg, want gedupliseerde reëls teen verskillende prioriteite lewer foute wat willekeurig lyk.

Bou ’n geselekteerde tabel wat volledig is

’n Tabel is nie ’n standaardroete met ’n vriend nie. Dit het genoeg roetes nodig sodat elke opsoek binne-in dit oplos, insluitend die gekoppelde roete vir die WAN-subnet sodat die volgende sprong bereikbaar is. Vir ’n poel van 10.77.0.0/24 op tun1, ’n WAN-adres van 203.0.113.20/24 met volgende sprong 203.0.113.1, en tabel 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

Die reël sit op ’n prioriteit onder enige bestaande vang-alles-reël, so passende kliënte tref tabel 600 eerste en alles anders val deur na die hoof-tabel. Die ip-rule-verwysing beskryf die geordende opsoekmodel en die kieser-sintaksis volledig.

Dink dan aan wat die tabel nie bevat nie. ’n Bestemming wat net ’n roete in hoof het, soos ’n bestuursubnet wat deur eth0 bereikbaar is, sal nie in tabel 600 gevind word nie en sal nie na hoof terugval sodra daar ’n standaard in is nie. As daardie paaie saak maak, voeg hulle eksplisiet by die geselekteerde tabel, wat gewoonlik die regte antwoord vir ’n VPN-uitgangstabel is.

Hou die luisteraar se eie verkeer uit die beleid

Die OpenVPN-luisteraar het sy eie buitenste verbinding, gedra oor watter opvoer die kliënt hom ook al bereik het. Daardie verkeer moet die terugpad behou waarmee dit aangekom het, en ’n breë reël wat die bediener se openbare adres of die hele tonnelkoppelvlak dek, kan dit in die alternatiewe tabel intrek. Beperk die reël tot die binnepoel en niks anders nie.

Omgekeerde-padfiltering verdien om dieselfde rede ’n kyk. Wanneer antwoorde aan kliënte via usb0 uitgaan terwyl die versoek oor ’n ander skakel aangekom het, kan ’n streng rp_filter-instelling pakkies laat val wat die roeteringsbeleid as geldig beskou. Kontroleer die effektiewe sysctl-waardes op beide koppelvlakke voordat jy tot die gevolgtrekking kom dat die reël gefaal het.

Orde maak ook saak teenoor enigiets anders op die masjien. Docker-bruggies, ’n tweede VPN en enige bestaande reëls uit ’n verskaffer-beeld voeg almal prioriteite by, so lees die volledige reëllys eerder as om aan te neem prioriteit 100 is alleen.

Laat forwardering en vertaling met die roete saamstem

Roetering kies ’n opvoer; dit gee nie toestemming om te forward nie. Die kern moet IPv4-forwardering geaktiveer hê, en die vuurmuur moet die kliënt-na-WAN-rigting en die terugverkeer aanvaar. ’n Korrekte tabel met ’n FORWARD-ketting wat die vloei laat val, lewer dieselfde simptoom as ’n ontbrekende roete, en daarom word albei in dieselfde deurloop nagegaan.

As die tweede WAN nie ’n private poel na jou terug sal roeteer nie, vertaal die bron op daardie uitgang. Vir ’n koppelvlak met dinamiese adres is ’n nou masquerade-reël wat tot die poel en die koppelvlak beperk is, die gewone keuse:

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

Omvang maak hier meer saak as die teiken. ’n Masquerade-reël wat enige uitgaande koppelvlak pas, sal ook verkeer herskryf wat korrek via eth0 uitgaan, wat roeteringsfoute wegsteek eerder as om hulle reg te maak. Vertaling loop ná die roeteringsbesluit, so dit kan nooit ’n pakkie herstel wat na die verkeerde opvoer gestuur is nie.

Tonnel-oorhoofde vra ook aandag sodra paaie verskil. As kliënte ’n groot TCP-MSS beding en die alternatiewe WAN ’n laer MTU of ’n tonnel binne-in het, staak groot segmente terwyl klein s’n werk. Om MSS op die forwarderingspad te klem, maak daarvan ’n voorspelbare gedrag eerder as ’n af en toe hang.

Besluit wat gebeur wanneer usb0 verdwyn

’n Leë tabel is nie ’n toestand wat by fout toemaak nie. As die passende roete verdwyn, gaan die opsoek voort na die volgende reël, bereik die hoof-tabel en neem die eth0-standaard. Verkeer wat veronderstel was om via die tweede WAN uit te gaan, gaan stilweg via die eerste uit, wat vir ’n beleidsgeroeteerde ontplooiing gewoonlik die uitkoms is wat jy die minste wil hê.

Waar daardie terugval onaanvaarbaar is, voeg ’n eksplisiete terminale roete in tabel 600 by, soos ’n blackhole-standaard, of laat die poel in die vuurmuur val terwyl die koppelvlak af is. Enige een van die twee is ’n besluit wat jy kan neerskryf; stilte is dit nie.

Volharding is die laaste item. Wie ook al albei skakels besit, of dit die netwerkbestuurder, ’n verspreider-skrip of die verbindingslewensiklus is, moet die roetes en die reël by elke herverbinding herskep sonder om duplikate by te voeg. Verifieer met ’n versoek van ’n werklike kliënt en ’n aparte versoek van die poort, bevestig die waargenome uitgang op albei, trek dan die tweede WAN uit en kyk watter van die twee uitkomste wat jy ontwerp het, werklik gebeur. IPv6 het sy eie tabel, reël en vertaling nodig; die IPv4-reël hierbo sê niks daaroor nie.