O nome dunha cadea non é un gancho: iptables fronte a nftables

Ambos os cortalumes poden filtrar o tráfico VPN reenviado, e enganchan as regras á ruta do paquete de xeitos distintos. iptables ten cadeas integradas dentro dunha táboa, así que FORWARD existe como punto de gancho con nome. nftables separa o nome dunha cadea do seu tipo, gancho e prioridade, o que significa que unha cadea normal chamada FORWARD non filtra absolutamente nada. Comparar os dous modelos explica por que unha entrada que parece correcta nunha ferramenta non ten efecto na outra.

Unha cadea é un contedor. Que o núcleo a consulte depende da implementación e de como o conxunto de regras a engancha.

Dous modelos, dous enganches distintos

En iptables, a táboa filter trae tres cadeas integradas, INPUT, FORWARD e OUTPUT, e -N crea unha cadea definida polo usuario que só ten efecto cando se salta a ela desde unha delas. O manual de nftables define en cambio cadeas base, que declaran o seu tipo, gancho e prioridade, e cadeas normais, que non o fan. Unha cadea base pode levar calquera nome que se desexe, e unha cadea normal chamada FORWARD non gaña ningunha propiedade pola súa etiqueta. Esa é toda a diferenza, e resulta invisible nun tutorial que só mostra texto de regras.

Os backends de compatibilidade engaden unha segunda razón para non inferir o comportamento do nome dunha orde. A documentación de iptables menciona operacións que difiren baixo iptables-nft, así que trate nftables nativo, iptables-nft e un conxunto de regras antigo como tres sistemas e non como tres grafías dun.

Lea o erro no seu contexto real

Unha táboa ausente, un fallo de permisos, unha función do núcleo non dispoñible e unha cadea con nome ausente son catro achados distintos, e só un trata da cadea. Anote a versión da ferramenta, a familia de enderezos e a táboa solicitadas, o espazo de nomes de rede e o primeiro erro exacto. Despois comprobe que compoñente posúe o conxunto de regras: un servizo de cortalumes ou unha pasarela xestionada por un produto pode xerar as súas propias cadeas e a súa orde. Engadir unha cadea nativa xunto a elas deixa a política xestionada intacta e fai o inventario máis confuso.

O espazo de nomes dun contedor pode conter un conxunto de regras distinto do do anfitrión, así que unha orde executada no contexto equivocado non pode mostrar que cadea viu un paquete reenviado. Elevar privilexios porque unha cadea esperada non era visible non é un diagnóstico.

Os contadores proban alcance, non veredicto

Os contadores de regras dinlle que se acadou unha regra. Non lle din que unha regra posterior permitise a operación, nin proban que se denegasen todas as rutas alternativas. Léaos durante un fluxo autorizado e inofensivo, xunto coa orde das regras e o enganche da cadea, e tráteos como unha observación e non como un veredicto. Un contador distinto de cero nunha regra de descarte significa que o tráfico a acadou; non di nada do tráfico que non o fixo.

O reenvío IP do núcleo é un axuste completamente á parte. Que exista unha cadea non habilita o reenvío, e que falte unha etiqueta coñecida non significa que o reenvío se detivese.

Describa o fluxo que espera protexer

Anote unha solicitude de cliente tras a desencapsulación: a súa orixe, o seu destino, a familia de enderezos e se remata na pasarela ou a atravesa. A entrada do servizo local e o tráfico reenviado obsérvanse en puntos distintos, así que necesitan regras e probas distintas. Para unha VPN con ponte, verifique tamén a ruta da ponte, porque unha cadea a nivel IP non controla automaticamente as tramas Ethernet.

Conserve un acceso de recuperación independente antes de cambiar unha pasarela remota. Logo comprobe o fluxo previsto e as denegacións necesarias baixo o mesmo conxunto de regras. Unha cadea nova e baleira cun nome coñecido non é unha reparación.

A comparación remata nunha pregunta: que gancho chama realmente o núcleo para este paquete? Responda iso e o nome da cadea deixa de importar.