Kill switch-a aktibatzen da: zer gertatzen zaie irekitako TCP saioei?

Tunela erortzen da, kill switch-a abiarazten da, eta hiru laurdenetan amaituta zegoen deskarga bat izoztu edo berehala huts egiten du. Bi emaitza horiek betearazpen-aukeraketa desberdinetatik datoz, ez babes-maila desberdinetatik. Botatako pakete batek konexioa itxaroten uzten du, ukatu batek, berriz, itxi egiten du eta aplikazioari jakinarazten dio. Zein portaera nahi duzun erabakitzea diseinu-galdera bat da, eta hura probatzea beste ariketa bat.

Botatakoa, ukatu eta berrezarria desberdinak dira

Trafikoa botatzen duen suebaki-arau batek paketea baztertu eta ez du ezer itzultzen, beraz igorleak bere tenporizadoreekin berrigortzen jarraitzen du. TCP reset batekin ukatzen duen arau batek konexioa berehala ixten du eta aplikazioak errore bat ikusten du. Kill switch gehienek botatzen dute, ukoak politika agerian utziko lukeelako eta botatzea hildako sare baten portaeraren antzekoa delako.

Blokeatzea ez da socket-a ixtearen berdina. Aplikazioak deskriptore bat eusten dio oraindik established egoeran, eta paketeak baino ez dira falta. Horregatik orrialde bat karga-adierazle batean egon daiteke minutuz, sistema eragileak konexioa existitzen dela baieztatzen duen bitartean. Irakurri dokumentatutako betearazpena aplikazioaren mezutik ondorioztatu beharrean, bi portaerak sare erori baten itxura dutelako.

Zer egiten du aplikazioak hutsuneak dirauen bitartean

TCP-k berrigortzen du atzerapen handiagoekin, eta Linux-en berriz saiatzeko aurrekontu lehenetsia ordu laurden inguruan iraungitzen da, ez segundoetan. Harik eta socket-a ez dago ez erabilgarri irekita ez itxita. Keepalive propioak edo eskaera-denbora mugak dituzten aplikazioek askotan lehenago amore ematen dute, horregatik makina bereko bi programak desberdin jokatzen dute etenaldi batean.

Tunela itzultzen denean, tokiko socket-a aldatu gabe dago, baina bidea agian ez. Iturburuko helbide publiko berri batek laukote desberdina sortzen du zerbitzarian, beraz urruneko aldeko suebaki egoeradun batek ez dator bat saioarekin. Konexioa hilda dago, bezeroak inoiz errore bat ikusi ez arren.

Erabaki berreskuratzea beharrezkoa den

Aukeratu bi kontraturen artean. Edo saioak hutsune labur bat gainditu behar du, eta horrek helbideratze egonkorra eta bere egoera gordetzen duen zerbitzari bat behar ditu, edo aplikazioak garbi berriro konektatu behar du, eta horrek errepikatzeko segurua den berriro saiatzeko logika behar du. Tartean dagoen edozein gauzak emaitzarik okerrena sortzen du: zerbitzariak jada konprometitu duena berbidaltzen duen bezero bat, edo inork ikusten ez duen saio baten arrakasta jakinarazten duena.

Helbideratze egonkorra jendeak ahazten duen zatia da, helbide publiko desberdin batera iristen den berrikonexioak zerbitzariaren aldeko egoera baliogabetzen duelako bezeroaren socket-a osasuntsu egon arren. Idatzi bi kontratuetatik zein dagokion aplikazio bakoitzari, gutxitan datoz denak bat.

Egiaztatu blokeoa eta berreskuratzea bereizita

Tratatu ihesen aurkako babesa eta saioaren biziraupena bi propietate gisa, bat gainditzeak ez baitu ezer esaten besteaz. Bizirik irauten duen saio bat ez da trafiko zuzena blokeatu zenaren froga, eta hiltzen den saio bat ez da bide zuzen guztiak blokeatu zirelaren froga.

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'

Erabili eragiketa arin bat berreskuratzea behatzean, bidalketa bikoiztu bat istorioa bihur ez dadin. Idatzi benetan ikusi zenuen hutsegite-modua: aplikazioak zer erakutsi zuen, socket-ak bizirik iraun zuen, eta noiz berreskuratu zen bere kabuz.

Idatzi espero den portaera betearazpen-arauaren ondoan eta data ipini. Arau hori aldatuko duen hurrengo pertsonak jakin behar du zein bi kontratu agindu zituen inplementazioak.