Kill switch aktivoituu: mitä avoimille TCP-istunnoille tapahtuu?

Tunneli putoaa, kill switch aktivoituu ja lataus, joka oli kolme neljäsosaa valmis, joko jäätyy tai epäonnistuu heti. Nämä kaksi lopputulosta tulevat erilaisista valvontavalinnoista, ei erilaisista suojatasoista. Pudotettu paketti jättää yhteyden odottamaan, kun taas hylätty paketti sulkee sen ja kertoo sovellukselle. Sen päättäminen, kumpaa käytöstä haluat, on suunnittelukysymys, ja sen testaaminen on erillinen harjoitus.

Pudotettu, hylätty ja nollattu ovat eri asioita

Palomuurisääntö, joka pudottaa liikenteen, hylkää paketin eikä lähetä mitään takaisin, joten lähettäjä jatkaa uudelleenlähetystä omilla ajastimillaan. Sääntö, joka hylkää TCP-nollauksella, sulkee yhteyden heti ja sovellus näkee virheen. Useimmat kill switch -toteutukset pudottavat, koska hylkäys paljastaisi käytännön ja koska pudottaminen muistuttaa kuolleen verkon käyttäytymistä.

Estäminen ei ole sama kuin pistokkeen sulkeminen. Sovellus pitää yhä kuvaajaa established-tilassa, ja vain paketit puuttuvat. Siksi sivu voi istua latausympyrässä minuutteja, kun käyttöjärjestelmä väittää yhteyden olevan olemassa. Lue dokumentoitu valvonta sen sijaan, että päättelet sen sovelluksen viestistä, koska molemmat käytökset näyttävät verkkoon, joka on alhaalla.

Mitä sovellus tekee katkoksen aikana

TCP lähettää uudelleen kasvavin viivein, ja Linuxin oletusyritysbudjetti päättyy jossain neljännes tunnin kohdalla, ei sekunneissa. Siihen asti pistoke ei ole hyödyllisesti auki eikä kiinni. Sovellukset, joilla on omat keepalivet tai pyyntöjen aikakatkaisut, luovuttavat usein aiemmin, minkä vuoksi kaksi ohjelmaa samassa koneessa käyttäytyvät eri tavoin yhden katkoksen aikana.

Kun tunneli palaa, paikallinen pistoke on muuttumaton, mutta polku ei ehkä ole. Uusi julkinen lähdeosoite tuottaa palvelimella erilaisen nelikon, joten kaukopuolen tilallinen palomuuri ei enää vastaa istuntoa. Yhteys on kuollut, vaikka asiakas ei koskaan nähnyt virhettä.

Päätä, vaaditaanko palautuminen

Valitse kahden sopimuksen välillä. Joko istunnon on selvittävä lyhyestä katkoksesta, mikä vaatii vakaan osoitteistuksen ja palvelimen, joka pitää tilansa, tai sovelluksen on yhdistettävä uudelleen puhtaasti, mikä vaatii uudelleenyrityslogiikan, joka on turvallista toistaa. Kaikki siltä väliltä tuottaa huonoimman tuloksen: asiakas, joka lähettää uudelleen sen, minkä palvelin on jo vahvistanut, tai sellainen, joka raportoi onnistumisen istunnosta, jota kukaan ei näe.

Vakaa osoitteistus on se osa, jonka ihmiset unohtavat, koska uudelleenyhteys, joka laskeutuu eri julkiseen osoitteeseen, mitätöi palvelinpuolen tilan, vaikka asiakkaan pistoke näyttäisi terveeltä. Kirjoita muistiin, kumpi sopimuksista koskee kutakin sovellusta, koska ne harvoin täsmäävät kaikki.

Tarkista estäminen ja palautuminen erikseen

Käsittele vuotosuojaa ja istunnon säilymistä kahtena ominaisuutena, koska yhden läpäiseminen ei kerro mitään toisesta. Säilyvä istunto ei ole todiste siitä, että suora liikenne estettiin, eikä kuoleva istunto ole todiste siitä, että jokainen suora reitti estettiin.

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'

Käytä vaaratonta testitoimintoa palautumista tarkkaillessasi, jotta toistettu lähetys ei muutu tapaukseksi. Kirjaa todella näkemäsi vikatila: mitä sovellus näytti, säilyikö pistoke ja milloin se palautui itsestään.

Kirjoita odotettu käytös valvontasäännön viereen ja päivää se. Seuraavan henkilön, joka muuttaa sääntöä, on tiedettävä, kumman kahdesta sopimuksesta käyttöönotto lupasi.