S'activa el commutador de seguretat: què passa amb les sessions TCP obertes?

El túnel cau, el commutador de seguretat s'activa i una descàrrega que estava a tres quartes parts o es congela o falla immediatament. Aquests dos resultats vénen de decisions d'aplicació diferents, no de nivells de protecció diferents. Un paquet descartat deixa la connexió esperant, mentre que un de rebutjat la tanca i avisa l'aplicació. Decidir quin comportament voleu és una qüestió de disseny, i provar-lo és un exercici a part.

Descartat, rebutjat i reiniciat són diferents

Una regla de tallafoc que descarta el trànsit llença el paquet i no retorna res, així que l'emissor continua retransmetent amb els seus propis temporitzadors. Una regla que rebutja amb un reinici TCP tanca la connexió immediatament i l'aplicació veu un error. La majoria de commutadors de seguretat descarten, perquè un rebuig revelaria la política i perquè descartar s'assembla al comportament d'una xarxa morta.

Bloquejar tampoc és el mateix que tancar el sòcol. L'aplicació encara té un descriptor en estat establert, i només falten els paquets. Per això una pàgina pot quedar-se minuts en un indicador de càrrega mentre el sistema operatiu insisteix que la connexió existeix. Llegiu l'aplicació documentada en lloc d'inferir-la del missatge de l'aplicació, perquè tots dos comportaments semblen la xarxa caiguda.

Què fa l'aplicació mentre dura el buit

TCP retransmet amb retards creixents, i el pressupost predeterminat de reintents de Linux s'esgota al voltant d'un quart d'hora, no en segons. Fins llavors el sòcol no és ni útilment obert ni tancat. Les aplicacions amb els seus propis keepalives o temps d'espera de sol·licitud sovint es rendeixen abans, i per això dos programes a la mateixa màquina es comporten diferent durant una caiguda.

Quan el túnel torna, el sòcol local no ha canviat, però el camí potser no. Una adreça d'origen pública nova produeix una quàdruple diferent al servidor, així que un tallafoc amb estat a l'altre costat ja no coincideix amb la sessió. La connexió és morta tot i que el client no va veure mai cap error.

Decidiu si cal recuperació

Trieu entre dos contractes. O la sessió ha de sobreviure a un buit curt, cosa que necessita adreçament estable i un servidor que conservi el seu estat, o l'aplicació s'ha de reconnectar netament, cosa que necessita lògica de reintents segura de repetir. Qualsevol cosa entremig produeix el pitjor resultat: un client que reenvia el que el servidor ja ha confirmat, o un que informa d'èxit per a una sessió que ningú no veu.

L'adreçament estable és la part que la gent oblida, perquè una reconnexió que cau en una adreça pública diferent invalida l'estat del costat del servidor fins i tot quan el sòcol del client sembla sa. Anoteu quin dels dos contractes s'aplica a cada aplicació, perquè rares vegades coincideixen tots.

Proveu el bloqueig i la recuperació per separat

Tracteu la protecció contra fuites i la supervivència de la sessió com dues propietats, perquè superar-ne una no diu res de l'altra. Una sessió que sobreviu no és prova que el trànsit directe s'hagi bloquejat, i una sessió que mor no és prova que totes les rutes directes s'hagin bloquejat.

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'

Feu servir una operació de prova inofensiva quan observeu la recuperació, perquè un enviament duplicat no es converteixi en l'incident. Registreu el mode de fallada que vau veure realment: què va mostrar l'aplicació, si el sòcol va sobreviure i quan es va recuperar sol.

Escriviu el comportament esperat al costat de la regla d'aplicació i dateu-lo. La següent persona que canviï aquesta regla ha de saber quin dels dos contractes va prometre el desplegament.