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'

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

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