Paquete de firewall instalado, regras desaparecidas tras o reinicio

O paquete instalouse limpiamente, as regras probáronse e, tras o seguinte reinicio, a pasarela estaba completamente aberta. Nada da transacción fallou; o fallo estaba no que se daba por feito que persistiría. Instalar ferramentas de firewall, decidir que regras deben sobrevivir e restauralas no momento axeitado son tres tarefas distintas.

Que che di realmente o síntoma

Un conxunto de regras que desaparece ao reiniciar ten un de tres donos: ninguén o gardou, outra cousa substituíuno ou restaurouse antes de que existise aquilo do que depende. Os dous primeiros son visibles na configuración; o terceiro só aparece na orde. Por iso un reinicio pode parecer unha perda de datos cando en realidade é un problema de secuencia.

Comeza escribindo que era certo antes do reinicio: que servizo tiña as regras, que ficheiro ou base de datos lía ao arrancar e se esa fonte se escribira algunha vez. Un conxunto de regras activo que ninguén gardou é unha explicación válida e a máis habitual.

Non comeces reinstalando o paquete.

Le a ferramenta de persistencia antes de usala

As ferramentas de Debian tratan a persistencia como un problema de complementos: cada complemento sabe como escribir as súas propias regras e un envoltorio chámaos. A súa acción de gardar almacena todo o que está cargado nese momento, e a súa acción de inicio volve cargar esa instantánea. Nada en ningunha das dúas accións revisa que está almacenando.

Iso é unha instantánea, non unha revisión. Un permiso sobrante dunha sesión de depuración, un experimento a medias ou unha regra permisiva inserida por outro axudante vólvense permanentes xunto á política que querías conservar. Gardar o estado e aprobar o estado son actividades distintas, e só unha esixe criterio. Le primeiro o conxunto cargado e logo decide que liñas merecen sobrevivir.

Garda deliberadamente, despois de ler o que está cargado.

Decide que debe sobrevivir

Algunhas regras pertencen ao ciclo de vida dunha interface e deberían desaparecer con ela. Outras deben sobrevivir ao túnel, e o exemplo máis claro é unha restrición que prohíbe que o tráfico dos clientes volva á interface física cando o túnel cae. Esas dúas categorías necesitan disparadores de restauración distintos, non unha instantánea compartida.

Escribe o resultado desexado para tres momentos: arranque, activación de VPN e perda do túnel. Despois comproba se a ferramenta que escolliches pode expresar cada un. Un paquete de persistencia que recarga unha instantánea estática cobre o primeiro e quizais ningún dos outros, porque unha instantánea non ten idea de cando cambiou o estado do túnel. Se non pode expresalos, o oco pertence a outro compoñente.

A política, non o paquete, decide a resposta.

Comproba a orde de restauración

Restaurar o ficheiro non é o mesmo que posuír o resultado. Outro xestor pode substituír as regras, un permiso anterior pode tapalas ou os clientes poden comezar a enviar antes de que chegue a restrición. Revisa o comportamento de arranque e de reconexión, non só a presenza dun ficheiro gardado.

systemctl status netfilter-persistent
iptables -S

Non supoñas que deter o servizo de persistencia é inofensivo, porque o paquete documenta un baleirado condicional cando se detén. Establece a configuración real do servizo antes de usar deter ou reiniciar como experimento nunha pasarela que administras en remoto. Unha sesión de consola e unha reversión documentada son o mínimo antes desa proba.

A orde é unha propiedade do sistema en marcha, non do ficheiro no disco.

Acepta tres resultados distintos

Rexistra a instalación do paquete, o conxunto de regras cargado e a política aplicada como feitos separados. Un nome de paquete nun fío de soporte só responde ao primeiro, e é o que raramente importa.

nft list ruleset

Despois proba unha operación permitida e unha denegación obrigatoria.

Se a denegación se mantén tras un reinicio e tras a caída do túnel, a política sobrevive. Se só se mantén nun deses estados, atopaches o problema de orde en lugar de corrixilo.