Kill switch se sproži: kaj se zgodi z odprtimi sejami TCP?

Tunel pade, kill switch se sproži in prenos, ki je bil tri četrtine končan, se bodisi ustavi bodisi takoj ne uspe. Ta dva izida izhajata iz različnih odločitev o izvajanju, ne iz različnih ravni zaščite. Zavržen paket pusti povezavo v čakanju, medtem ko zavrnjen paket jo zapre in obvesti aplikacijo. Odločitev, kakšno vedenje želite, je vprašanje zasnove, preizkušanje pa je ločena vaja.

Zavrženje, zavrnitev in ponastavitev so različni

Pravilo požarnega zidu, ki zavrže promet, paket zavrže in nič ne pošlje nazaj, zato pošiljatelj še naprej pošilja po svojih časovnikih. Pravilo, ki zavrne s TCP reset, takoj zapre povezavo in aplikacija vidi napako. Večina kill switchov zavrže, ker bi zavrnitev razkrila politiko in ker zavrženje spominja na vedenje mrtvega omrežja.

Blokiranje ni isto kot zapiranje vtičnice. Aplikacija še vedno drži deskriptor v vzpostavljenem stanju in manjkajo samo paketi. Zato lahko stran več minut sedi na vrtavki, medtem ko operacijski sistem vztraja, da povezava obstaja. Berite dokumentirano izvajanje, namesto da bi ga sklepali iz sporočila aplikacije, saj sta obe vedenji videti kot padlo omrežje.

Kaj aplikacija počne, dokler prekinitev traja

TCP pošilja znova z naraščajočimi zakasnitvami, privzeti proračun ponovnih poskusov v Linuxu pa se izteče v približno četrt ure, ne v sekundah. Do takrat vtičnica ni niti koristno odprta niti zaprta. Aplikacije z lastnimi keepalive ali časovnimi omejitvami zahtev se pogosto predajo prej, zato se dva programa na istem računalniku med eno motnjo obnašata različno.

Ko se tunel vrne, lokalna vtičnica ostane nespremenjena, pot pa morda ne. Nov javni izvorni naslov na strežniku ustvari drugo četverico, zato se požarni zid s stanjem na drugi strani ne ujema več s sejo. Povezava je mrtva, čeprav odjemalec nikoli ni videl napake.

Odločite se, ali je obnovitev potrebna

Izberite med dvema pogodbama. Bodisi mora seja preživeti kratko prekinitev, kar zahteva stabilno naslavljanje in strežnik, ki ohrani svoje stanje, bodisi se mora aplikacija čisto znova povezati, kar zahteva logiko ponovnih poskusov, ki je varna za ponavljanje. Kar koli vmes daje najslabši izid: odjemalec, ki znova pošlje tisto, kar je strežnik že zabeležil, ali tak, ki poroča o uspehu za sejo, ki je nihče ne more videti.

Stabilno naslavljanje je del, ki ga ljudje pozabijo, ker ponovna povezava, ki pristane na drugem javnem naslovu, razveljavi stanje na strani strežnika, tudi ko je odjemalčeva vtičnica videti zdrava. Zapišite, katera od dveh pogodb velja za vsako aplikacijo, saj se redko vse ujemajo.

Blokado in obnovitev preverite ločeno

Zaščito pred uhajanjem in preživetje seje obravnavajte kot dve lastnosti, ker uspeh pri eni ne pove nič o drugi. Seja, ki preživi, ni dokaz, da je bil neposredni promet blokiran, in seja, ki umre, ni dokaz, da je bila blokirana vsaka neposredna pot.

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'

Pri opazovanju obnovitve uporabite neškodljivo preskusno operacijo, da dvojno pošiljanje ne postane incident. Zabeležite način odpovedi, ki ste ga res videli: kaj je aplikacija prikazala, ali je vtičnica preživela in kdaj si je sama opomogla.

Zapišite pričakovano vedenje ob pravilu izvajanja in mu dodajte datum. Naslednja oseba, ki bo spremenila to pravilo, mora vedeti, katero od dveh pogodb je obljubila namestitev.