Kill switch се активира: шта се дешава са отвореним TCP сесијама?

Тунел падне, kill switch се активира, а преузимање које је било три четвртине готово или се замрзне или одмах не успе. Ова два исхода долазе из различитих одлука о спровођењу, а не из различитих нивоа заштите. Одбачен пакет оставља везу да чека, док одбијени пакет затвара је и обавештава апликацију. Одлучити које понашање желите је питање дизајна, а тестирање је засебна вежба.

Одбацивање, одбијање и ресетовање су различити

Правило заштитног зида које одбацује саобраћај баца пакет и не шаље ништа назад, па пошиљалац наставља да поново шаље по сопственим тајмерима. Правило које одбија са TCP reset одмах затвара везу и апликација види грешку. Већина kill switch-ева одбацује, јер би одбијање открило политику и јер одбацивање личи на понашање мртве мреже.

Блокирање није исто што и затварање сокета. Апликација још држи дескриптор у успостављеном стању, а недостају само пакети. Зато страница може да стоји на спинеру минутима док оперативни систем тврди да веза постоји. Читајте документовано спровођење уместо да га закључујете из поруке апликације, јер оба понашања изгледају као пала мрежа.

Шта апликација ради док прекид траје

TCP поново шаље са растућим кашњењима, а подразумевани буџет поновних покушаја у Linux-у истиче за око четврт сата, а не за секунде. До тада сокет није ни корисно отворен ни затворен. Апликације са сопственим keepalive или временским ограничењима захтева често одустају раније, зато се два програма на истој машини понашају различито током једног прекида.

Када се тунел врати, локални сокет је непромењен, али путања можда није. Нова јавна изворна адреса ствара другу четворку на серверу, па заштитни зид са стањем на другој страни више не одговара сесији. Веза је мртва иако клијент никада није видео грешку.

Одлучите да ли је опоравак потребан

Изаберите између два уговора. Или сесија мора да преживи кратак прекид, што захтева стабилно адресирање и сервер који чува своје стање, или апликација мора чисто поново да се повеже, што захтева логику поновних покушаја која је безбедна за понављање. Све између даје најгори исход: клијент који поново шаље оно што је сервер већ забележио, или онај који пријављује успех за сесију коју нико не може да види.

Стабилно адресирање је део који људи забораве, јер поновно повезивање које слети на другу јавну адресу поништава стање на страни сервера чак и када сокет клијента изгледа здраво. Запишите који од два уговора важи за сваку апликацију, јер се ретко сви поклапају.

Проверите блокирање и опоравак одвојено

Третирајте заштиту од цурења и преживљавање сесије као два својства, јер пролаз једног не говори ништа о другом. Сесија која преживи није доказ да је директни саобраћај блокиран, а сесија која умре није доказ да је свака директна рута блокирана.

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'

Када посматрате опоравак, користите безопасну тест операцију, да дуплирано слање не постане инцидент. Забележите начин отказа који сте заиста видели: шта је апликација приказала, да ли је сокет преживео и када се сам опоравио.

Запишите очекивано понашање поред правила спровођења и ставите датум. Следећа особа која промени то правило мора да зна који је од два уговора распоређивање обећало.