Treure un sol port del VPN requereix encaminament per política

La petició sempre és una variant de la mateixa frase: mantén el VPN per navegar, però deixa que SSH o una tasca de còpia de seguretat facin servir la connexió normal. El consell que circula per a això, reenviar el port amb regles NAT d'iptables, no ho fa. Una regla NAT reescriu adreces i ports dins d'un flux; mai no tria per quina interfície surt el paquet. Aquesta decisió pertany a la consulta d'encaminament, i la consulta d'encaminament necessita ajuda per veure un port.

Per què una ruta simple no pot coincidir amb un port

Linux tria una ruta consultant l'adreça de destinació en una taula, després de filtrar les taules candidates amb regles de política. Aquestes regles poden coincidir amb una marca de tallafoc, una adreça d'origen, una interfície d'entrada o un UID. L'entrada de ruta no té cap camp de port, perquè la ruta es tria abans que la capçalera de transport importi.

Els iproute2 i els nuclis actuals amplien el selector de regles: ipproto, sport i dport s'accepten, així que ip rule add ipproto tcp dport 22 table 100 expressa la intenció en una línia. Executa ip rule add help a l'amfitrió real per veure si la teva compilació llista dport. Si ho fa, ja has acabat amb una ordre; si no, el camí per marca d'aquí sota és l'equivalent.

De qualsevol manera, la regla només és un punter. La taula 100 encara necessita una ruta, i aquesta és la peça que la gent oblida.

Tres peces, o una

La forma moderna és la regla única de dalt més una ruta a la taula alternativa. La forma clàssica hi afegeix netfilter al mig: marca el paquet i després compara la marca en una regla. Totes dues acaben a la mateixa consulta; es diferencien en on es llegeix el port.

L'enfocament per marca existeix perquè netfilter veu la capçalera de transport i el codi d'encaminament històricament no la veia. Aquest és tot el mecanisme, i explica per què el recurs alternatiu són tres peces que cooperen i no una ordre enginyosa.

Les tres peces en ordre

Primer, marca els fluxos que vols desviar, en una cadena que s'executi prou aviat perquè la marca existeixi abans de la decisió de ruta:

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

Segon, envia els paquets marcats a una taula separada:

ip rule add fwmark 0x1/0x1 table 100

Tercer, dona a aquesta taula una ruta per defecte per l'enllaç físic. Les adreces són il·lustratives; substitueix-les per les teves:

ip route add default via 192.168.1.1 dev wlan0 table 100

Salta't el tercer pas i el paquet marcat no troba cap ruta a la taula 100, així que falla. El símptoma sembla que la regla hagi trencat la xarxa, quan en realitat ha eliminat l'únic camí que li quedava al paquet.

Què el manté funcionant després del primer paquet

Les marques s'apliquen als paquets de sortida. La resposta arriba per la interfície física amb l'adreça que aquell enllaç ha assignat, i la taula principal potser encara prefereix el túnel per a aquesta destinació. Dos mecanismes mantenen coherent el camí de tornada: una regla basada en l'origen per a l'adreça de l'enllaç i el seguiment de connexions que conserva la decisió durant tota la vida del flux. Desar la marca a conntrack i restaurar-la en la resposta és la manera habitual de fer estable una excepció amb estat.

El filtratge de camí invers és l'altre assassí silenciós. Si el nucli valida estrictament el camí de retorn i la resposta arriba per una interfície que la taula principal no triaria, el paquet es descarta sense cap missatge. rp_filter els valors per defecte varien segons la distribució i segons si la interfície s'encamina, així que llegeix el valor efectiu en lloc de suposar que està desactivat.

No marquis el transport propi del túnel. Un túnel WireGuard o UDP OpenVPN no és TCP 22, així que la recepta de dalt és segura, però una excepció escrita com tot excepte la destinació del túnel pot capturar els paquets xifrats i trencar el túnel d'una manera que sembla un bucle d'encaminament.

Comprova-ho en lloc de suposar-ho

Pregunta al nucli quin camí prendria, per a la destinació i per al port, i després executa la transferència real:

ip route get 203.0.113.10
ip rule show
nft list ruleset

Si la marca existeix però els comptadors no es mouen mai, la regla no coincideix. Els comptadors són la diferència entre una configuració que has escrit i una política que el nucli aplica.

Quan aquesta és l'eina equivocada

Les excepcions basades en ports són fràgils per naturalesa. Els serveis canvien de port, HTTP/3 arriba com a UDP 443, i una aplicació pot obrir diversos fluxos de tipus diferents. Si el requisit real és que aquest programa faci servir l'enllaç normal, la capa d'encaminament és el lloc equivocat; un espai de noms de xarxa o un proxy per aplicació encaixen millor.

Si el requisit és que aquesta subxarxa faci servir l'enllaç normal, omet les marques del tot i afegeix una ruta més específica. És més simple, es veu en una sola taula i la propera persona el pot auditar sense llegir un conjunt de regles.

Anota quin dels tres requisits tens realment abans de tocar el tallafoc. El mecanisme de dalt és precís, i la precisió aplicada a la capa equivocada només és una caiguda més llarga.