Kill switch aktivizohet: çfarë ndodh me sesionet e hapura TCP?

Tuneli bie, kill switch aktivizohet, dhe një shkarkim që ishte tre të katërtat gati ose ngrin ose dështon menjëherë. Këto dy rezultate vijnë nga zgjedhje të ndryshme zbatimi, jo nga nivele të ndryshme mbrojtjeje. Një paketë e hedhur lë lidhjen në pritje, ndërsa një paketë e refuzuar e mbyll atë dhe njofton aplikacionin. Të vendosësh se çfarë sjelljeje dëshiron është pyetje projektimi, dhe testimi i saj është ushtrim më vete.

Hedhja, refuzimi dhe rivendosja janë të ndryshme

Një rregull i firewall-it që hedh trafikun e flak paketën dhe nuk kthen asgjë, kështu që dërguesi vazhdon të ridërgojë sipas kohëmatësve të vet. Një rregull që refuzon me TCP reset e mbyll lidhjen menjëherë dhe aplikacioni sheh një gabim. Shumica e kill switch-eve hedhin, sepse refuzimi do të zbulonte politikën dhe sepse hedhja i ngjan sjelljes së një rrjeti të vdekur.

Bllokimi nuk është e njëjta gjë si mbyllja e socket-it. Aplikacioni ende mban një përshkrues në gjendje të vendosur, dhe mungojnë vetëm paketat. Kjo është arsyeja pse një faqe mund të qëndrojë në një spinner për minuta ndërsa sistemi operativ këmbëngul se lidhja ekziston. Lexoni zbatimin e dokumentuar në vend që ta nxirrni atë nga mesazhi i aplikacionit, pasi të dyja sjelljet duken si një rrjet i rënë.

Çfarë bën aplikacioni ndërsa zgjat boshllëku

TCP ridërgon me vonesa në rritje, dhe buxheti i parazgjedhur i përpjekjeve të Linux skadon rreth një çerek ore, jo në sekonda. Deri atëherë socket-i nuk është as i hapur në mënyrë të dobishme as i mbyllur. Aplikacionet me keepalive ose afate kohore të kërkesave të tyre shpesh dorëzohen më herët, prandaj dy programe në të njëjtën makinë sillen ndryshe gjatë një ndërprerjeje.

Kur tuneli kthehet, socket-i lokal nuk ka ndryshuar, por rruga mund të ketë. Një adresë e re publike burimore prodhon një katërshe tjetër në server, kështu që një firewall me gjendje në anën tjetër nuk përputhet më me sesionin. Lidhja është e vdekur edhe pse klienti nuk pa kurrë një gabim.

Vendosni nëse rikuperimi është i nevojshëm

Zgjidhni midis dy kontratave. Ose sesioni duhet t’ia dalë një boshllëku të shkurtër, që kërkon adresim të qëndrueshëm dhe një server që ruan gjendjen e vet, ose aplikacioni duhet të rilidhet pastër, që kërkon logjikë ripërpjekjeje të sigurt për t’u përsëritur. Çdo gjë në mes prodhon rezultatin më të keq: një klient që ridërgon atë që serveri ka regjistruar tashmë, ose një që raporton sukses për një sesion që askush nuk mund ta shohë.

Adresimi i qëndrueshëm është pjesa që njerëzit harrojnë, sepse një rilidhje që zbarkon në një adresë tjetër publike pavlefshmon gjendjen në anën e serverit edhe kur socket-i i klientit duket i shëndetshëm. Shkruani cila nga dy kontratat vlen për çdo aplikacion, pasi rrallë përputhen të gjitha.

Kontrolloni bllokimin dhe rikuperimin veçmas

Trajtoni mbrojtjen nga rrjedhjet dhe mbijetesën e sesionit si dy veti, sepse kalimi i njërës nuk thotë asgjë për tjetrën. Një sesion që mbijeton nuk është provë se trafiku i drejtpërdrejtë u bllokua, dhe një sesion që vdes nuk është provë se çdo rrugë e drejtpërdrejtë u bllokua.

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'

Kur vëzhgoni rikuperimin, përdorni një veprim testimi të padëmshëm, në mënyrë që një dërgim i dyfishtë të mos bëhet incidenti. Regjistroni mënyrën e dështimit që patët vërtet: çfarë shfaqi aplikacioni, a mbijetoi socket-i dhe kur u rikuperua vetë.

Shkruani sjelljen e pritur pranë rregullit të zbatimit dhe vendosni një datë. Personi i ardhshëm që ndryshon atë rregull duhet të dijë cilën nga dy kontratat premtoi vendosja.