nftables: inserte la regla de permiso VPN antes del identificador de descarte

Coloque una regla de permiso en la posición equivocada y se comporta como si no hubiera ninguna. En nftables, la elección entre insert y add decide en qué lado de una regla referenciada cae la nueva instrucción, y un identificador nombra la regla en el conjunto de reglas activo, no su número de fila. Si la colocación es incorrecta, el paquete llega primero al descarte.

La comparación siguiente usa un par fijo y un intercambio de oyente exterior. Es deliberadamente estrecha; sustituir una cadena completa es otro cambio con otro perfil de riesgo.

Dos colocaciones, dos resultados distintos

insert coloca una regla antes de la regla referenciada. add la coloca después. Si la regla referenciada es el descarte terminal del flujo, esos dos comandos producen resultados opuestos aunque el texto de la regla sea idéntico.

Omitir una ubicación tiene su propio comportamiento predeterminado, otra razón para no copiar un comando de un foro sin leer a qué está anclado. El ancla es toda la decisión. Anote el lado previsto antes de escribir el comando. insert y add se diferencian en una palabra en el archivo.

La colocación es relativa a una regla de una cadena concreta. Mover la misma instrucción a otra cadena u otra prioridad de hook cambia qué paquetes ve, incluso cuando la sintaxis de la regla parece correcta.

Un identificador identifica una regla, no un número de línea

Un identificador como 42 es un identificador del estado actual del conjunto de reglas. No es la regla cuarenta y dos y no es estable entre hosts, reconstrucciones o un gestor que recarga su configuración.

Localice la cadena y el descarte terminal real antes de elegir el ancla. Luego confirme el identificador en esa regla en el mismo listado que muestra el descarte, para que el número y la regla se lean juntos. Un identificador leído de un listado antiguo puede pertenecer ya a otra regla. Vuelva a leerlo en la sesión que aplicará el cambio.

iptables --version
nft -a list ruleset

La versión de iptables informa qué backend se usa. Un conjunto de reglas iptables-nft y una tabla nativa gestionada de forma independiente pueden coexistir, así que un listado de un solo frontend no es automáticamente la imagen completa del filtrado. Revise ambas vistas antes de elegir una cadena.

Encuentre la cadena y la regla que realmente descarta

Lea el hook de entrada, la prioridad de la cadena y la regla que rechaza este flujo de oyente. Una tabla inet puede portar ambas familias de direcciones, pero una regla individual aún puede coincidir solo con IPv4.

Tome un par aprobado, usando 198.51.100.25 del rango de documentación como ejemplo. Un archivo nativo revisado podría colocar un permiso exterior antes del identificador 42:

insert rule inet filter input handle 42 iifname "eth0" ip saddr 198.51.100.25 udp dport { 500, 4500 } counter accept

Sustituya la familia, la tabla, la cadena, el identificador, la interfaz de entrada y el par tras la inspección. El ejemplo usa la forma de ubicación por identificador documentada para nft 1.0.9, y pertenece a un archivo de entrada; el entrecomillado de llaves es un asunto aparte cuando el comando se escribe de forma interactiva.

Mantenga claro el propietario de la configuración. Un gestor que reconstruye sus reglas puede sobrescribir una edición en tiempo de ejecución, y un script de arranque que codifica un identificador obsoleto fallará o se enganchará a la regla equivocada.

La aceptación tiene alcance, el descarte es terminal

Un veredicto de aceptación termina la evaluación en su ruta actual, pero una cadena base aplicable posterior aún puede descartar el paquete. Un veredicto de descarte es terminal. Por eso un contador de aceptaciones creciente no es prueba de que el flujo haya tenido éxito.

Inspeccione todas las prioridades de hook relevantes en lugar de una cadena aislada. Un paquete puede pasar un filtro de entrada y aun así ser rechazado por el hook de otra tabla a una prioridad distinta. Enumere cada cadena base que pueda ver el flujo.

Esa regla cubre solo el intercambio del oyente exterior. ESP encapsulado en transporte, ESP nativo, pares IPv6 y el tráfico descifrado dentro del túnel necesitan todos políticas propias. No es un cortafuegos completo de VPN de sitio.

Revise el archivo y luego verifique el resultado activo

Ejecute una comprobación de sintaxis y transacción sobre el archivo revisado antes de aplicarlo. El modo de comprobación informa si nft puede analizar y preparar el cambio; no lo aplica ni demuestra que otro hook permita el paquete. El archivo sigue siendo una propuesta hasta que el propietario lo aplique:

nft -c -f reviewed-vpn-rule.nft

Aplíquelo mediante el proceso controlado del propietario y conserve el acceso de recuperación. Si la regla es incorrecta, el descarte que intentaba preceder también puede cortar la ruta que usa para corregirlo.

Tras el cambio, observe un nuevo intento de par permitido y compruebe que las fuentes fuera del par aprobado siguen rechazándose. Mueva la regla duradera al gestor que posea el conjunto de reglas, porque los identificadores en tiempo de ejecución localizan objetos actuales en lugar de identificarlos entre arranques.