A kill switch aktiválódik: mi történik a nyitott TCP-munkamenetekkel?

Az alagút megszakad, a kill switch aktiválódik, és egy letöltés, amely háromnegyedig kész volt, vagy lefagy, vagy azonnal meghiúsul. Ez a két kimenet különböző kényszerítési döntésekből ered, nem a védelem különböző szintjeiből. Az eldobott csomag várakozásban hagyja a kapcsolatot, míg az elutasított csomag lezárja azt, és értesíti az alkalmazást. Eldönteni, melyik viselkedést akarja, tervezési kérdés, a tesztelése pedig külön feladat.

Az eldobás, az elutasítás és a reset nem ugyanaz

A forgalmat eldobó tűzfal-szabály elveti a csomagot, és semmit nem küld vissza, így a küldő a saját időzítői szerint újraküldi. A TCP reset-tel elutasító szabály azonnal lezárja a kapcsolatot, és az alkalmazás hibát lát. A legtöbb kill switch eldob, mert az elutasítás felfedné a szabályzatot, és mert az eldobás egy halott hálózat viselkedésére hasonlít.

A blokkolás nem ugyanaz, mint a socket lezárása. Az alkalmazás továbbra is fogad egy leírót létesített állapotban, és csak a csomagok hiányoznak. Ezért egy oldal percekig ülhet egy pörgőn, miközben az operációs rendszer azt állítja, hogy a kapcsolat létezik. Olvassa a dokumentált kényszerítést, ahelyett hogy az alkalmazás üzenetéből következtetne rá, mivel mindkét viselkedés halott hálózatnak látszik.

Mit tesz az alkalmazás, amíg a szünet tart

A TCP növekvő késleltetéssel küld újra, a Linux alapértelmezett újrapróbálkozási kerete pedig nem másodpercekben, hanem nagyjából negyedóra alatt jár le. Addig a socket sem hasznosan nyitott, sem zárva nincs. A saját keepalive-pal vagy kérési időtúllépéssel rendelkező alkalmazások gyakran hamarabb feladják, ezért viselkedik két program ugyanazon a gépen eltérően egy kiesés alatt.

Amikor az alagút visszatér, a helyi socket nem változott, de az útvonal igen. Az új nyilvános forrás-cím más négyest hoz létre a kiszolgálón, így a túloldali állapottartó tűzfal már nem illeszkedik a munkamenethez. A kapcsolat halott, pedig az ügyfél soha nem látott hibát.

Döntse el, szükséges-e helyreállás

Válasszon két szerződés közül. Vagy a munkamenetnek túl kell élnie egy rövid szünetet, ami stabil címzést és állapotát megőrző kiszolgálót igényel, vagy az alkalmazásnak tisztán újra kell csatlakoznia, ami ismételhetően biztonságos újrapróbálkozási logikát igényel. A kettő közötti bármi a legrosszabb eredményt adja: egy ügyfél, amely újra elküldi azt, amit a kiszolgáló már rögzített, vagy egy, amely sikert jelent egy senki által nem látható munkamenetről.

A stabil címzés az a rész, amelyet az emberek elfelejtenek, mert a másik nyilvános címre érkező újracsatlakozás érvényteleníti a kiszolgáló oldali állapotot akkor is, ha az ügyfél socketje egészségesnek tűnik. Jegyezze fel, melyik szerződés vonatkozik az egyes alkalmazásokra, mert ritkán egyezik mind.

A blokkolást és a helyreállást külön ellenőrizze

A szivárgásvédelmet és a munkamenet túlélését két tulajdonságként kezelje, mert az egyik teljesülése semmit nem mond a másikról. Egy túlélő munkamenet nem bizonyítja, hogy a közvetlen forgalmat blokkolták, és egy elhalt munkamenet nem bizonyítja, hogy minden közvetlen útvonal blokkolva van.

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'

A helyreállás megfigyelésekor használjon ártalmatlan tesztműveletet, hogy a duplikált beküldés ne váljon incidenssé. Rögzítse a ténylegesen látott hibaformát: mit mutatott az alkalmazás, túlélte-e a socket, és mikor állt helyre magától.

Írja fel a várható viselkedést a kényszerítési szabály mellé, és lássa el dátummal. A következő embernek, aki megváltoztatja a szabályt, tudnia kell, melyik szerződést ígérte a telepítés.