Probar cambios de cortalumes sen quedares fóra
Ordena as túas vías de recuperación antes de que entre a regra e despois verifica cun fluxo que a nova política deba avaliar, non coa sesión que sobreviviu.
A regra entra, o terminal que xa tes segue respondendo e o seguinte inicio de sesión rexéitase. Esa fenda é toda a dificultade de probar un cambio de cortalumes pola conexión que estás a cambiar. O seguimento de conexións decide unha vez e despois deixa de mirar, así que un fluxo establecido é a única sonda que non pode ver a nova política. O que segue compara as tres formas de volver e despois fixa a orde na que hai que cambiar e comprobar as regras.
Por que a sesión que sobrevive é a evidencia máis feble
Un cortalumes con estado avalía o primeiro paquete dun fluxo e conserva ese veredicto mentres viva a entrada. As regras engadidas despois aplícanse aos fluxos que comezan máis tarde, por iso a xanela na que escribes segue sendo utilizábel mentres a todos os demais se lles rexeita. O que aprendas dela describe a política que estaba en vigor hai minutos. Incluso unha captura tomada nese fluxo mostra unha decisión que a máquina xa tomou.
Trata a sesión funcionante como unha saída de emerxencia e non como unha medición. Toda comprobación que pague a pena debe abrir un fluxo novo desde unha fonte que a nova regra vaia avaliar, e a primeira comprobación debería ser a que máis doería se falla. Cando esa sesión é a túa única vía de entrada, o cambio non está listo para facerse.
Tres formas de volver, ordenadas polo que depende cada unha
Ordena as opcións por canto dependen do dispositivo en probas, porque esa orde é á que recorres cando a regra resulta estar mal. Unha consola que nunca pasa polo cortalumes é independente, unha reversión ensaiada case o é, e a sesión xa aberta non o é.
| Way back in | What it survives | Where it fails |
|---|---|---|
| out-of-band or hypervisor console | a policy that blocks new logins | needs separate access you have already tried |
| rollback rehearsed on that platform | a rule that breaks remote access | fails when nobody ever ran it |
| the session that is already open | the change itself | cannot show whether new flows work |
Antes do cambio, inicia sesión pola consola e demostra que funciona, porque unha vía fóra de banda que nunca usaches é un diagrama e non un recurso de reserva. Unha reversión gaña o seu sitio só tras un ensaio nesa plataforma, con ese conxunto de regras, seguindo o procedemento aprobado en lugar de improvisar nunha máquina en vivo. Escribe os pasos e fai que outra persoa cho lea. Se a secuencia necesita a túa memoria para completarse, non é un plan.
Un cambio, despois unha conexión que debe ser avaliada
Garda o conxunto de regras vivo e o ficheiro que o posúe, e despois fai unha única edición estreita. Un cambio por proba mantén o resultado atribuíbel; dous á vez déixanche unha máquina que funciona e ningunha idea de que edición fixo o traballo. Onde a plataforma poida analizar unha configuración sen cargala, faino primeiro, para que unha errata falle cando non hai nada en xogo.
nft list ruleset > /root/ruleset.before
nft -c -f /etc/nftables.conf
Despois inicia unha sesión nova desde unha fonte que a regra cambiada vai facer coincidir, mentres a consola segue conectada. Repíteo unha vez se ten éxito, porque o primeiro intento pode caer nunha entrada que a táboa xa tiña. Se falla, aínda tes unha vía de entrada e unha decisión que reverter, que é o peor resultado barato dispoñíbel.
Os contadores, o estado e o ficheiro responden a preguntas distintas
Cada unha das tres observacións pode parecer convincente por si soa e enganarte sobre as outras dúas. Os contadores mostran se o fluxo que acabas de crear chegou á regra que editaches. A táboa de estado mostra que fluxos cre a máquina que xa están establecidos, e así unha regra rota pode seguir parecendo sa. O ficheiro gardado mostra que fará o dispositivo tras a próxima recarga, e pode que non sexa o que fai agora o conxunto de regras en execución.
ss -tn state established
Le os contadores como un delta e non como un total, porque o único número que importa é o que moveu o teu fluxo de proba. Unha regra cuxo contador nunca se incrementa non coincide, por moi correcta que pareza sobre o papel. Confirma tamén o caso de rexeitamento: unha política que nunca rexeitou nada nunca demostrou que rexeita o que querías bloquear. Percorre unha interface de cada familia que o despregamento leve realmente, porque unha regra v4 non di nada sobre un fluxo v6.
Restaura desde o conxunto de regras gardado e despois fai que o ficheiro coincida
Cando o cambio falla, carga o conxunto de regras gardado en lugar de engadir regras permisivas ata que os inicios de sesión volvan funcionar. Cada permiso extra calma o síntoma e deixa un burato que sobrevive ao incidente e ao recordo del. Restaura, reconecta e despois garda a comparación fallida xunto ao rexistro do que probaches.
Tras un cambio correcto, fai que o ficheiro do disco describa o conxunto de regras que se executa, e confirma que unha recarga o reproduce. Un conxunto de regras vivo que se desviou do seu propio ficheiro de configuración é unha trampa posta para o seguinte reinicio.