Kill switch virkjast: hvað gerist með opnar TCP-tengingar?

Tunnillinn dettur, kill switch virkjast og niðurhal sem var þrjá fjórðu hluta á leið frystir eða mistekst samstundis. Þessar tvær niðurstöður koma frá mismunandi ákvörðunum um framfylgd, ekki frá mismunandi stigum verndar. Hendu pakka lætur tenginguna bíða, en hafnaðri pakka lokar henni og tilkynnir forritinu. Að ákveða hvaða hegðun þú vilt er hönnunarspurning og að prófa hana er sérstakt verkefni.

Hendur, hafnað og endurstillt eru ólík

Eldveggsregla sem hendir umferð fleygir pakkanum og sendir ekkert til baka, svo sendandinn heldur áfram að endursenda samkvæmt eigin tímateljurum. Regla sem hafnar með TCP endurstillingu lokar tengingunni samstundis og forritið sér villu. Flestir kill switch hendir, því höfnun myndi afhjúpa stefnuna og því að hending líkist hegðun dauðs nets.

Að blokka er ekki það sama og að loka sökkli. Forritið heldur enn lýsingu í uppsettu ástandi og aðeins pakkarnir vantar. Þess vegna getur síða setið á hringnum í mínútur á meðan stýrikerfið fullyrðir að tengingin sé til. Lestu skjalfesta framfylgd í stað þess að álykta hana frá skilaboðum forritsins, þar sem báðar hegðanir líta út eins og netið sé niðri.

Hvað forritið gerir meðan bilið varir

TCP endursendir með vaxandi töfum og sjálfgefið endurtilraunafjárhagsáætlun Linux rennur út á um fjórðungi klukkustundar, ekki í sekúndum. Þangað til er sökkullinn hvorki gagnlega opinn né lokaður. Forrit með eigin keepalive eða beiðnitímamörk gefast oft fyrr upp, þess vegna hegða tvö forrit á sömu vél sér ólíkt meðan á einni truflun stendur.

Þegar tunnillinn kemur aftur er staðbundni sökkullinn óbreyttur en slóðin kann að vera það ekki. Ný opinber upprunavistfang mynda annan ferning á þjóninum, svo ástandsmeðvituð eldveggur hinum megin passar ekki lengur við lotuna. Tengingin er dauð þótt biðlarinn hafi aldrei séð villu.

Ákveðið hvort bati er nauðsynlegur

Veldu á milli tveggja samninga. Annars vegar verður lotan að lifa af stuttu bili, sem krefst stöðugrar vistfangsnotkunar og þjóns sem heldur ástandi sínu, hins vegar verður forritið að tengjast aftur hreint, sem krefst endurtilraunarlógíkur sem er örugg að endurtaka. Hvað sem er þar á milli gefur versta útkomu: biðlara sem endursendir það sem þjónninn hefur þegar skráð, eða einn sem tilkynnir árangur fyrir lotu sem enginn getur séð.

Stöðug vistfangsnotkun er sá þáttur sem fólk gleymir, því endurtenging sem lendir á öðru opinberu vistfangi ógildir ástand þjónsins jafnvel þótt sökkull biðlarans líti út fyrir að vera heilbrigður. Skrifaðu niður hvor samningurinn gildir fyrir hvert forrit, þar sem þeir passa sjaldan allir saman.

Prófaðu blokkunina og batann hvort í sínu lagi

Líttu á lekavernd og lifun lotunnar sem tvo eiginleika, því að standast annan segir ekkert um hinn. Lota sem lifir er ekki sönnun þess að beinri umferð hafi verið blokkað, og lota sem deyr er ekki sönnun þess að hver bein leið hafi verið blokkuð.

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'

Notaðu skaðlausa prófunaraðgerð þegar þú fylgist með bata, svo tvítekin sending verði ekki atvikið. Skráðu bilunarhaminn sem þú sást í raun: hvað forritið sýndi, hvort sökkullinn lifði og hvenær hann batnaði sjálfur.

Skrifaðu vænta hegðun við hlið framfylgdareglunnar og setjið dagsetningu. Næsta manneskja sem breytir þeirri reglu þarf að vita hvor samninganna uppsetningin lofaði.