La sekureca ŝaltilo aktiviĝas: kio okazas al malfermitaj TCP-sesioj?

La tunelo falas, la sekureca ŝaltilo ekagas, kaj elŝuto, kiu estis tri kvaronojn finita, aŭ frostas aŭ tuj malsukcesas. Tiuj du rezultoj venas de malsamaj elektoj de plenumado, ne de malsamaj niveloj de protekto. Forĵetita paketo lasas la konekton atendi, dum malakceptita paketo fermas ĝin kaj informas la aplikaĵon. Decidi, kiun konduton vi volas, estas demando pri dezajno, kaj testi ĝin estas aparta ekzerco.

Forĵetita, malakceptita kaj restarigita estas malsamaj

Regulo de fajroŝirmilo, kiu forĵetas trafikon, forpelas la paketon kaj sendas nenion reen, do la sendanto daŭre resendas laŭ siaj propraj tempigiloj. Regulo, kiu malakceptas per TCP-restarigo, tuj fermas la konekton kaj la aplikaĵo vidas eraron. Plej multaj sekurecaj ŝaltiloj forĵetas, ĉar malakcepto malkaŝus la politikon kaj ĉar forĵetado similas al la konduto de morta reto.

Blokado ankaŭ ne samas al fermado de la ingo. La aplikaĵo ankoraŭ tenas priskribilon en establita stato, kaj mankas nur la paketoj. Tial paĝo povas sidi sur ŝpinilo dum minutoj, dum la operaciumo insistas, ke la konekto ekzistas. Legu la dokumentitan plenumadon anstataŭ dedukti ĝin el la mesaĝo de la aplikaĵo, ĉar ambaŭ kondutoj aspektas kiel reto, kiu estas malsupre.

Kion la aplikaĵo faras dum la paŭzo daŭras

TCP resendas kun kreskantaj prokrastoj, kaj la defaŭlta buĝeto de Linux por reedonoj finiĝas ie ĉirkaŭ kvarono da horo, ne en sekundoj. Ĝis tiam la ingo estas nek utile malfermita nek fermita. Aplikaĵoj kun propraj keepalive aŭ petotempolimoj ofte rezignas pli frue, kio klarigas, kial du programoj sur la sama maŝino kondutas malsame dum unu paneo.

Kiam la tunelo revenas, la loka ingo estas neŝanĝita, sed la vojo eble ne estas. Nova publika fonta adreso produktas alian kvaropon ĉe la servilo, do stejt-plena fajroŝirmilo sur la malproksima flanko ne plu kongruas kun la sesio. La konekto estas morta, kvankam la kliento neniam vidis eraron.

Decidu, ĉu reakiro estas bezonata

Elektu inter du kontraktoj. Aŭ la sesio devas postvivi mallongan paŭzon, kio postulas stabilan adresadon kaj servilon, kiu konservas sian staton, aŭ la aplikaĵo devas rekonektiĝi pure, kio postulas relogikon sekuran por ripeto. Io ajn intere produktas la plej malbonan rezulton: kliento, kiu resendas tion, kion la servilo jam faris, aŭ unu, kiu raportas sukceson por sesio, kiun neniu povas vidi.

Stabila adresado estas la parto, kiun homoj forgesas, ĉar rekonekto, kiu alteriĝas sur alia publika adreso, nuligas la staton ĉe la servila flanko eĉ kiam la ingo de la kliento aspektas sana. Skribu, kiu el la du kontraktoj validas por ĉiu aplikaĵo, ĉar ili malofte ĉiuj kongruas.

Testu la blokadon kaj la reakiron aparte

Traktu likprotekton kaj sesian postvivon kiel du ecojn, ĉar trapasi unu diras nenion pri la alia. Sesio, kiu postvivas, ne estas pruvo, ke rekta trafiko estis blokita, kaj sesio, kiu mortas, ne estas pruvo, ke ĉiu rekta vojo estis blokita.

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'

Uzu sendanĝeran testan operacion dum vi observas reakiron, por ke duobla sendado ne fariĝu la incidento. Registru la fiaskmanieron, kiun vi efektive vidis: kion montris la aplikaĵo, ĉu la ingo postvivis, kaj kiam ĝi mem resaniĝis.

Skribu la atendatan konduton apud la plenumada regulo kaj datu ĝin. La sekva persono, kiu ŝanĝos tiun regulon, devas scii, kiun el la du kontraktoj la deplojo promesis.