Kill switch sa aktivuje: čo sa stane s otvorenými TCP reláciami?

Tunel spadne, kill switch sa aktivuje a stiahnutie, ktoré bolo na tri štvrtiny hotové, buď zamrzne, alebo hneď zlyhá. Tieto dva výsledky pochádzajú z rôznych rozhodnutí o presadzovaní, nie z rôznych úrovní ochrany. Zahodený paket necháva spojenie čakať, kým odmietnutý paket ho zatvorí a informuje aplikáciu. Rozhodnúť, ktoré správanie chcete, je otázka dizajnu a jeho testovanie je samostatné cvičenie.

Zahodenie, odmietnutie a reset sú rozdielne

Pravidlo firewallu, ktoré zahadzuje prevádzku, paket zlikviduje a nič nevráti, takže odosielateľ pokračuje v opakovanom odosielaní podľa vlastných časovačov. Pravidlo, ktoré odmieta s TCP reset, okamžite zatvorí spojenie a aplikácia vidí chybu. Väčšina kill switchov zahadzuje, pretože odmietnutie by prezradilo politiku a pretože zahadzovanie pripomína správanie mŕtvej siete.

Blokovanie nie je to isté ako zatvorenie socketu. Aplikácia stále drží deskriptor v nadviazanom stave a chýbajú iba pakety. Preto môže stránka minúty sedieť na spinneri, kým operačný systém tvrdí, že spojenie existuje. Čítajte zdokumentované presadzovanie, namiesto toho, aby ste ho odvodzovali zo správy aplikácie, keďže obe správania vyzerajú ako spadnutá sieť.

Čo aplikácia robí, kým prerušenie trvá

TCP opakuje odosielanie s rastúcim oneskorením a predvolený rozpočet opakovaní v Linuxe vyprší približne za štvrť hodiny, nie v sekundách. Dovtedy socket nie je ani užitočne otvorený, ani zatvorený. Aplikácie s vlastnými keepalive alebo časovými limitmi požiadaviek sa často vzdajú skôr, a preto sa dva programy na tom istom počítači počas jedného výpadku správajú odlišne.

Keď sa tunel vráti, lokálny socket sa nezmenil, ale cesta možno áno. Nová verejná zdrojová adresa vytvára na serveri inú štvoricu, takže stavový firewall na druhej strane už nezodpovedá relácii. Spojenie je mŕtve, hoci klient nikdy nevidel chybu.

Rozhodnite, či je obnova potrebná

Vyberte si medzi dvoma zmluvami. Buď musí relácia prežiť krátke prerušenie, čo vyžaduje stabilné adresovanie a server, ktorý si zachováva stav, alebo sa aplikácia musí čisto znova pripojiť, čo vyžaduje logiku opakovaní, ktorá je bezpečná na zopakovanie. Čokoľvek medzitým prináša najhorší výsledok: klient, ktorý znova odosiela to, čo server už zaznamenal, alebo taký, ktorý hlási úspech pre reláciu, ktorú nikto nevidí.

Stabilné adresovanie je časť, na ktorú ľudia zabúdajú, pretože opätovné pripojenie, ktoré pristane na inej verejnej adrese, zneplatní stav na strane servera, aj keď socket klienta vyzerá zdravo. Zapíšte, ktorá z dvoch zmlúv platí pre každú aplikáciu, keďže zriedka sedia všetky.

Skontrolujte blokovanie a obnovu oddelene

Berte ochranu pred únikom a prežitie relácie ako dve vlastnosti, pretože prejdenie jednej nič nehovorí o druhej. Relácia, ktorá prežije, nie je dôkazom, že priama prevádzka bola zablokovaná, a relácia, ktorá zomrie, nie je dôkazom, že bola zablokovaná každá priama trasa.

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 pozorovaní obnovy použite neškodnú testovaciu operáciu, aby sa duplicitné odoslanie nestalo incidentom. Zaznamenajte režim zlyhania, ktorý ste skutočne videli: čo aplikácia zobrazila, či socket prežil a kedy sa sám vzchopil.

Napíšte očakávané správanie vedľa pravidla presadzovania a doplňte dátum. Ďalší človek, ktorý to pravidlo zmení, musí vedieť, ktorú z dvoch zmlúv nasadenie sľúbilo.