Aplicación local, regra VPN: por que a túa cadea FORWARD nunca se activa

Engades unha regra para o tráfico VPN na cadea FORWARD, executas a petición desde a mesma máquina Linux e o contador queda a cero. A regra probablemente sexa correcta. O paquete nunca tomou ese camiño, porque unha petición xerada na mesma máquina non a reenvía ela. Percorrer a vida do paquete desde o socket ata o cable explica por que, e onde debería ir a regra no seu lugar.

Descubre onde naceu o paquete

A orde de hooks de Netfilter separa tres casos, e só un deles implica FORWARD:

Unha aplicación local comeza na ruta OUTPUT, porque o núcleo xa estableceu que o paquete se orixina aquí e nunca é candidato a reenvío. Crear un túnel non cambia esa clasificación; o túnel é un dispositivo polo que o paquete pode saír, non unha etapa que converta a saída local en tránsito.

Dous paquetes, unha historia

Unha vez levantado o túnel, o paquete interno da aplicación e o paquete externo cifrado son obxectos distintos. O paquete interno leva o destino e a carga que escolleu a app. O paquete externo leva texto cifrado ao enderezo e ao porto do par, e é o que cruza realmente a interface física.

A túa política afecta un deles, e escoller o equivocado é unha causa habitual de que unha regra pareza non facer nada. Unha regra que coincide co enderezo externo do par ve todos os paquetes do túnel por igual, faga o que faga a aplicación de dentro. Unha regra que coincide cun destino interno ve o tráfico que che importa, e só se activará se ese paquete chega ao hook onde instalaches a regra.

Os espazos de nomes moven a fronteira

Un contedor fai isto máis difícil sen cambiar o principio. A petición da aplicación é saída local dentro do espazo de nomes de rede do contedor. O host recibe ese tráfico nunha interface Ethernet virtual e pode reenvialo, así que unha regra FORWARD no host pode ter sentido aínda que o proceso que xerou a petición nunca tocase a cadea OUTPUT do host.

Antes de escoller un hook, establece onde viven realmente o conxunto de regras e o túnel. Un túnel dentro do contedor, un túnel no host co contedor encamiñado a través del e un túnel nun espazo de nomes separado son tres topoloxías distintas con tres ubicacións de regras distintas. Le as regras dentro do espazo de nomes que posúe o dispositivo, non só no predeterminado.

Pregúntate se necesitas unha marca

Se o obxectivo é enviar un prefixo de destino polo túnel, pode abondar unha ruta para ese prefixo. Comproba primeiro as rutas efectivas, incluído todo o que empuxase o servidor: unha ruta predeterminada redirixida envía moito máis tráfico pola VPN que a política estreita que tiñas en mente, e ningunha cantidade de marcado fará que o resultado coincida coa intención.

A clasificación fai falta cando a decisión depende de algo que unha ruta non pode expresar, como a orixe, o usuario ou o proceso. Para o tráfico recibido, o marcado en PREROUTING funciona. Para o tráfico local, o marcado debe ocorrer nunha etapa de saída que poida desencadear unha nova consulta de ruta despois de establecer a marca. Con nftables iso é unha cadea de tipo route no hook de saída; unha cadea de filtro de saída ordinaria establecerá o valor e deixará a ruta intacta.

Con iptables, o equivalente vive na disposición mangle OUTPUT, e aplicase o mesmo requisito: a decisión de encamiñamento debe revisarse despois de que exista a marca. Despois unha regra de política ten que consumir a marca e apuntar a unha táboa que conteña unha ruta utilizable. Establecer unha marca de conntrack é unha terceira operación, separada; garda un valor no fluxo e non pon por si mesma ese valor no paquete actual para que o lea o encamiñamento.

Verifica a consulta e o contador á vez

nft list ruleset
ip route get 198.51.100.25
ip route get 198.51.100.25 mark 0x1

O enderezo e a marca son ilustrativos, e as dúas consultas de ruta responden preguntas distintas. A segunda pregunta que faría o núcleo se un paquete levase esa marca; non demostra que o teu conxunto de regras asigne algunha. Trátaa como unha proba de hipótese, non como evidencia de que a política funciona.

Despois executa unha petición inocua e observa dúas cousas á vez: o contador do hook que escolliches e a saída que o paquete tomou realmente. Se o contador se move e o paquete sae por outro sitio, a marca ou a táboa están mal. Se non se move ningún, o paquete non chega a ese hook en absoluto, e o espazo de nomes ou a ruta son a seguinte pregunta.

Por último, limita a proba ao que o mecanismo pode expresar. Unha ruta para un enderezo non se converte nunha política permanente para un servizo cuxos enderezos rotan. Decide primeiro o alcance dos paquetes e despois comproba se o deseño de encamiñamento e marcado pode manter ese alcance tras unha reconexión.