Активира се защитен превключвател: какво се случва с отворени TCP сесии?

Тунелът пада, защитният превключвател се задейства и изтегляне, готово на три четвърти, или замръзва, или се проваля веднага. Тези два изхода идват от различни решения за налагане, а не от различни нива на защита. Отхвърленият пакет оставя връзката да чака, докато отказаният я затваря и уведомява приложението. Да решите какво поведение искате е въпрос на дизайн, а да го тествате е отделно упражнение.

Отхвърляне, отказ и нулиране са различни

Правило на защитна стена, което отхвърля трафик, изхвърля пакета и не връща нищо, така че подателят продължава да препредава по собствените си таймери. Правило, което отказва с TCP нулиране, затваря връзката веднага и приложението вижда грешка. Повечето защитни превключватели отхвърлят, защото отказът би разкрил политиката и защото отхвърлянето прилича на поведението на мъртва мрежа.

Блокирането също не е същото като затваряне на сокета. Приложението все още държи дескриптор в установено състояние и липсват само пакетите. Затова страница може да стои на въртящ се индикатор с минути, докато операционната система настоява, че връзката съществува. Четете документираното налагане, вместо да го извеждате от съобщението на приложението, защото и двете поведения изглеждат като паднала мрежа.

Какво прави приложението, докато трае прекъсването

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'

Използвайте безвредна тестова операция, когато наблюдавате възстановяването, за да не се превърне дублирано изпращане в самия инцидент. Запишете режима на отказ, който наистина видяхте: какво показа приложението, дали сокетът оцеля и кога се възстанови сам.

Напишете очакваното поведение до правилото за налагане и го датирайте. Следващият човек, който промени това правило, трябва да знае кой от двата договора е обещало внедряването.