Probar cambios de cortafuegos sin quedarte fuera

La regla entra, el terminal que ya tienes sigue respondiendo y el siguiente inicio de sesión se rechaza. Esa brecha es toda la dificultad de probar un cambio de cortafuegos por la conexión que estás cambiando. El seguimiento de conexiones decide una vez y luego deja de mirar, así que un flujo establecido es la única sonda que no puede ver la nueva política. Lo que sigue compara las tres formas de volver y después fija el orden en que hay que cambiar y comprobar las reglas.

Por qué la sesión que sobrevive es la evidencia más débil

Un cortafuegos con estado evalúa el primer paquete de un flujo y conserva ese veredicto mientras viva la entrada. Las reglas añadidas después se aplican a los flujos que empiezan más tarde, por eso la ventana en la que escribes sigue siendo utilizable mientras a todos los demás se les rechaza. Lo que aprendas de ella describe la política que estaba en vigor hace minutos. Incluso una captura tomada en ese flujo muestra una decisión que la máquina ya tomó.

Trata la sesión funcionante como una salida de emergencia y no como una medición. Toda comprobación que merezca la pena debe abrir un flujo nuevo desde una fuente que la nueva regla vaya a evaluar, y la primera comprobación debería ser la que más dolería si falla. Cuando esa sesión es tu única vía de entrada, el cambio no está listo para hacerse.

Tres formas de volver, ordenadas por aquello de lo que depende cada una

Ordena las opciones por cuánto dependen del dispositivo en pruebas, porque ese orden es al que recurres cuando la regla resulta estar mal. Una consola que nunca pasa por el cortafuegos es independiente, una reversión ensayada casi lo es, y la sesión ya abierta no lo es.

Antes del cambio, inicia sesión por la consola y demuestra que funciona, porque una vía fuera de banda que nunca has usado es un diagrama y no un recurso de reserva. Una reversión se gana su sitio solo tras un ensayo en esa plataforma, con ese conjunto de reglas, siguiendo el procedimiento aprobado en lugar de improvisar en una máquina en vivo. Escribe los pasos y haz que otra persona te los lea. Si la secuencia necesita tu memoria para completarse, no es un plan.

Un cambio, luego una conexión que debe ser evaluada

Guarda el conjunto de reglas vivo y el archivo que lo posee, y luego haz una única edición estrecha. Un cambio por prueba mantiene el resultado atribuible; dos a la vez te dejan una máquina que funciona y ninguna idea de qué edición hizo el trabajo. Donde la plataforma pueda analizar una configuración sin cargarla, hazlo primero, para que una errata falle cuando no hay nada en juego.

nft list ruleset > /root/ruleset.before
nft -c -f /etc/nftables.conf

Después inicia una sesión nueva desde una fuente que la regla cambiada vaya a hacer coincidir, mientras la consola sigue conectada. Repítelo una vez si tiene éxito, porque el primer intento puede caer en una entrada que la tabla ya tenía. Si falla, todavía tienes una vía de entrada y una decisión que revertir, que es el peor resultado barato disponible.

Los contadores, el estado y el archivo responden a preguntas distintas

Cada una de las tres observaciones puede parecer convincente por sí sola y engañarte sobre las otras dos. Los contadores muestran si el flujo que acabas de crear llegó a la regla que editaste. La tabla de estado muestra qué flujos cree la máquina que ya están establecidos, y así una regla rota puede seguir pareciendo sana. El archivo guardado muestra qué hará el dispositivo tras la próxima recarga, y puede que no sea lo que el conjunto de reglas en ejecución hace ahora.

ss -tn state established

Lee los contadores como un delta y no como un total, porque el único número que importa es el que movió tu flujo de prueba. Una regla cuyo contador nunca se incrementa no coincide, por muy correcta que parezca sobre el papel. Confirma también el caso de rechazo: una política que nunca ha rechazado nada nunca ha demostrado que rechaza lo que querías bloquear. Recorre una interfaz de cada familia que el despliegue lleve realmente, porque una regla v4 no dice nada sobre un flujo v6.

Restaura desde el conjunto de reglas guardado y luego haz que el archivo coincida

Cuando el cambio falla, carga el conjunto de reglas guardado en lugar de añadir reglas permisivas hasta que los inicios de sesión vuelvan a funcionar. Cada permiso extra calla el síntoma y deja un agujero que sobrevive al incidente y al recuerdo del mismo. Restaura, reconecta y luego guarda la comparación fallida junto al registro de lo que probaste.

Tras un cambio correcto, haz que el archivo del disco describa el conjunto de reglas que se ejecuta, y confirma que una recarga lo reproduce. Un conjunto de reglas vivo que se ha desviado de su propio archivo de configuración es una trampa puesta para el siguiente reinicio.