Å føre én port utenom VPN krever policy-ruting

Forespørselen er alltid en variant av den samme setningen: behold VPN for nettlesing, men la SSH eller en sikkerhetskopijobb bruke den vanlige forbindelsen. Rådet som sirkulerer om dette, å videresende porten med iptables NAT-regler, gjør det ikke. En NAT-regel skriver om adresser og porter inne i en strøm; den velger aldri hvilket grensesnitt pakken forlater via. Den beslutningen hører til ruteoppslaget, og ruteoppslaget trenger hjelp for å se en port.

Hvorfor en vanlig rute ikke kan matche en port

Linux velger en rute ved å slå opp destinasjonsadressen i en tabell, etter at kandidattabellene er filtrert gjennom policy-regler. Disse reglene kan matche et brannmurmerke, en kildeadresse, et innkommende grensesnitt eller en UID. Selve ruteoppføringen har ikke noe portfelt, fordi ruten velges før transportoverskriften betyr noe.

Dagens iproute2 og kjerner utvider regelvelgeren: ipproto, sport og dport godtas, slik at ip rule add ipproto tcp dport 22 table 100 uttrykker hensikten på én linje. Kjør ip rule add help på den faktiske verten for å se om bygget ditt viser dport. Hvis det gjør det, er du ferdig med én kommando; hvis ikke, er merkestien nedenfor ekvivalenten.

Uansett er regelen bare en peker. Tabell 100 trenger fortsatt en rute, og det er den delen folk glemmer.

Tre deler, eller én

Den moderne formen er den enslige regelen ovenfor pluss en rute i den alternative tabellen. Den klassiske formen legger inn netfilter i midten: merk pakken, og match deretter merket i en regel. Begge ender i samme oppslag; de skiller seg i hvor porten leses.

Merkemetoden finnes fordi netfilter ser transportoverskriften og rutekoden historisk ikke gjorde det. Det er hele mekanismen, og det forklarer hvorfor reserveveien er tre samarbeidende deler og ikke én smart kommando.

De tre delene i rekkefølge

Først merker du strømmene du vil omdirigere, i en kjede som kjører tidlig nok til at merket finnes før rutebeslutningen:

nft add table inet vpnexempt
nft 'add chain inet vpnexempt out { type route hook output priority mangle; }'
nft add rule inet vpnexempt out tcp dport 22 meta mark set 0x1

Deretter sender du merkede pakker til en egen tabell:

ip rule add fwmark 0x1/0x1 table 100

For det tredje gir du den tabellen en standardrute gjennom den fysiske lenken. Adressene er eksempler; sett inn dine egne:

ip route add default via 192.168.1.1 dev wlan0 table 100

Hopp over det tredje trinnet, og den merkede pakken finner ingen rute i tabell 100, så den feiler. Symptomet ser ut som om regelen ødela nettverket, mens den i virkeligheten fjernet den eneste veien pakken hadde igjen.

Hva som holder det i gang etter den første pakken

Merker gjelder utgående pakker. Svaret kommer inn på det fysiske grensesnittet med adressen lenken tildelte, og hovedtabellen kan fortsatt foretrekke tunnelen for den destinasjonen. To mekanismer holder svarveien konsistent: en kildebasert regel for lenkeadressen, og tilkoblingssporing som bevarer beslutningen gjennom hele strømmens levetid. Å lagre merket i conntrack og gjenopprette det på svaret er den vanlige måten å gjøre et tilstandsbasert unntak stabilt på.

Filtrering av omvendt vei er den andre stille morderen. Hvis kjernen validerer returveien strengt og svaret kommer inn på et grensesnitt hovedtabellen ikke ville valgt, blir pakken forkastet uten melding. rp_filter standardverdier varierer etter distribusjon og etter om grensesnittet videresendes, så les den effektive verdien i stedet for å anta at den er av.

Ikke merk tunnelens egen transport. En WireGuard- eller UDP OpenVPN-tunnel er ikke TCP 22, så oppskriften ovenfor er trygg, men et unntak skrevet som alt unntatt tunnelens destinasjon kan fange de krypterte pakkene og bryte tunnelen på en måte som ser ut som en ruteløkke.

Kontroller i stedet for å anta

Spør kjernen hvilken vei den ville ta, for destinasjonen og for porten, og kjør deretter den ekte overføringen:

ip route get 203.0.113.10
ip rule show
nft list ruleset

Hvis merket finnes men tellerne aldri beveger seg, matcher ikke regelen. Tellerne er forskjellen mellom en konfigurasjon du skrev og en policy kjernen anvender.

Når dette er feil verktøy

Portbaserte unntak er skjøre av natur. Tjenester flytter porter, HTTP/3 kommer som UDP 443, og én applikasjon kan åpne flere strømmer av ulike slag. Hvis det egentlige kravet er at dette programmet bruker den vanlige lenken, er rutelaget feil sted; et nettverksnavnerom eller en proxy per applikasjon passer bedre.

Hvis kravet er at dette subnettet bruker den vanlige lenken, hopp helt over merkene og legg til en mer spesifikk rute. Det er enklere, det er synlig i én tabell, og neste person kan revidere det uten å lese et regelsett.

Skriv ned hvilket av de tre kravene du faktisk har, før du rører brannmuren. Mekanismen ovenfor er presis, og presisjon brukt på feil lag er bare lengre nedetid.