Kill switch aktiveras: vad händer med öppna TCP-sessioner?

Tunneln faller, kill switch aktiveras och en nedladdning som var tre fjärdedelar klar antingen fryser eller misslyckas direkt. Dessa två utfall kommer från olika tvingande val, inte från olika skyddsnivåer. Ett kastat paket låter anslutningen vänta, medan ett avvisat paket stänger den och informerar programmet. Att bestämma vilket beteende du vill ha är en designfråga, och att testa det är en separat övning.

Kastat, avvisat och återställt är olika

En brandväggsregel som kastar trafik slänger paketet och skickar ingenting tillbaka, så avsändaren fortsätter att skicka igen enligt sina egna timers. En regel som avvisar med TCP reset stänger anslutningen omedelbart och programmet ser ett fel. De flesta kill switchar kastar, eftersom en avvisning skulle avslöja policyn och eftersom kastande liknar beteendet hos ett dött nätverk.

Blockering är inte samma sak som att stänga socketen. Programmet håller fortfarande en deskriptor i etablerat tillstånd, och det är bara paketen som saknas. Därför kan en sida sitta på en spinner i minuter medan operativsystemet insisterar på att anslutningen finns. Läs den dokumenterade tvingande regeln i stället för att härleda den från programmets meddelande, eftersom båda beteendena ser ut som ett nätverk som ligger nere.

Vad programmet gör medan avbrottet varar

TCP skickar igen med ökande fördröjningar, och Linux standardbudget för nya försök löper ut efter ungefär en kvart, inte i sekunder. Fram till dess är socketen varken användbart öppen eller stängd. Program med egna keepalives eller tidsgränser för förfrågningar ger ofta upp tidigare, och därför beter sig två program på samma maskin olika under ett avbrott.

När tunneln kommer tillbaka är den lokala socketen oförändrad, men vägen är kanske inte det. En ny offentlig källadress ger en annan fyrtupel på servern, så en tillståndsbaserad brandvägg på andra sidan matchar inte längre sessionen. Anslutningen är död även om klienten aldrig såg ett fel.

Bestäm om återhämtning krävs

Välj mellan två kontrakt. Antingen måste sessionen överleva ett kort avbrott, vilket kräver stabil adressering och en server som behåller sitt tillstånd, eller så måste programmet återansluta rent, vilket kräver retry-logik som är säker att upprepa. Allt däremellan ger det sämsta utfallet: en klient som skickar igen det servern redan har registrerat, eller en som rapporterar framgång för en session ingen kan se.

Stabil adressering är den del folk glömmer, eftersom en återanslutning som landar på en annan offentlig adress ogiltigförklarar tillståndet på serversidan även när klientens socket ser frisk ut. Skriv ner vilket av de två kontrakten som gäller för varje program, eftersom de sällan passar alla.

Kontrollera blockeringen och återhämtningen separat

Behandla läckskydd och sessionens överlevnad som två egenskaper, eftersom att klara den ena inte säger något om den andra. En session som överlever är inte bevis på att direkt trafik blockerades, och en session som dör är inte bevis på att varje direkt väg blockerades.

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'

Använd en ofarlig testoperation när du observerar återhämtning, så att en dubblerad inskickning inte blir incidenten. Registrera felmoden du faktiskt såg: vad programmet visade, om socketen överlevde och när den återhämtade sig själv.

Skriv det förväntade beteendet bredvid tvinganderegeln och sätt ett datum. Nästa person som ändrar regeln måste veta vilket av de två kontrakten utrullningen lovade.