Kill switch aktivearret: wat bart der mei iepen TCP-sesjes?

De tunnel falt, de kill switch grypt yn, en in download dy't foar trije fearn klear wie friezet of mislearret daliks. Dy twa útkomsten komme fan ferskillende hanthavingskarren, net fan ferskillende nivo's fan beskerming. In fallen pakket lit de ferbining wachtsje, wylst in wegere pakket it slút en de applikaasje warskôget. Beslute hokker gedrach jo wolle is in ûntwerpfraach, en it testen dêrfan is in aparte oefening.

Fallen, wegere en weromset binne ferskillend

In firewallregel dy't ferkear falt smyt it pakket fuort en stjoert neat werom, sadat de stjoerder mei syn eigen timers trochgiet mei opnij stjoeren. In regel dy't mei in TCP-reset wegeret, slút de ferbining daliks en de applikaasje sjocht in flater. De measte kill switches falle, om't in wegering it belied sjen litte soe en om't fallen liket op hoe't in dea netwurk him gedraacht.

Blokkearjen is ek net itselde as it sluten fan de socket. De applikaasje hâldt noch in beskriuwer yn 'e established-steat, en allinne de pakketten ûntbrekke. Dêrom kin in side minuten lang op in laadrûntsje bliuwe wylst it bestjoeringssysteem folhâldt dat de ferbining bestiet. Lês de dokumintearre hanthaving yn stee fan dy út 'e berjocht fan 'e applikaasje ôf te lieden, om't beide gedraach as in del netwurk lykje.

Wat de applikaasje docht wylst it gat duorret

TCP stjoert opnij mei tanimmende fertragingen, en it standert werombesykbudzjet fan Linux ferrint earne om in kertier, net yn sekonden. Oant dan is de socket noch nuttich iepen noch sletten. Applikaasjes mei har eigen keepalives of oanfraachtime-outs jouwe faak earder op, dêrom gedrage twa programma's op deselde masine har oars by ien útfal.

As de tunnel weromkomt, is de lokale socket ûnferoare, mar it paad miskien net. In nij publyk boarne-adres produsearret in oar fjouwertal by de tsjinner, sadat in steatfol firewall oan 'e oare kant net mear by de sesje past. De ferbining is dea, ek al seach de klant nea in flater.

Beslis oft werstel ferplichte is

Kies tusken twa kontrakten. Of de sesje moat in koart gat oerlibje, wat stabile adressering en in tsjinner nedich is dy't syn steat hâldt, of de applikaasje moat skjin wer ferbine, wat werombesyklogika nedich is dy't feilich is om te werheljen. Alles dertusken jout it slimste resultaat: in klant dy't werstjoert wat de tsjinner al fêstlein hat, of ien dy't sukses meldt foar in sesje dy't nimmen sjen kin.

Stabile adressering is it diel dat minsken ferjitte, om't in werferbining dy't op in oar publyk adres telâne komt de steat oan 'e tsjinnerkant ûnjildich makket, ek as de socket fan 'e klant sûn liket. Skriuw op hokker fan 'e twa kontrakten op elke applikaasje fan tapassing is, om't se selden allegear oerienkomme.

Kontrolearje de blokkade en it werstel apart

Behannelje lekbeskerming en it oerlibjen fan 'e sesje as twa eigenskippen, om't it slagjen fan ien neat seit oer de oare. In sesje dy't oerlibbet is gjin bewiis dat direkt ferkear blokkearre waard, en in sesje dy't stjert is gjin bewiis dat elke direkte rûte blokkearre waard.

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'

Brûk in ûnskealike testoperaasje by it observearjen fan it werstel, sadat in dûbele yntsjinning net it ynsidint wurdt. Skriuw de falmodus op dy't jo echt seagen: wat de applikaasje toande, oft de socket oerlibbe en wannear't er himsels werstelde.

Skriuw it ferwachte gedrach njonken de hanthavingsregel en datearje it. De folgjende persoan dy't dy regel feroaret, moat witte hokker fan 'e twa kontrakten de útrulling tasein hat.