Kill switch slår inn: kva skjer med opne TCP-økter?

Tunnelen fell, kill switch slår inn, og ei nedlasting som var tre firedelar ferdig frys eller feilar med ein gong. Desse to utfalla kjem frå ulike handhevingval, ikkje frå ulike vernenivå. Ei forkasta pakke lèt tilkoplinga vente, medan ei avvist pakke lukkar henne og varslar applikasjonen. Å avgjere kva åtferd du vil ha er eit designspørsmål, og å teste henne er ei eiga øving.

Forkasta, avvist og tilbakestilt er ulike

Ein brannmurregel som forkastar trafikk, kastar pakka og sender ingenting tilbake, så avsendaren held fram med å sende på nytt etter eigne timarar. Ein regel som avviser med TCP reset, lukkar tilkoplinga med ein gong og applikasjonen ser ein feil. Dei fleste kill switch forkastar, fordi ei avvising ville avsløre policyen og fordi forkasting liknar åtferda til eit dødt nettverk.

Blokkering er heller ikkje det same som å lukke sockelen. Applikasjonen held framleis ein deskriptor i etablert tilstand, og det er berre pakkene som manglar. Difor kan ei side bli sitjande på ein spinner i minutt etter minutt medan operativsystemet insisterer på at tilkoplinga finst. Les den dokumenterte handhevinga i staden for å utleie henne frå meldinga til applikasjonen, sidan begge åtferdene ser ut som eit nettverk som er nede.

Kva applikasjonen gjer medan avbrotet varer

TCP sender på nytt med aukande forseinkingar, og standardbudsjettet for nye forsøk i Linux går ut etter om lag eit kvarter, ikkje i sekund. Fram til då er sockelen korkje nyttig open eller lukka. Applikasjonar med eigne keepalive eller tidsavbrot for førespurnader gir seg ofte tidlegare, og difor oppfører to program på same maskin seg ulikt under eitt avbrot.

Når tunnelen kjem tilbake, er den lokale sockelen uendra, men vegen er kanskje ikkje det. Ei ny offentleg kjeldeadresse gir ein annan firedel på tenaren, så ein tilstandsbasert brannmur på den andre sida passar ikkje lenger med økta. Tilkoplinga er død sjølv om klienten aldri såg ein feil.

Avgjer om gjenoppretting er nødvendig

Vel mellom to kontraktar. Anten må økta overleve eit kort avbrot, noko som krev stabil adressering og ein tenar som held på tilstanden sin, eller applikasjonen må kopie til på nytt reint, noko som krev retry-logikk som er trygg å gjenta. Alt imellom gir det verste utfallet: ein klient som sender på nytt det tenaren alt har registrert, eller ein som rapporterer suksess for ei økt ingen kan sjå.

Stabil adressering er den delen folk gløymer, fordi ei gjenoppkopling som landar på ei anna offentleg adresse gjer tilstanden på tenarsida ugyldig sjølv når sockelen til klienten ser sunn ut. Skriv ned kva av dei to kontraktane som gjeld for kvar applikasjon, sidan dei sjeldan passar alle saman.

Kontroller blokkeringa og gjenopprettinga kvar for seg

Handsam lekkasjevern og overleving av økta som to eigenskapar, fordi å klare den eine ikkje seier noko om den andre. Ei økt som overlever er ikkje prov på at direkte trafikk vart blokkert, og ei økt som døyr er ikkje prov på at kvar direkte rute vart blokkert.

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'

Bruk ein ufarleg testoperasjon når du observerer gjenoppretting, slik at ei duplisert innsending ikkje blir hendinga. Registrer feilmodusen du faktisk såg: kva applikasjonen viste, om sockelen overlevde, og når ho kom seg av seg sjølv.

Skriv den forventa åtferda ved sida av handhevingregelen og set dato på han. Den neste som endrar regelen må vite kva av dei to kontraktane utrullinga lova.