O cambio de regra da devasa non funciona: orde das regras e estado da conexión

Editou a regra, recargou o conxunto de regras e o túnel compórtase exactamente como antes. Ese resultado ten dúas causas habituais, e necesitan probas distintas. Ou a regra nova queda despois de unha regra anterior que xa aceptou o paquete, ou o intercambio que observa é unha conexión rastrexada que o cambio nunca volve avaliar. Unha regra nun ficheiro expresa intención; o que decide o paquete é a ruta activa coa que se atopa. Percorra as comprobacións seguintes en orde e manteña unha vía de volta mentres o fai.

A orde das regras e o estado da conexión son fallos distintos

As cadeas ordenadas avalíanse de arriba abaixo, e a primeira regra que chega a un veredicto final termina o percorrido por esa cadea. Insira unha aceptación ampla por riba dunha regra de bloqueo escrita con coidado e a regra de bloqueo convértese en documentación: está no conxunto de regras, o seu contador é cero e ningún paquete chegará nunca a ela. O mesmo texto aplicado a outra cadea tampouco demostra nada. En nftables, as cadeas base enganchanse a hooks con prioridades, así que unha aceptación nunha cadea non impide que outra cadea nun hook ou unha prioridade distintos vexan o mesmo paquete.

O seguimento de conexións produce o segundo síntoma, e desde fóra vese idéntico. Unha vez que un fluxo está na táboa de estados, unha aceptación para establecido-ou-relacionado preto da cabeceira da cadea retorna antes de que se consulte a súa nova regra. As traducións NAT teñen a mesma propiedade: a tradución quedou fixada cando comezou o fluxo, así que unha regra de postrouting editada non reescribe unha sesión que xa está en marcha. Por iso un cambio parece funcionar ás 09:00 para unha conexión nova e parece non facer nada para a sesión que alguén abriu ás 08:55.

Os grupos de seguridade da nube engaden un terceiro modelo que atrapa a quen aprendeu con iptables. As súas regras de entrada son unha lista de permitidos que se avalía como un conxunto en lugar dun percorrido por primeira coincidencia, son con estado, e quitar unha regra de permiso non termina fluxos que xa se rastrexan. Supoñer semántica de primeira coincidencia nunha plataforma que non a ten leva a conclusións seguras e equivocadas.

Lea o conxunto de regras activo, non o ficheiro que editou

Comece polo que o núcleo está aplicando agora mesmo. Unha configuración gardada que nunca se aplicou explica unha cantidade sorprendente de comportamentos sen cambios, e descartalo custa un só comando:

nft list ruleset
iptables-save

Logo pregunte se a súa regra chega a alcanzarse. Os contadores de paquetes responden a iso directamente, e responden mellor que calquera razoamento sobre a intención:

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

Unha regra de bloqueo con cero paquetes tras un intento de proba real non é un problema de política, é un problema de posición. Movela é un cambio dunha liña, e a sintaxe é exactamente o que causou o erro orixinal. Con iptables, -I insire e -A engade ao final; con nftables, insert coloca unha regra ao comezo da cadea mentres que add engade ao final. Cando unha regra debe gañar, dígao explicitamente en lugar de confiar na orde que se cargou por casualidade.

Demostre se o fluxo está rastrexado

Antes de culpar a regra, comprobe se o tráfico é sequera unha conexión rastrexada. Pregunte á táboa de estados polo fluxo concreto en lugar de volcala enteira:

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

A listaxe mostra o estado e o tempo de espera restante, e así é como distingue unha sesión establecida dun intento novo; o modo de eventos imprime as actualizacións a medida que ocorren, o que resulta útil mentres reconecta un cliente. Se o fluxo está presente con estado establecido antes de que vostede tocara nada, ningunha edición das regras de filtrado cambiará o seu destino. Iso non é un fallo da devasa, é o contrato do filtrado con estado.

Resista o atallo de baleirar toda a táboa nunha pasarela de produción. conntrack -F está dispoñible, e tamén destrúe cada fluxo rastrexado da máquina, incluída a sesión de xestión desde a que traballa e o túnel que transporta a súa shell. As entradas individuais pódense borrar cando de verdade o necesita, pero un fluxo novo desde un porto de orixe novo adoita ser un experimento máis limpo.

Algunhas rutas non se rastrexan, e compórtanse ao revés. O tráfico marcado como notrack na táboa raw, algúns túneles que evitan os hooks normais e o encamiñamento asimétrico que reparte un fluxo entre dúas pasarelas producen todos paquetes avaliados un a un, ou un estado que nunca se crea nos dous extremos. Se os contadores se moven con cada paquete, sospeite dese tipo de ruta antes de sospeitar da orde.

Probe desde un fluxo novo cunha vía de volta

Antes de probar unha regra que podería cortar o acceso remoto, estableza unha vía de recuperación: a consola do provedor, unha consola serie, un enderezo de xestión fóra de banda ou unha segunda interface que a regra non poida coincidir. Un temporizador de reversión é un compañeiro razoable, xa que restaurará o conxunto de regras anterior aínda que a súa sesión morra a metade da proba.

Despois probe cun intercambio que o estado non puidera ter cuberto xa. Desconecte e reconecte o cliente para que se cree unha quíntupla nova, e observe ambos os extremos mentres ocorre:

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

Executa a proba nos dous sentidos. Unha regra que bloquea o novo handshake de entrada aínda pode permitir a ruta de resposta, ou ao revés, e un resultado unidireccional é a razón habitual de que un bloqueo funcione a medias. Reconecte unha vez despois da proba para confirmar o estado estacionario, e comprobe que o acceso de xestión lexítimo sobreviviu; unha regra escrita para un porto ten o costume de coincidir cun rango máis amplo do previsto.

Rexistre o propósito e a posición xunto coa regra

Unha regra sen un propósito rexistrado é unha regra que ninguén se atreve a eliminar. Xunto a cada entrada de bloqueo, garde o fluxo que protexe, a cadea e o hook no que vive, a posición que debe manter respecto das aceptacións máis amplas e a proba que o demostrou. Cando alguén edite o conxunto de regras circundante seis meses despois, esa nota é o único aviso de que a posición era deliberada.

Antes de pechar o cambio, confirme catro cousas: o conxunto de regras en execución coincide co ficheiro, a regra nova ten contadores distintos de cero tras un intento novo, o sentido inverso e o acceso de xestión seguen funcionando, e reconectou unha vez para demostrar o estado estacionario en lugar do estado dunha sesión anterior ao cambio. Se algo diso non está verificado, o cambio non está terminado, faga o que faga o túnel.