Skild utgang: VPN-pool på usb0, gateway-trafikk på eth0

Klientar koplar til og autentiserer seg, og deretter går trafikken deira ut over feil oppstraumslenke, fordi den einaste standardruta på maskinen høyrer til gatewayen sjølv. Å byta ut den standardruta ville bryte maskinen sine eigne oppdateringar og administrasjonstilgang, så utvalet må vera smalare enn «all trafikk». Den brukbare forma er ei policy-regel basert på den indre kjeldeadressa til klientpoolen, som peikar på ein andre rutetabell som eig den alternative WAN-linja. Derifrå handlar sjekklista om fullstendigheit og åtferd ved feil, ikkje om sjølve regelen.

Stadfest at kjeldeadressa overlever heilt til rutingsavgjerda

Ei policy-regel som svarar til eit kjeldeområde, blir berre utløyst når pakken framleis ber den kjelda ved oppslagstidspunktet. Vidaresend klienttrafikk gjer det, så lenge ingenting lenger oppe har skrive han om før rutinga. Trafikk som gatewayen sjølv genererer, gjer det ikkje, og det er nettopp difor gatewayen si eiga standardrute kan bli der ho er.

Det er her lokale testar villeder. Ein curl-køyring på gatewayen er ein lokalt generert straum med gatewayen si adresse, så han tek hovudtabellen og provar ingenting om klientbana. Test frå ein tilkopla klient, eller generer trafikk med ei kjelde som faktisk høyrer til poolen.

Byrja med å skrive ned dei verkelege verdiane: prefikset til poolen, tunnelgrensesnittet som ber han, adressa og neste hopp for den andre WAN-linja, og tabellnummeret du har tenkt å bruke. Ryd dei gamle reglane frå kvar tidlegare freistnad før du legg til nye, fordi dupliserte reglar med ulik prioritet gjev feil som verkar tilfeldige.

Bygg ein vald tabell som er fullstendig

Ein tabell er ikkje ei standardrute med ein ven. Han treng nok ruter til at kvart oppslag blir løyst inne i han, inkludert den tilkopla ruta for WAN-subnettet slik at neste hopp er nåbart. For ein pool på 10.77.0.0/24 på tun1, ei WAN-adresse på 203.0.113.20/24 med neste hopp 203.0.113.1, og tabell 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

Regelen ligg på ein prioritet under kvar eksisterande fange-alt-regel, så samsvarande klientar treff tabell 600 først, og alt anna fell gjennom til hovudtabellen. ip-rule-referansen skildrar den ordna oppslagsmodellen og veljarsyntaksen fullt ut.

Tenk så over kva tabellen ikkje inneheld. Eit mål som berre har ei rute i hovudtabellen, til dømes eit administrasjonssubnett som ein når via eth0, blir ikkje funne i tabell 600 og fell ikkje tilbake til hovudtabellen når det først finst ei standardrute der. Viss desse banane betyr noko, legg dei eksplisitt til i den valde tabellen, som vanlegvis er det rette svaret for ein VPN-utgangstabell.

Hald eigen trafikk frå lyttaren utanfor policyen

OpenVPN-lyttaren har si eiga ytre tilkopling, boren over den oppstraumslenka klienten nådde han på. Den trafikken må halde på returvegen han kom med, og ein brei regel som dekkjer den offentlege adressa til tenaren eller heile tunnelgrensesnittet kan dra han inn i den alternative tabellen. Avgrensa regelen til den indre poolen og ingenting anna.

Filtrering av returveg fortener eit blikk av same grunn. Når svar til klientar går ut via usb0 medan førespurnaden kom inn over ei anna lenke, kan ei streng rp_filter-innstilling kaste pakkar som rutingspolicyen reknar som gyldige. Kontroller dei effektive sysctl-verdiane på begge grensesnitt før du konkluderer med at regelen feila.

Rekkjefølgja betyr også noko i høve til alt anna på maskinen. Docker-bruer, ein andre VPN og alle eksisterande reglar frå eit leverandøravtrykk legg til prioritetar, så les heile regellista i staden for å gå ut frå at prioritet 100 står åleine.

Få vidaresending og omsetjing til å stemme med ruta

Ruting vel ei oppstraumslenke; det gjev ikkje løyve til å vidaresende. Kjernen må ha IPv4-vidaresending slått på, og brannmuren må godta retninga frå klient til WAN og returtrafikken. Ein korrekt tabell med ei FORWARD-kjede som droppar straumen, gjev same symptomet som ei manglande rute, og difor blir begge kontrollerte i same gjennomgang.

Viss den andre WAN-linja ikkje vil rute ein privat pool tilbake til deg, omset kjelda på den utgangen. For eit grensesnitt med dynamisk adresse er ein smal masquerade-regel avgrensa til poolen og grensesnittet det vanlege valet:

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

Omfanget betyr meir enn målet her. Ein masquerade-regel som svarar til kvart utgåande grensesnitt, vil også skrive om trafikk som rett går ut via eth0, og det skjuler rutingsfeil i staden for å rette dei. Omsetjinga køyrer etter rutingsavgjerda, så ho kan aldri reparere ein pakke som er send til feil oppstraumslenke.

Tunneloverhead krev også merksemd når banane er ulike. Viss klientane forhandlar ein stor TCP-MSS og den alternative WAN-linja har lågare MTU eller ein tunnel inni seg, stoggar store segment medan små verkar. Å klemme MSS på vidaresendingsbana gjer det til føreseieleg åtferd i staden for ei periodisk henging.

Avgjer kva som skjer når usb0 forsvinn

Ein tom tabell er ikkje ein feillukkande tilstand. Viss den samsvarande ruta forsvinn, held oppslaget fram til neste regel, når hovudtabellen og tek eth0-standarden. Trafikk som skulle ha gått ut via den andre WAN-linja, går stille ut via den første, noko som for ei policy-ruta utrulling vanlegvis er resultatet du ynskjer minst.

Der denne tilbakefallinga er uakseptabel, legg til ei eksplisitt terminal rute i tabell 600, til dømes ein blackhole-standard, eller dropp poolen i brannmuren medan grensesnittet er nede. Kvar av vala er eit vedtak du kan skrive ned; stille er det ikkje.

Varigheit er det siste punktet. Den som eig begge lenkene, anten det er nettverkshandsamaren, eit dispatcher-skript eller livssyklusen til tilkoplinga, må gjenopprette rutene og regelen ved kvar attilkopling utan å leggje til duplikat. Stadfest med ein førespurnad frå ein ekte klient og ein separat førespurnad frå gatewayen, stadfest den observerte utgangen på begge, trekk deretter ut den andre WAN-linja og sjå kva av dei to resultata du designa som faktisk skjer. IPv6 treng sin eigen tabell, regel og omsetjing; IPv4-regelen ovanfor seier ingenting om det.