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

Klienter kobler til og autentiserer seg, og deretter forlater trafikken deres feil oppstrømslenke, fordi den eneste standardruten på maskinen tilhører gatewayen selv. Å erstatte den standardruten ville bryte maskinens egne oppdateringer og administrasjonstilgang, så utvalget må være smalere enn «all trafikk». Den brukbare formen er en policy-regel basert på den indre kildeadressen til klientpoolen, som peker på en andre rutetabell som eier den alternative WAN-forbindelsen. Derfra handler sjekklisten om fullstendighet og oppførsel ved feil, ikke om selve regelen.

Bekreft at kildeadressen overlever helt til rutingsbeslutningen

En policy-regel som samsvarer med et kildeområde, utløses bare når pakken fortsatt bærer den kilden ved oppslagstidspunktet. Videresendt klienttrafikk gjør det, så lenge ingenting lenger oppe har skrevet den om før rutingen. Trafikk som gatewayen selv genererer, gjør det ikke, og det er nettopp derfor gatewayens egen standardrute kan bli der den er.

Det er her lokale tester villeder. En curl-kjøring på gatewayen er en lokalt generert strøm med gatewayens adresse, så den tar hovedtabellen og beviser ingenting om klientbanen. Test fra en tilkoblet klient, eller generer trafikk med en kilde som faktisk tilhører poolen.

Begynn med å skrive ned de virkelige verdiene: poolens prefiks, tunnelgrensesnittet som bærer den, adressen og neste hopp for den andre WAN-forbindelsen, og tabellnummeret du har tenkt å bruke. Rydd de gamle reglene fra ethvert tidligere forsøk før du legger til nye, fordi dupliserte regler med ulik prioritet gir feil som virker tilfeldige.

Bygg en valgt tabell som er komplett

En tabell er ikke en standardrute med en venn. Den trenger nok ruter til at hvert oppslag løses inne i den, inkludert den tilkoblede ruten for WAN-subnettet slik at neste hopp er nåbart. For en pool på 10.77.0.0/24 på tun1, en 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 ligger på en prioritet under enhver eksisterende fange-alt-regel, så samsvarende klienter treffer tabell 600 først, og alt annet faller gjennom til hovedtabellen. ip-rule-referansen beskriver den ordnede oppslagsmodellen og velgersyntaksen fullt ut.

Tenk så over hva tabellen ikke inneholder. Et mål som bare har en rute i hovedtabellen, for eksempel et administrasjonssubnett som nås via eth0, blir ikke funnet i tabell 600 og faller ikke tilbake til hovedtabellen når det først finnes en standardrute der. Hvis disse banene betyr noe, legg dem eksplisitt til i den valgte tabellen, som vanligvis er det riktige svaret for en VPN-utgangstabell.

Hold lytterens egen trafikk utenfor policyen

OpenVPN-lytteren har sin egen ytre forbindelse, båret over den oppstrømslenken klienten nådde den på. Den trafikken må beholde returveien den kom med, og en bred regel som dekker serverens offentlige adresse eller hele tunnelgrensesnittet kan dra den inn i den alternative tabellen. Begrens regelen til den indre poolen og ingenting annet.

Filtrering av returvei fortjener en titt av samme grunn. Når svar til klienter går ut via usb0 mens forespørselen kom inn over en annen lenke, kan en streng rp_filter-innstilling forkaste pakker som rutingspolicyen anser som gyldige. Kontroller de effektive sysctl-verdiene på begge grensesnittene før du konkluderer med at regelen feilet.

Rekkefølgen betyr også noe i forhold til alt annet på maskinen. Docker-broer, en andre VPN og alle eksisterende regler fra et leverandøravtrykk legger til prioriteter, så les hele regellisten i stedet for å anta at prioritet 100 står alene.

Få videresending og oversettelse til å stemme med ruten

Ruting velger en oppstrømslenke; det gir ikke tillatelse til å videresende. Kjernen må ha IPv4-videresending aktivert, og brannmuren må godta retningen fra klient til WAN og returtrafikken. En korrekt tabell med en FORWARD-kjede som dropper strømmen, gir samme symptom som en manglende rute, og derfor kontrolleres begge i samme gjennomgang.

Hvis den andre WAN-forbindelsen ikke vil rute en privat pool tilbake til deg, oversett kilden på den utgangen. For et grensesnitt med dynamisk adresse er en smal masquerade-regel begrenset til poolen og grensesnittet det vanlige valget:

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

Omfanget betyr mer enn målet her. En masquerade-regel som samsvarer med ethvert utgående grensesnitt, vil også skrive om trafikk som korrekt går ut via eth0, og det skjuler rutingsfeil i stedet for å rette dem. Oversettelsen kjører etter rutingsbeslutningen, så den kan aldri reparere en pakke som er sendt til feil oppstrømslenke.

Tunneloverhead krever også oppmerksomhet når banene er ulike. Hvis klientene forhandler en stor TCP-MSS og den alternative WAN-forbindelsen har lavere MTU eller en tunnel inni seg, stopper store segmenter mens små virker. Å klemme MSS på videresendingsbanen gjør det til forutsigbar oppførsel i stedet for en periodisk henging.

Bestem hva som skjer når usb0 forsvinner

En tom tabell er ikke en feillukkende tilstand. Hvis den samsvarende ruten forsvinner, fortsetter oppslaget til neste regel, når hovedtabellen og tar eth0-standardruten. Trafikk som skulle ha gått ut via den andre WAN-forbindelsen, går stille ut via den første, noe som for en policy-rutet utrulling vanligvis er resultatet du ønsker minst.

Der denne tilbakefallingen er uakseptabel, legg til en eksplisitt terminalrute i tabell 600, for eksempel en blackhole-standardrute, eller dropp poolen i brannmuren mens grensesnittet er nede. Hvert av valgene er en beslutning du kan skrive ned; stillhet er det ikke.

Vedvarenhet er det siste punktet. Den som eier begge lenkene, enten det er nettverksbehandleren, et dispatcher-skript eller tilkoblingens livssyklus, må gjenopprette rutene og regelen ved hver gjentilkobling uten å legge til duplikater. Verifiser med en forespørsel fra en ekte klient og en separat forespørsel fra gatewayen, bekreft den observerte utgangen på begge, trekk deretter ut den andre WAN-forbindelsen og se hvilket av de to resultatene du designet som faktisk skjer. IPv6 trenger sin egen tabell, regel og oversettelse; IPv4-regelen ovenfor sier ingenting om det.