El cambio de regla del firewall no funciona: orden de las reglas y estado de la conexión

Editó la regla, recargó el conjunto de reglas y el túnel se comporta exactamente como antes. Ese resultado tiene dos causas habituales, y necesitan pruebas distintas. O la regla nueva queda después de una regla anterior que ya aceptó el paquete, o el intercambio que observa es una conexión rastreada que el cambio nunca vuelve a evaluar. Una regla en un archivo expresa intención; lo que decide el paquete es la ruta activa con la que se encuentra. Recorra las comprobaciones siguientes en orden y mantenga una vía de vuelta mientras lo hace.

El orden de las reglas y el estado de la conexión son fallos distintos

Las cadenas ordenadas se evalúan de arriba abajo, y la primera regla que llega a un veredicto final termina el recorrido por esa cadena. Inserte una aceptación amplia por encima de una regla de bloqueo escrita con cuidado y la regla de bloqueo se convierte en documentación: está en el conjunto de reglas, su contador es cero y ningún paquete llegará nunca a ella. El mismo texto aplicado a otra cadena tampoco demuestra nada. En nftables, las cadenas base se enganchan a hooks con prioridades, así que una aceptación en una cadena no impide que otra cadena en un hook o una prioridad distintos vean el mismo paquete.

El seguimiento de conexiones produce el segundo síntoma, y desde fuera se ve idéntico. Una vez que un flujo está en la tabla de estados, una aceptación para establecido-o-relacionado cerca de la cabecera de la cadena retorna antes de que se consulte su regla nueva. Las traducciones NAT tienen la misma propiedad: la traducción quedó fijada cuando empezó el flujo, así que una regla de postrouting editada no reescribe una sesión que ya está en marcha. Por eso un cambio parece funcionar a las 09:00 para una conexión nueva y parece no hacer nada para la sesión que alguien abrió a las 08:55.

Los grupos de seguridad de la nube añaden un tercer modelo que atrapa a quienes aprendieron con iptables. Sus reglas de entrada son una lista de permitidos que se evalúa como un conjunto en lugar de un recorrido por primera coincidencia, son con estado, y quitar una regla de permiso no termina flujos que ya se rastrean. Suponer semántica de primera coincidencia en una plataforma que no la tiene lleva a conclusiones seguras y equivocadas.

Lea el conjunto de reglas activo, no el archivo que editó

Empiece por lo que el núcleo está aplicando ahora mismo. Una configuración guardada que nunca se aplicó explica una cantidad sorprendente de comportamientos sin cambios, y descartarlo cuesta un solo comando:

nft list ruleset
iptables-save

Luego pregunte si su regla llega a alcanzarse siquiera. Los contadores de paquetes responden a eso directamente, y responden mejor que cualquier razonamiento sobre la intención:

iptables -L FORWARD -v -n --line-numbers
nft list chain inet filter forward

Una regla de bloqueo con cero paquetes tras un intento de prueba real no es un problema de política, es un problema de posición. Moverla es un cambio de una línea, y la sintaxis es exactamente lo que causó el error original. Con iptables, -I inserta y -A añade al final; con nftables, insert coloca una regla al principio de la cadena mientras que add añade al final. Cuando una regla debe ganar, dígalo explícitamente en lugar de confiar en el orden que se cargó por casualidad.

Demuestre si el flujo está rastreado

Antes de culpar a la regla, compruebe si el tráfico es siquiera una conexión rastreada. Pregunte a la tabla de estados por el flujo concreto en lugar de volcarla entera:

conntrack -L -p tcp --dport 1194
conntrack -E -p tcp --dport 1194

El listado muestra el estado y el tiempo de espera restante, y así es como distingue una sesión establecida de un intento nuevo; el modo de eventos imprime las actualizaciones a medida que ocurren, lo que resulta útil mientras reconecta un cliente. Si el flujo está presente con estado establecido antes de que usted tocara nada, ninguna edición de las reglas de filtrado cambiará su destino. Eso no es un fallo del firewall, es el contrato del filtrado con estado.

Resista el atajo de vaciar toda la tabla en una puerta de enlace de producción. conntrack -F está disponible, y también destruye cada flujo rastreado de la máquina, incluida la sesión de gestión desde la que trabaja y el túnel que transporta su shell. Las entradas individuales se pueden borrar cuando de verdad lo necesita, pero un flujo nuevo desde un puerto de origen nuevo suele ser un experimento más limpio.

Algunas rutas no se rastrean, y se comportan al revés. El tráfico marcado como notrack en la tabla raw, algunos túneles que evitan los hooks normales y el enrutamiento asimétrico que reparte un flujo entre dos puertas de enlace producen todos paquetes evaluados uno a uno, o un estado que nunca se crea en ambos extremos. Si los contadores se mueven con cada paquete, sospeche de ese tipo de ruta antes de sospechar del orden.

Pruebe desde un flujo nuevo con una vía de vuelta

Antes de probar una regla que podría cortar el acceso remoto, establezca una vía de recuperación: la consola del proveedor, una consola serie, una dirección de gestión fuera de banda o una segunda interfaz que la regla no pueda coincidir. Un temporizador de reversión es un compañero razonable, ya que restaurará el conjunto de reglas anterior aunque su sesión muera a mitad de la prueba.

Después pruebe con un intercambio que el estado no pudiera haber cubierto ya. Desconecte y reconecte el cliente para que se cree una quíntupla nueva, y observe ambos extremos mientras ocurre:

tcpdump -ni eth0 'tcp port 1194'
journalctl -k -n 50 --no-pager

Ejecute la prueba en ambos sentidos. Una regla que bloquea el nuevo handshake de entrada todavía puede permitir la ruta de respuesta, o al revés, y un resultado unidireccional es la razón habitual de que un bloqueo funcione a medias. Reconecte una vez después de la prueba para confirmar el estado estacionario, y compruebe que el acceso de gestión legítimo sobrevivió; una regla escrita para un puerto tiene la costumbre de coincidir con un rango más amplio de lo previsto.

Registre el propósito y la posición junto con la regla

Una regla sin un propósito registrado es una regla que nadie se atreve a eliminar. Junto a cada entrada de bloqueo, guarde el flujo que protege, la cadena y el hook en el que vive, la posición que debe mantener respecto a las aceptaciones más amplias y la prueba que lo demostró. Cuando alguien edite el conjunto de reglas circundante seis meses después, esa nota es la única advertencia de que la posición era deliberada.

Antes de cerrar el cambio, confirme cuatro cosas: el conjunto de reglas en ejecución coincide con el archivo, la regla nueva tiene contadores distintos de cero tras un intento nuevo, el sentido inverso y el acceso de gestión siguen funcionando, y se ha reconectado una vez para demostrar el estado estacionario en lugar del estado de una sesión anterior al cambio. Si algo de eso no está verificado, el cambio no está terminado, haga lo que haga el túnel.