Sikkerhedsafbryderen aktiveres: hvad sker der med åbne TCP-sessioner?

Tunnelen falder, sikkerhedsafbryderen slår til, og en download, der var tre fjerdedele færdig, enten fryser eller fejler med det samme. De to udfald kommer fra forskellige håndhævelsesvalg, ikke fra forskellige beskyttelsesniveauer. En droppet pakke lader forbindelsen vente, mens en afvist pakke lukker den og fortæller applikationen det. At beslutte, hvilken adfærd du vil have, er et designspørgsmål, og at teste den er en separat øvelse.

Droppet, afvist og nulstillet er forskellige

En firewallregel, der dropper trafik, kasserer pakken og sender intet tilbage, så afsenderen bliver ved med at gensende efter sine egne timere. En regel, der afviser med et TCP-reset, lukker forbindelsen med det samme, og applikationen ser en fejl. De fleste sikkerhedsafbrydere dropper, fordi en afvisning ville afsløre politikken, og fordi drop ligner, hvordan et dødt netværk opfører sig.

Blokering er heller ikke det samme som at lukke soklen. Applikationen holder stadig en deskriptor i et etableret stadie, og det er kun pakkerne, der mangler. Derfor kan en side sidde på en spinner i flere minutter, mens operativsystemet fastholder, at forbindelsen findes. Læs den dokumenterede håndhævelse i stedet for at udlede den af applikationens besked, fordi begge adfærd ser ud som om netværket er nede.

Hvad applikationen gør, mens hullet varer

TCP gensender med stigende forsinkelser, og Linux' standardbudget for genforsøg udløber et sted omkring et kvarter i stedet for i sekunder. Indtil da er soklen hverken nyttigt åben eller lukket. Applikationer med deres egne keepalives eller anmodningstimeouts giver ofte op tidligere, og derfor opfører to programmer på samme maskine sig forskelligt under en afbrydelse.

Når tunnelen vender tilbage, er den lokale sokkel uændret, men stien er måske ikke. En ny offentlig kildeaddresse giver en anden firedel på serveren, så en stateful firewall på den anden side ikke længere matcher sessionen. Forbindelsen er død, selv om klienten aldrig så en fejl.

Beslut, om genopretning er nødvendig

Vælg mellem to kontrakter. Enten skal sessionen overleve et kort hul, hvilket kræver stabil adressering og en server, der beholder sin tilstand, eller applikationen skal genoprette forbindelsen rent, hvilket kræver genforsøgslogik, der er sikker at gentage. Alt derimellem giver det værste udfald: en klient, der gensender det, serveren allerede har bekræftet, eller en, der rapporterer succes for en session, ingen kan se.

Stabil adressering er den del, folk glemmer, fordi en genoprettet forbindelse, der lander på en anden offentlig adresse, ugyldiggør tilstanden på serversiden, selv når klientens sokkel ser sund ud. Skriv ned, hvilken af de to kontrakter der gælder for hver applikation, fordi de sjældent alle passer.

Test blokeringen og genopretningen hver for sig

Behandl lækagebeskyttelse og sessionsoverlevelse som to egenskaber, fordi det at bestå den ene intet siger om den anden. En session, der overlever, er ikke bevis for, at direkte trafik blev blokeret, og en session, der dør, er ikke bevis for, at enhver direkte rute blev blokeret.

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'

Brug en ufarlig testhandling, når du observerer genopretning, så en dobbelt indsendelse ikke bliver selve hændelsen. Notér den fejltilstand, du faktisk så: hvad applikationen viste, om soklen overlevede, og hvornår den kom sig af sig selv.

Skriv den forventede adfærd ved siden af håndhævelsesreglen, og sæt dato på. Den næste person, der ændrer reglen, skal vide, hvilken af de to kontrakter udrulningen lovede.