Actívase o interruptor de seguridade: que ocorre coas sesións TCP abertas?

O túnel cae, o interruptor de seguridade actívase e unha descarga que ía por tres cuartos queda conxelada ou falla de inmediato. Esas dúas saídas proveñen de decisións de aplicación distintas, non de niveis de protección distintos. Un paquete descartado deixa a conexión agardando, mentres que un rexeitado péchaa e avisa a aplicación. Decidir que comportamento quere é unha cuestión de deseño, e probalo é un exercicio aparte.

Descartar, rexeitar e reiniciar son cousas distintas

Unha regra de firewall que descarta o tráfico elimina o paquete e non devolve nada, así que o emisor segue retransmitindo cos seus propios temporizadores. Unha regra que rexeita cun TCP reset pecha a conexión de inmediato e a aplicación ve un erro. A maioría dos interruptores de seguridade descartan, porque un rexeitamento revelaría a política e porque descartar parécese ao comportamento dunha rede morta.

Bloquear tampouco é o mesmo que pechar o socket. A aplicación aínda mantén un descritor nun estado establecido, e só faltan os paquetes. Por iso unha páxina pode quedar cun indicador de carga durante minutos mentres o sistema operativo insiste en que a conexión existe. Lea a política de aplicación documentada en lugar de deducila da mensaxe da aplicación, xa que ambos os comportamentos parecen unha rede caída.

Que fai a aplicación mentres dura a interrupción

TCP retransmite con atrasos crecentes, e o orzamento de reintentos por defecto de Linux esgótase arredor dun cuarto de hora, non en segundos. Ata entón o socket non está nin utilmente aberto nin pechado. As aplicacións cos seus propios keepalives ou tempos de espera de petición adoitan renderse antes, e por iso dous programas na mesma máquina compórtanse de forma distinta durante unha interrupción.

Cando o túnel volve, o socket local non cambiou, pero a ruta pode que si. Unha nova dirección de orixe pública produce unha cuádrupla distinta no servidor, así que un firewall con estado no lado remoto xa non coincide coa sesión. A conexión está morta aínda que o cliente nunca viu un erro.

Decida se se require recuperación

Escolla entre dous contratos. Ou a sesión debe sobrevivir a unha interrupción curta, o que require direccionamento estable e un servidor que conserve o seu estado, ou a aplicación debe reconectarse limpiamente, o que require lóxica de reintento que sexa segura de repetir. Calquera opción intermedia produce o peor resultado: un cliente que reenvía o que o servidor xa confirmou, ou un que informa de éxito para unha sesión que ninguén pode ver.

O direccionamento estable é a parte que a xente esquece, porque unha reconexión que aterra nunha dirección pública distinta invalida o estado do servidor mesmo cando o socket do cliente parece san. Anote cal dos dous contratos se aplica a cada aplicación, xa que raramente coinciden todos.

Comprobe o bloqueo e a recuperación por separado

Trate a protección contra fugas e a supervivencia da sesión como dúas propiedades, porque superar unha non di nada da outra. Unha sesión que sobrevive non é proba de que se bloqueou o tráfico directo, e unha sesión que morre non é proba de que se bloqueara toda ruta directa.

ss -tnp state established '( dport = :443 )'
sudo conntrack -L -p tcp --dport 443
sudo tcpdump -ni any 'tcp port 443 and tcp[tcpflags] & tcp-syn != 0'

Use unha operación de proba inofensiva ao observar a recuperación, para que un envío duplicado non se converta no incidente. Anote o modo de fallo que realmente viu: que mostraba a aplicación, se o socket sobreviviu e cando se recuperou por si só.

Escriba o comportamento esperado xunto á regra de aplicación e póñalle data. A próxima persoa que cambie esa regra necesita saber cal dos dous contratos prometeu o despregamento.