Aktivuje se ochranný vypínač: co se stane s otevřenými TCP relacemi?

Tunel spadne, ochranný vypínač se zapne a stahování, které bylo ze tří čtvrtin hotové, buď zamrzne, nebo hned selže. Tyto dva výsledky pocházejí z různých rozhodnutí o prosazování, ne z různých úrovní ochrany. Zahrozený paket nechá spojení čekat, zatímco odmítnutý ho zavře a dá aplikaci vědět. Rozhodnout, jaké chování chcete, je otázka návrhu a otestovat ho je samostatné cvičení.

Zahrazení, odmítnutí a reset jsou různé věci

Pravidlo firewallu, které zahazuje provoz, paket zahodí a nic nevrátí, takže odesílatel dál znovu odesílá podle vlastních časovačů. Pravidlo, které odmítá resetem TCP, spojení okamžitě zavře a aplikace vidí chybu. Většina ochranných vypínačů zahazuje, protože odmítnutí by prozradilo politiku a protože zahazování připomíná chování mrtvé sítě.

Blokování také není totéž jako zavření socketu. Aplikace stále drží deskriptor v navázaném stavu a chybí jen pakety. Proto může stránka minuty viset na spinneru, zatímco operační systém trvá na tom, že spojení existuje. Čtěte dokumentované prosazování, místo abyste ho odvozovali ze zprávy aplikace, protože oba projevy vypadají jako výpadek sítě.

Co aplikace dělá, dokud mezera trvá

TCP znovu odesílá s rostoucím zpožděním a výchozí rozpočet opakování v Linuxu vyprší zhruba kolem čtvrt hodiny, ne v sekundách. Do té doby socket není užitečně otevřený ani zavřený. Aplikace s vlastními keepalive nebo časovými limity požadavků se často vzdají dřív, a proto se dva programy na stejném počítači chovají během jednoho výpadku různě.

Když se tunel vrátí, místní socket je nezměněný, ale cesta možná ne. Nová veřejná zdrojová adresa vytvoří na serveru jinou čtveřici, takže stavový firewall na vzdálené straně už relaci neodpovídá. Spojení je mrtvé, i když klient nikdy neviděl chybu.

Rozhodněte, zda je obnova nutná

Vyberte si mezi dvěma smlouvami. Buď musí relace přežít krátkou mezeru, což vyžaduje stabilní adresování a server, který si drží stav, nebo se aplikace musí čistě připojit znovu, což vyžaduje logiku opakování bezpečnou k opakování. Cokoli mezi tím dává nejhorší výsledek: klient, který znovu posílá to, co server už zapsal, nebo klient, který hlásí úspěch u relace, kterou nikdo nevidí.

Stabilní adresování je ta část, na kterou lidé zapomínají, protože opětovné připojení na jinou veřejnou adresu zneplatní stav na straně serveru, i když socket klienta vypadá zdravě. Zapište, která ze dvou smluv platí pro každou aplikaci, protože málokdy odpovídají všechny.

Testujte blokování a obnovu odděleně

Berte ochranu proti únikům a přežití relace jako dvě vlastnosti, protože splnění jedné nic neříká o druhé. Relace, která přežije, není důkazem, že byl přímý provoz zablokován, a relace, která zemře, není důkazem, že byla zablokována každá přímá 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'

Při sledování obnovy použijte neškodnou testovací operaci, aby se duplicitní odeslání nestalo samotným incidentem. Zaznamenejte režim selhání, který jste skutečně viděli: co aplikace zobrazila, zda socket přežil a kdy se sám obnovil.

Napište očekávané chování vedle pravidla prosazování a opatřete ho datem. Další člověk, který to pravidlo změní, musí vědět, kterou ze dvou smluv nasazení slíbilo.