Kill switch қосылды: ашық TCP сессиялары не болады?

Туннель үзіледі, kill switch қосылады, ал төрттен үші дайын болған жүктеу не қатып қалады, не бірден сәтсіз аяқталады. Бұл екі нәтиже қорғаныстың әртүрлі деңгейінен емес, орындаудың әртүрлі таңдауынан туындайды. Тасталған пакет қосылымды күтуде қалдырады, ал қабылданбаған пакет оны жабады және қолданбаға хабарлайды. Қай мінез-құлық керек екенін шешу — дизайн мәселесі, ал оны тексеру — бөлек жаттығу.

Тастау, қабылдамау және қайта орнату — әртүрлі нәрселер

Трафикті тастайтын firewall ережесі пакетті лақтырады және ештеңе қайтармайды, сондықтан жіберуші өз таймерлерімен қайта жіберуді жалғастырады. TCP reset-пен қабылдамайтын ереже қосылымды бірден жабады және қолданба қатені көреді. Көптеген kill switch тастайды, өйткені қабылдамау саясатты ашады және тастау өлі желінің мінез-құлқына ұқсайды.

Блоктау — socket-ті жабу деген сөз емес. Қолданба әлі де орнатылған күйдегі дескрипторды ұстап тұр, тек пакеттер жетіспейді. Сондықтан бет минуттар бойы спиннерде тұра алады, ал операциялық жүйе қосылым бар деп таласады. Қолданбаның хабарламасынан болжам жасамай, құжатталған орындау ережесін оқыңыз, өйткені екі мінез-құлық та желі сөнгендей көрінеді.

Үзіліс жалғасқанда қолданба не істейді

TCP ұлғаятын кідірістермен қайта жібереді, ал Linux-тің әдепкі қайта әрекет бюджеті секундтарда емес, шамамен он бес минутта бітеді. Оған дейін socket пайдалы түрде ашық та, жабық та емес. Өз keepalive-ы немесе сұраныс күту уақыты бар қолданбалар жиі ертерек бас тартады, сондықтан бір машинадағы екі бағдарлама бір үзіліс кезінде әртүрлі мінез-құлық танытады.

Туннель қайтқанда жергілікті socket өзгермейді, бірақ жол өзгеруі мүмкін. Жаңа жалпыға қолжетімді бастапқы мекенжай серверде басқа төрттік тудырады, сондықтан алыс жақтағы күйі бар firewall енді сессияға сәйкес келмейді. Клиент ешқашан қате көрмесе де қосылым өлі.

Қалпына келу қажет пе, соны шешіңіз

Екі шарттың бірін таңдаңыз. Не сессия қысқа үзілісті өтуі керек, бұл тұрақты мекенжайлауды және күйін сақтайтын серверді қажет етеді, не қолданба таза қайта қосылуы керек, бұл қайталауға қауіпсіз қайта әрекет логикасын қажет етеді. Ортадағы кез келген нәрсе ең нашар нәтиже береді: сервер әлдеқашан тіркегенді қайта жіберетін клиент немесе ешкім көре алмайтын сессия үшін сәттілік хабарлайтын клиент.

Тұрақты мекенжайлау — адамдар ұмытатын бөлік, өйткені басқа жалпыға қолжетімді мекенжайға қонатын қайта қосылу клиенттің socket-і сау көрінсе де сервер жағындағы күйді жарамсыз етеді. Екі шарттың қайсысы қай қолданбаға қатысты екенін жазыңыз, өйткені олар сирек бәрі сәйкеседі.

Блоктауды және қалпына келуді бөлек тексеріңіз

Ағудан қорғауды және сессияның тірі қалуын екі қасиет ретінде қарастырыңыз, өйткені біреуінен өту екіншісі туралы ештеңе айтпайды. Тірі қалған сессия тікелей трафиктің блокталғанына дәлел емес, ал өлген сессия әрбір тікелей маршруттың блокталғанына дәлел емес.

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'

Қалпына келуді бақылағанда зиянсыз сынақ әрекетін қолданыңыз, сонда қайталанған жіберу оқиғаға айналмайды. Шын мәнінде көрген істен шығу түрін жазыңыз: қолданба не көрсетті, socket тірі қалды ма және ол өздігінен қашан қалпына келді.

Күтілетін мінез-құлықты орындау ережесінің жанына жазып, күнін қойыңыз. Бұл ережені өзгертетін келесі адам орналастыру қай шартқа уәде бергенін білуі керек.