Kill switch ieslēdzas: kas notiek ar atvērtām TCP sesijām?

Tunelis nokrīt, kill switch ieslēdzas, un lejupielāde, kas bija trīs ceturtdaļas pabeigta, vai nu iesaldējas, vai tūlīt neizdodas. Šie divi iznākumi rodas no atšķirīgām izpildes izvēlēm, nevis no atšķirīgiem aizsardzības līmeņiem. Nomests pakete savienojumu atstāj gaidām, bet noraidīts pakete to aizver un paziņo lietotnei. Izlemt, kādu uzvedību vēlaties, ir dizaina jautājums, un tās pārbaude ir atsevišķs vingrinājums.

Nomešana, noraidīšana un atiestatīšana atšķiras

Ugunsmūra noteikums, kas nomet satiksmi, izmet paketi un neko neatgriež, tāpēc sūtītājs turpina pārsūtīt pēc saviem taimeriem. Noteikums, kas noraida ar TCP reset, tūlīt aizver savienojumu, un lietotne redz kļūdu. Lielākā daļa kill switch nomet, jo noraidījums atklātu politiku un jo nomešana atgādina miruša tīkla uzvedību.

Bloķēšana nav tas pats, kas ligzdas aizvēršana. Lietotne joprojām tur deskriptoru nodibinātā stāvoklī, un trūkst tikai paketes. Tāpēc lapa var minūtēm sēdēt uz ielādes indikatora, kamēr operētājsistēma uzstāj, ka savienojums pastāv. Lasiet dokumentēto izpildi, nevis seciniet to no lietotnes ziņojuma, jo abas uzvedības izskatās kā nokritis tīkls.

Ko lietotne dara, kamēr pārtraukums ilgst

TCP pārsūta ar pieaugošiem aizkavējumiem, un Linux noklusējuma atkārtošanas budžets beidzas nevis sekundēs, bet aptuveni ceturtdaļstundā. Līdz tam ligzda nav ne lietderīgi atvērta, ne aizvērta. Lietotnes ar saviem keepalive vai pieprasījumu taimautiem bieži padodas agrāk, tāpēc divas programmas vienā mašīnā viena pārtraukuma laikā uzvedas atšķirīgi.

Kad tunelis atgriežas, vietējā ligzda nav mainījusies, bet ceļš var būt. Jauna publiskā avota adrese serverī rada citu četrinieku, tāpēc tālākās puses stāvokļa ugunsmūris vairs neatbilst sesijai. Savienojums ir miris, lai gan klients nekad nav redzējis kļūdu.

Izlemiet, vai atjaunošana ir nepieciešama

Izvēlieties starp diviem līgumiem. Vai nu sesijai jāpārdzīvo īss pārtraukums, kas prasa stabilu adresāciju un serveri, kas saglabā savu stāvokli, vai arī lietotnei jāpievienojas no jauna tīri, kas prasa atkārtošanai drošu atkārtošanas loģiku. Jebkas pa vidu rada sliktāko iznākumu: klients, kas atkārtoti sūta to, ko serveris jau fiksējis, vai tāds, kas ziņo par panākumiem sesijai, kuru neviens nevar redzēt.

Stabila adresācija ir tā daļa, ko cilvēki aizmirst, jo atkārtots savienojums, kas nonāk citā publiskajā adresē, anulē servera puses stāvokli pat tad, ja klienta ligzda izskatās vesela. Pierakstiet, kurš no diviem līgumiem attiecas uz katru lietotni, jo reti visi sakrīt.

Pārbaudiet bloķēšanu un atjaunošanos atsevišķi

Uzskatiet noplūdes aizsardzību un sesijas izdzīvošanu par divām īpašībām, jo vienas izturēšana neko nepasaka par otru. Izdzīvojusī sesija nav pierādījums, ka tiešā satiksme tika bloķēta, un mirusī sesija nav pierādījums, ka tika bloķēts katrs tiešais maršruts.

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'

Novērojot atjaunošanos, izmantojiet nekaitīgu testa darbību, lai dublēts iesniegums nekļūtu par incidentu. Pierakstiet kļūmes veidu, ko faktiski redzējāt: ko lietotne parādīja, vai ligzda izdzīvoja un kad tā pati atjaunojās.

Pierakstiet gaidīto uzvedību blakus izpildes noteikumam un pievienojiet datumu. Nākamajai personai, kas mainīs šo noteikumu, jāzina, kuru no diviem līgumiem izvietošana apsolīja.