Kill switch slaat aan: wat gebeurt er met open TCP-sessies?

De tunnel valt weg, de kill switch grijpt in, en een download die voor driekwart klaar was, bevriest of mislukt onmiddellijk. Die twee uitkomsten komen voort uit verschillende handhavingskeuzes, niet uit verschillende beschermingsniveaus. Een weggegooid pakket laat de verbinding wachten, terwijl een geweigerd pakket hem sluit en de toepassing informeert. Bepalen welk gedrag je wilt is een ontwerpvraag, en het testen ervan is een aparte oefening.

Weggooien, weigeren en resetten zijn verschillend

Een firewallregel die verkeer weggooit, gooit het pakket weg en stuurt niets terug, dus de afzender blijft op zijn eigen timers opnieuw verzenden. Een regel die weigert met een TCP reset sluit de verbinding onmiddellijk en de toepassing ziet een fout. De meeste kill switches gooien weg, omdat een weigering het beleid zou verraden en omdat weggooien lijkt op het gedrag van een dood netwerk.

Blokkeren is ook niet hetzelfde als de socket sluiten. De toepassing houdt nog steeds een descriptor in een gevestigde toestand, en alleen de pakketten ontbreken. Daarom kan een pagina minutenlang op een spinner blijven staan terwijl het besturingssysteem volhoudt dat de verbinding bestaat. Lees de gedocumenteerde handhaving in plaats van die af te leiden uit het bericht van de toepassing, want beide gedragingen lijken op een netwerk dat platligt.

Wat de toepassing doet zolang de onderbreking duurt

TCP verzendt opnieuw met toenemende vertragingen, en het standaard herhaalbudget van Linux verloopt na ongeveer een kwartier, niet in seconden. Tot die tijd is de socket niet nuttig open en niet gesloten. Toepassingen met eigen keepalives of verzoek-timeouts geven vaak eerder op, en daarom gedragen twee programma's op dezelfde machine zich anders tijdens één storing.

Als de tunnel terugkomt, is de lokale socket ongewijzigd, maar het pad misschien niet. Een nieuw openbaar bronadres levert een andere vier-tuple op de server op, dus een stateful firewall aan de andere kant past niet meer bij de sessie. De verbinding is dood, ook al heeft de client nooit een fout gezien.

Bepaal of herstel nodig is

Kies tussen twee contracten. Ofwel de sessie moet een korte onderbreking overleven, wat stabiele adressering en een server vereist die zijn toestand bewaart, ofwel de toepassing moet schoon opnieuw verbinden, wat herhaallogica vereist die veilig te herhalen is. Alles daartussen levert het slechtste resultaat op: een client die opnieuw verstuurt wat de server al heeft vastgelegd, of een die succes meldt voor een sessie die niemand kan zien.

Stabiele adressering is het deel dat mensen vergeten, omdat een herverbinding die op een ander openbaar adres landt de toestand aan de serverkant ongeldig maakt, zelfs wanneer de socket van de client gezond lijkt. Schrijf op welk van de twee contracten voor elke toepassing geldt, want ze komen zelden allemaal overeen.

Controleer de blokkade en het herstel afzonderlijk

Behandel lekbepaling en sessieoverleving als twee eigenschappen, want het halen van de ene zegt niets over de andere. Een sessie die overleeft is geen bewijs dat direct verkeer is geblokkeerd, en een sessie die sterft is geen bewijs dat elke directe route is geblokkeerd.

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'

Gebruik een onschadelijke testbewerking bij het observeren van herstel, zodat een dubbele inzending niet het incident wordt. Leg de faalwijze vast die je werkelijk zag: wat de toepassing toonde, of de socket overleefde en wanneer die vanzelf herstelde.

Schrijf het verwachte gedrag naast de handhavingsregel en dateer het. De volgende persoon die die regel wijzigt, moet weten welk van de twee contracten de uitrol heeft beloofd.