Kill switch aktiveres: hva skjer med åpne TCP-økter?

Tunnelen faller, kill switch aktiveres, og en nedlasting som var tre firedeler ferdig enten fryser eller feiler med en gang. Disse to utfallene kommer fra ulike håndhevelsesvalg, ikke fra ulike beskyttelsesnivåer. En forkastet pakke lar tilkoblingen vente, mens en avvist pakke lukker den og varsler applikasjonen. Å bestemme hvilken oppførsel du vil ha er et designspørsmål, og å teste den er en egen øvelse.

Forkastet, avvist og tilbakestilt er forskjellige

En brannmurregel som forkaster trafikk, kaster pakken og sender ingenting tilbake, så avsenderen fortsetter å sende på nytt etter egne timere. En regel som avviser med TCP reset, lukker tilkoblingen umiddelbart og applikasjonen ser en feil. De fleste kill switches forkaster, fordi en avvisning ville avsløre policyen og fordi forkasting ligner oppførselen til et dødt nettverk.

Blokkering er heller ikke det samme som å lukke sockelen. Applikasjonen holder fortsatt en deskriptor i etablert tilstand, og det er bare pakkene som mangler. Derfor kan en side bli sittende på en spinner i minutter mens operativsystemet insisterer på at tilkoblingen finnes. Les den dokumenterte håndhevelsen i stedet for å utlede den fra applikasjonens melding, siden begge oppførslene ser ut som et nettverk som er nede.

Hva applikasjonen gjør mens avbruddet varer

TCP sender på nytt med økende forsinkelser, og Linux' standardbudsjett for nye forsøk utløper omtrent etter et kvarter, ikke i sekunder. Inntil da er sockelen verken nyttig åpen eller lukket. Applikasjoner med egne keepalives eller tidsavbrudd for forespørsler gir seg ofte tidligere, og derfor oppfører to programmer på samme maskin seg ulikt under ett avbrudd.

Når tunnelen kommer tilbake, er den lokale sockelen uendret, men banen er kanskje ikke det. En ny offentlig kildeadresse gir en annen firedel på serveren, så en tilstandsbasert brannmur på den andre siden ikke lenger passer med økten. Tilkoblingen er død selv om klienten aldri så en feil.

Bestem om gjenoppretting er nødvendig

Velg mellom to kontrakter. Enten må økten overleve et kort avbrudd, noe som krever stabil adressering og en server som beholder tilstanden sin, eller applikasjonen må koble til på nytt rent, noe som krever retry-logikk som er trygg å gjenta. Alt imellom gir det verste utfallet: en klient som sender på nytt det serveren allerede har registrert, eller en som rapporterer suksess for en økt ingen kan se.

Stabil adressering er den delen folk glemmer, fordi en gjenoppkobling som lander på en annen offentlig adresse ugyldiggjør tilstanden på serversiden selv når klientens sockel ser sunn ut. Skriv ned hvilken av de to kontraktene som gjelder for hver applikasjon, siden de sjelden passer alle sammen.

Kontroller blokkeringen og gjenopprettingen hver for seg

Behandle lekkasjebeskyttelse og øktens overlevelse som to egenskaper, fordi å bestå den ene ikke sier noe om den andre. En økt som overlever er ikke bevis på at direkte trafikk ble blokkert, og en økt som dør er ikke bevis på at hver direkte rute ble 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 en ufarlig testoperasjon når du observerer gjenoppretting, slik at en duplisert innsending ikke blir hendelsen. Registrer feilmodusen du faktisk så: hva applikasjonen viste, om sockelen overlevde, og når den kom seg av seg selv.

Skriv den forventede oppførselen ved siden av håndhevelsesregelen og sett dato på den. Den neste som endrer regelen må vite hvilken av de to kontraktene utrullingen lovet.