Kill switch aktiveerub: mis juhtub avatud TCP-sessioonidega?

Tunnel katkeb, kill switch rakendub ja allalaadimine, mis oli kolmveerandini valmis, kas hangub või ebaõnnestub kohe. Need kaks tulemust tulenevad erinevatest jõustamisvalikutest, mitte erinevatest kaitseastmetest. Allavisatud pakett jätab ühenduse ootama, samas kui tagasi lükatud pakett sulgeb selle ja teavitab rakendust. Otsustamine, millist käitumist te soovite, on disainiküsimus, ja selle testimine on eraldi harjutus.

Allavisatud, tagasi lükatud ja lähtestatud on erinevad

Tulemüüri reegel, mis jätab liikluse allavisatuks, heidab paketi kõrvale ega saada midagi tagasi, nii et saatja jätkab oma taimerite järgi kordussaatmist. Reegel, mis lükkab TCP resetiga tagasi, sulgeb ühenduse kohe ja rakendus näeb viga. Enamik kill switche jätab allavisatuks, sest tagasilükkamine paljastaks poliitika ja sest allavisramine sarnaneb surnud võrgu käitumisega.

Blokeerimine ei ole sama mis pesa sulgemine. Rakendus hoiab endiselt established olekus kirjeldajat ja puudu on ainult paketid. Seetõttu võib leht jääda laadimisringile minutiteks, samal ajal kui operatsioonisüsteem kinnitab, et ühendus on olemas. Lugege dokumenteeritud jõustamist, selle asemel et tuletada seda rakenduse teatest, kuna mõlemad käitumised näevad välja nagu maas olev võrk.

Mida rakendus teeb, kuni vaheaeg kestab

TCP saadab uuesti kasvavate viivitustega ja Linuxi vaikimisi korduskatsete eelarve aegub kuskil veerand tunni pärast, mitte sekunditega. Seni ei ole pesa ei kasulikult avatud ega suletud. Rakendused, millel on oma keepalive'id või päringu ajapiirid, annavad sageli varem alla, mistõttu kaks programmi samas masinas käituvad ühe katkestuse ajal erinevalt.

Kui tunnel naaseb, on kohalik pesa muutumatu, kuid tee ei pruugi olla. Uus avalik lähteaadress tekitab serveris teistsuguse neliku, nii et olekupõhine tulemüür kaugemal ei vasta enam sessioonile. Ühendus on surnud, kuigi klient ei näinud kunagi viga.

Otsustage, kas taastumine on nõutav

Valige kahe lepingu vahel. Kas sessioon peab lühikese vaheaja üle elama, mis nõuab stabiilset adresseerimist ja serverit, mis hoiab oma olekut, või peab rakendus puhtalt uuesti ühenduma, mis nõuab kordamiseks turvalist uuestiproovimisloogikat. Kõik vahepealne annab halvima tulemuse: klient, kes saadab uuesti selle, mille server on juba kinnitanud, või klient, kes teatab edust sessiooni puhul, mida keegi ei näe.

Stabiilne adresseerimine on see osa, mille inimesed unustavad, sest uuestiühendumine, mis maandub teisele avalikule aadressile, tühistab serveripoolse oleku isegi siis, kui kliendi pesa tundub terve. Kirjutage üles, milline kahest lepingust kehtib iga rakenduse kohta, kuna harva langevad need kõik kokku.

Kontrollige blokeerimist ja taastumist eraldi

Käsitlege lekke kaitset ja sessiooni püsimajäämist kahe omadusena, sest ühe läbimine ei ütle teise kohta midagi. Ellujäänud sessioon ei ole tõestus, et otseliiklus blokeeriti, ja surev sessioon ei ole tõestus, et iga otsene tee blokeeriti.

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'

Kasutage taastumise jälgimisel kahjutut testoperatsiooni, et duplikaatne esitamine ei muutuks juhtumiks. Kirjutage üles rikkerežiim, mida te tegelikult nägite: mida rakendus kuvas, kas pesa jäi püsima ja millal see ise taastus.

Kirjutage oodatav käitumine jõustamisreegli kõrvale ja dateerige see. Järgmine inimene, kes seda reeglit muudab, peab teadma, millise kahest lepingust juurutus lubas.