Sacar un só porto da VPN esixe encamiñamento por política

A petición sempre é unha variante da mesma frase: mantén a VPN para navegar, pero deixa que SSH ou unha tarefa de copia de seguridade usen a conexión normal. O consello que circula para isto, reenviar o porto con regras NAT de iptables, non o fai. Unha regra NAT reescribe enderezos e portos dentro dun fluxo; nunca escolle por que interface sae o paquete. Ese decisión pertence á consulta de encamiñamento, e a consulta de encamiñamento necesita axuda para ver un porto.

Por que unha ruta simple non pode coincidir cun porto

Linux escolle unha ruta buscando o enderezo de destino nunha táboa, despois de filtrar as táboas candidatas mediante regras de política. Esas regras poden coincidir cunha marca de devasas, un enderezo de orixe, unha interface de entrada ou un UID. A propia entrada de ruta non ten campo de porto, porque a ruta escóllese antes de que importe a cabeceira de transporte.

Os iproute2 e os núcleos actuais amplían o selector da regra: ipproto, sport e dport acéptanse, así que ip rule add ipproto tcp dport 22 table 100 expresa a intención nunha liña. Executa ip rule add help no host real para ver se a túa compilación lista dport. Se o fai, remataches cun só comando; se non, o camiño por marca de abaixo é o equivalente.

En calquera caso a regra só é un punteiro. A táboa 100 segue necesitando unha ruta, e esa é a peza que a xente esquece.

Tres pezas, ou unha

A forma moderna é a regra única de arriba máis unha ruta na táboa alternativa. A forma clásica engade netfilter no medio: marca o paquete e despois fai coincidir a marca nunha regra. Ambas rematan na mesma consulta; difiren en onde se le o porto.

O enfoque por marca existe porque netfilter ve a cabeceira de transporte e o código de encamiñamento historicamente non a vía. Ese é todo o mecanismo, e explica por que o recurso alternativo son tres pezas que cooperan e non un comando enxeñoso.

As tres pezas en orde

Primeiro, marca os fluxos que queres desviar, nunha cadea que se execute cedo abondo para que a marca exista antes da decisión 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

Segundo, envía os paquetes marcados a unha táboa aparte:

ip rule add fwmark 0x1/0x1 table 100

Terceiro, dálle a esa táboa unha ruta por defecto pola ligazón física. Os enderezos son ilustrativos; substitúeos polos teus:

ip route add default via 192.168.1.1 dev wlan0 table 100

Salta o terceiro paso e o paquete marcado non atopa ruta na táboa 100, así que falla. O síntoma parece que a regra rompeu a rede, cando en realidade eliminou o único camiño que lle quedaba ao paquete.

Que o mantén funcionando despois do primeiro paquete

As marcas aplícanse aos paquetes de saída. A resposta chega pola interface física co enderezo que asignou esa ligazón, e a táboa principal pode seguir preferindo o túnel para ese destino. Dous mecanismos manteñen coherente o camiño de volta: unha regra baseada na orixe para o enderezo da ligazón e o seguimento de conexións, que conserva a decisión durante toda a vida do fluxo. Gardar a marca en conntrack e restaurala na resposta é a forma habitual de facer estable unha excepción con estado.

O filtrado do camiño inverso é o outro asasino silencioso. Se o núcleo valida o camiño de volta de forma estrita e a resposta chega por unha interface que a táboa principal non escollería, o paquete descártase sen mensaxe. rp_filter os valores por defecto varían segundo a distribución e segundo se a interface se reenvía, así que le o valor efectivo en lugar de supoñer que está desactivado.

Non marques o transporte propio do túnel. Un túnel WireGuard ou UDP OpenVPN non é TCP 22, así que a receita de arriba é segura, pero unha excepción escrita como todo excepto o destino do túnel pode capturar os paquetes cifrados e romper o túnel dun xeito que parece un bucle de encamiñamento.

Compróbao en lugar de supoñelo

Pregúntalle ao núcleo que camiño tomaría, para o destino e para o porto, e despois executa a transferencia real:

ip route get 203.0.113.10
ip rule show
nft list ruleset

Se a marca existe pero os contadores nunca se moven, a regra non coincide. Os contadores son a diferenza entre unha configuración que escribiches e unha política que o núcleo aplica.

Cando é esta a ferramenta incorrecta

As excepcións baseadas en portos son fráxiles por natureza. Os servizos cambian de porto, HTTP/3 chega como UDP 443 e unha aplicación pode abrir varios fluxos de distinto tipo. Se o requisito real é que este programa use a ligazón normal, a capa de encamiñamento é o lugar incorrecto; un espazo de nomes de rede ou un proxy por aplicación encaixan mellor.

Se o requisito é que esta subrede use a ligazón normal, omite as marcas por completo e engade unha ruta máis específica. É máis simple, vese nunha soa táboa e a seguinte persoa pode auditalo sen ler un conxunto de regras.

Anota cal dos tres requisitos tes en realidade antes de tocar a devasas. O mecanismo de arriba é preciso, e a precisión aplicada á capa incorrecta só é unha caída máis longa.