Å omgå ein VPN for éin port krev policy-ruting

Førespurnaden er alltid ein variant av den same setninga: hald VPN-en til nettlesing, men lat SSH eller ein tryggleikskopi-jobb bruke den vanlege tilkoplinga. Rådet som går rundt om dette, å videresende porten med iptables NAT-reglar, gjer det ikkje. Ei NAT-regel skriv om adresser og portar inne i ein straum; ho vel aldri kva grensesnitt pakken går ut av. Den avgjerda høyrer til rutingsoppslaget, og rutingsoppslaget treng hjelp for å sjå ein port.

Kvifor ei vanleg rute ikkje kan matche ein port

Linux vel ei rute ved å slå opp mål-adressa i ein tabell, etter at kandidattabellar er filtrerte gjennom policy-reglar. Desse reglane kan matche eit brannmurmerke, ei kjelde-adresse, eit innkommande grensesnitt eller ein UID. Ei ruteoppføring har ikkje noko portfelt sjølv, fordi ruta blir vald før transportoverskrifta spelar noka rolle.

Noverande iproute2 og kjernar vidar ut regelveljaren: ipproto, sport og dport blir godtekne, så ip rule add ipproto tcp dport 22 table 100 uttrykkjer intensjonen på éi linje. Køyr ip rule add help på den faktiske verten for å sjå om bygget ditt listar dport. Viss det gjer det, er du ferdig med éin kommando; viss ikkje, er merkjevegen nedanfor det tilsvarande.

Uansett er regelen berre ein peikar. Tabell 100 treng framleis ei rute, og det er den biten folk gløymer.

Tre bitar, eller éin

Den moderne forma er den eine regelen ovanfor pluss ei rute i den alternative tabellen. Den klassiske forma legg netfilter i midten: merk pakken, og match så merket i ein regel. Begge endar i det same oppslaget; dei skil seg i kvar porten blir lesen.

Merkje-tilnærminga finst fordi netfilter ser transportoverskrifta og rutingkoden historisk ikkje gjorde det. Det er heile mekanismen, og det forklarer kvifor reservevegen er tre samarbeidande bitar i staden for éin smart kommando.

Dei tre bitane i rekkjefølgje

Fyrst, merk straumane du vil leie om, i ein kjede som køyrer tidleg nok til at merket finst før ruteavgjerda:

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, send merkte pakkar til ein separat tabell:

ip rule add fwmark 0x1/0x1 table 100

Til slutt, gje den tabellen ei standardrute gjennom den fysiske lenkja. Adressene er illustrative; byt ut med dine eigne:

ip route add default via 192.168.1.1 dev wlan0 table 100

Hopp over det tredje steget og den merkte pakken finn inga rute i tabell 100, så han feilar. Symtomet ser ut som om regelen braut nettverket, medan han i røynda fjerna den einaste vegen pakken hadde att.

Kva som held det i gang etter den fyrste pakken

Merke gjeld for utgåande pakkar. Svaret kjem inn på det fysiske grensesnittet med adressa som lenkja tildelte, og hovudtabellen kan framleis føretrekkje tunnelen for det målet. To mekanismar held svarvegen konsistent: ein kjeldebasert regel for lenkjeadressa, og connection tracking som held avgjerda gjennom heile straumen. Å lagre merket i conntrack og gjenopprette det på svaret er den vanlege måten å gjere eit stateful unntak stabilt på.

Reverse-path-filtrering er den andre stille drapsmannen. Viss kjernen validerer returvegen strengt og svaret kjem inn på eit grensesnitt som hovudtabellen ikkje ville velje, blir pakken droppa utan melding. rp_filter standardverdiar varierer mellom distribusjonar og med om grensesnittet blir vidaresendt, så les den effektive verdien i staden for å gå ut frå at han er av.

Ikkje merk sjølve transporten til tunnelen. Ein WireGuard- eller UDP OpenVPN-tunnel er ikkje TCP 22, så oppskrifta ovanfor er trygg, men eit unntak skrive som alt utanom tunnelmålet kan fange dei krypterte pakkane og bryte tunnelen på ein måte som liknar ei rutingløkke.

Sjekk det i staden for å gå ut frå det

Spør kjernen kva veg han ville ta, for målet og for porten, og køyr så den verkelege overføringa:

ip route get 203.0.113.10
ip rule show
nft list ruleset

Viss merket finst men teljarane aldri rører seg, matchar ikkje regelen. Teljarar er skilnaden mellom ein konfigurasjon du skreiv og ein policy kjernen brukar.

Når dette er feil verktøy

Portbaserte unntak er skjøre av natur. Tenester flyttar portar, HTTP/3 kjem som UDP 443, og ein applikasjon kan opne fleire straumar av ulike slag. Viss det verkelege kravet er at dette programmet brukar den vanlege lenkja, er rutinglaget feil stad; eit nettverksnammerom eller ein proxy per applikasjon passar betre.

Viss kravet er at dette subnettet brukar den vanlege lenkja, hopp over merka heilt og legg til ei meir spesifikk rute. Det er enklare, det er synleg i ein tabell, og den neste personen kan revidere det utan å lese eit regelverk.

Skriv ned kva av dei tre krava du faktisk har før du rører brannmuren. Mekanismen ovanfor er presis, og presisjon brukt på feil lag er berre eit lengre avbrot.