Примечание: Сетевой интерфейс (например, eth0)
Шаг:3
Таблица:mangle
Цепочка:PREROUTING
Примечание:Обычно эта цепочка используется для внесения изменений в заголовок пакета, например для изменения битов
TOSи пр..
Шаг:4
Таблица:nat
Цепочка:PREROUTING
Примечание:Эта цепочка используется для трансляции сетевых адресов (
Destination Network Address Translation).
Source Network Address Translationвыполняется позднее, в другой цепочке. Любого рода фильтрация в этой цепочке может производиться только в исключительных случаях
Шаг:5
Таблица:–
Цепочка:-
Примечание: Принятие решения о дальнейшей маршрутизации, т.е. в этой точке решается куда пойдет пакет – локальному приложению или на другой узел сети.
Шаг:6
Таблица:mangle
Цепочка:FORWARD
Примечание: Далее пакет попадает в цепочку
FORWARDтаблицы mangle, которая должна использоваться только в исключительных случаях, когда необходимо внести некоторые изменения в заголовок пакета между двумя точками принятия решения о маршрутизации.
Шаг:7
Таблица:Filter
Цепочка:FORWARD
Примечание: В цепочку
FORWARDпопадают только те пакеты, которые идут на другой хост Вся фильтрация транзитного трафика должна выполняться здесь. Не забывайте, что через эту цепочку проходит траффик в обоих направлениях, обязательно учитывайте это обстоятельство при написании правил фильтрации.
Шаг:8
Таблица:mangle
Цепочка:POSTROUTING
Примечание: Эта цепочка предназначена для внесения изменений в заголовок пакета уже после того как принято последнее решение о маршрутизации.
Шаг:9
Таблица:nat
Цепочка:POSTROUTING
Примечание: Эта цепочка предназначена в первую очередь для
Source Network Address Translation. Не используйте ее для фильтрации без особой на то необходимости. Здесь же выполняется и маскарадинг (Masquerading).
Шаг:10
Таблица:–
Цепочка:-
Примечание: Выходной сетевой интерфейс (например, eth1).
Шаг:11
Таблица:–
Цепочка:-
Примечание: Кабель (пусть будет LAN).
Как вы можете видеть, пакет проходит несколько этапов, прежде чем он будет передан далее. На каждом из них пакет может быть остановлен, будь то цепочка
iptablesили что либо еще, но нас главным образом интересует
iptables. Заметьте, что нет каких либо цепочек, специфичных для отдельных интерфейсов или чего либо подобного. Цепочку
FORWARDпроходят ВСЕ пакеты, которые движутся через наш брандмауэр/ роутер. Не используйте цепочку INPUT для фильтрации транзитных пакетов, они туда просто не попадают! Через эту цепочку движутся только те пакеты, которые предназначены данному хосту!
А теперь рассмотрим порядок движения пакета, предназначенного локальному процессу/приложению:
Таблица 3-2. Для локального приложения
(Шаг – Таблица – Цепочка – Примечание)
Шаг:1
Таблица:–
Цепочка:-
Примечание: Кабель (т.е. Интернет)
Шаг:2
Таблица:–
Цепочка:-
Примечание:Входной сетевой интерфейс (например, eth0)
Шаг:3
Таблица:mangle
Цепочка:PREROUTING
Примечание:Обычно используется для внесения изменений в заголовок пакета, например для установки битов
TOSи пр.
Шаг:4
Таблица:nat
Цепочка:PREROUTING
Примечание:Преобразование адресов (
Destination Network Address Translation). Фильтрация пакетов здесь допускается только в исключительных случаях.
Шаг:5
Таблица:–
Цепочка:-
Примечание:Принятие решения о маршрутизации.
Шаг:6
Таблица:mangle
Цепочка:INPUT
Примечание:Пакет попадает в цепочку
INPUTтаблицы mangle. Здесь внесятся изменения в заголовок пакета перед тем как он будет передан локальному приложению.
Шаг:7
Таблица:filter
Цепочка:INPUT
Примечание:Здесь производится фильтрация входящего трафика. Помните, что все входящие пакеты, адресованные нам, проходят через эту цепочку, независимо от того с какого интерфейса они поступили.
Шаг:8
Таблица:–
Цепочка:-
Примечание: Локальный процесс/приложение (т.е., программа-сервер или программа-клиент)
Важно помнить, что на этот раз пакеты идут через цепочку
INPUT, а не через
FORWARD.
И в заключение мы рассмотрим порядок движения пакетов, созданных локальными процессами.
Таблица 3-3. От локальных процессов
(Шаг – Таблица – Цепочка – Примечание)
Шаг:1
Таблица:–
Цепочка:-
Примечание: Локальный процесс (т.е., программа-сервер или программа-клиент).
Шаг:2
Таблица:–
Цепочка:-
Примечание: Принятие решения о маршрутизации. Здесь решается куда пойдет пакет дальше – на какой адрес, через какой сетевой интерфейс и пр.
Шаг:3
Таблица:mangle
Цепочка:OUTPUT
Примечание: Здесь производится внесение изменений в заголовок пакета. Выполнение фильтрации в этой цепочке может иметь негативные последствия.
Шаг:4
Таблица:nat
Цепочка:OUTPUT
Примечание: Эта цепочка используется для трансляции сетевых адресов (NAT) в пакетах, исходящих от локальных процессов брандмауэра.
Шаг:5
Таблица:Filter
Цепочка:OUTPUT
Примечание: Здесь фильтруется исходящий траффик.
Шаг:6
Таблица:mangle
Цепочка:POSTROUTING
Примечание: Цепочка
POSTROUTINGтаблицы mangle в основном используется для правил, которые должны вносить изменения в заголовок пакета перед тем, как он покинет брандмауэр, но уже после принятия решения о маршрутизации. В эту цепочку попадают все пакеты, как транзитные, так и созданные локальными процессами брандмауэра.
Шаг:7
Таблица:nat
Цепочка:POSTROUTING
Примечание: Здесь выполняется
Source Network Address Translation. Не следует в этой цепочке производить фильтрацию пакетов во избежание нежелательных побочных эффектов. Однако и здесь можно останавливать пакеты, применяя политику по-умолчанию
DROP.
Шаг:8
Таблица:-
Цепочка:-
Примечание: Сетевой интерфейс (например, eth0)
Шаг:9
Таблица:-
Цепочка:-
Примечание: Кабель (т.е., Internet)
Теперь мы знаем, что есть три различных варианта прохождения пакетов. Рисунок ниже более наглядно демонстрирует это:
Этот рисунок дает довольно ясное представление о порядке прохождения пакетов через различные цепочки. В первой точке принятия решения о маршрутизации (routing decision) все пакеты, предназначенные данному хосту направляются в цепочку
INPUT, остальные – в цепочку
FORWARD.
Обратите внимание также на тот факт, что пакеты, с адресом назначения на брандмауэр, могут претерпеть изменение сетевого адреса назначения (DNAT) в цепочке
PREROUTINGтаблицы nat и соответственно дальнейшая маршрутизация в первой точке будет выполняться в зависимости от произведенных изменений. Запомните –
всепакеты проходят через таблицы и цепочки по тому или иному маршруту. Даже если выполняется
DNATв ту же сеть, откуда пакет пришел, то он все равно продолжит движение по цепочкам.
СОВЕТ: В сценарии
rc.test-iptables.txtвы сможете найти дополнительную информацию о порядке прохождения пакетов.
3.2. Таблица Mangle
Как уже упоминалось выше, эта таблица предназначена, главным образом для внесения изменений в заголовки пакетов (mangle – искажать, изменять. прим. перев.). Т.е. в этой таблице вы можете устанавливать биты
TOS(Type Of Service) и т.д.
ОСТОРОЖНО: Еще раз напоминаю вам, что в этой таблице не следует производить любого рода фильтрацию, маскировку или преобразование адресов
(DNAT, SNAT, MASQUERADE).
В этой таблице допускается выполнять только нижеперечисленные действия:
TOS
TTL
MARK
Действие
TOSвыполняет установку битов поля
Type of Serviceв пакете. Это поле используется для назначения сетевой политики обслуживания пакета, т.е. задает желаемый вариант маршрутизации. Однако, следует заметить, что данное свойство в действительности используется на незначительном количестве маршрутизаторов в Интернете. Другими словами, не следует изменять состояние этого поля для пакетов, уходящих в Интернет, потому что на роутерах, которые таки обслуживают это поле, может быть принято неправильное решение при выборе маршрута.
Действие
TTLиспользуется для установки значения поля
TTL(Time To Live) пакета. Есть одно неплохое применение этому действию. Мы можем присваивать определенное значение этому полю, чтобы скрыть наш брандмауэр от чересчур любопытных провайдеров (Internet Service Providers). Дело в том, что отдельные провайдеры очень не любят когда одно подключение разделяется несколькими компьютерами. и тогда они начинают проверять значение
TTLприходящих пакетов и используют его как один из критериев определения того, один компьютер «сидит» на подключении или несколько.
Действие
MARKустанавливает специальную метку на пакет, которая затем может быть проверена другими правилами в iptables или другими программами, например
iproute2. С помощью «меток» можно управлять маршрутизацией пакетов, ограничивать траффик и т.п.
3.3. Таблица Nat
Эта таблица используется для выполнения преобразований сетевых адресов
NAT(Network Address Translation). Как уже упоминалось ранее, только первый пакет из потока проходит через цепочки этой таблицы, трансляция адресов или маскировка применяются ко всем последующим пакетам в потоке автоматически. Для этой таблицы характерны действия:
DNAT
SNAT
MASQUERADE
Действие
DNAT(Destination Network Address Translation) производит преобразование адресов назначения в заголовках пакетов. Другими словами, этим действием производится перенаправление пакетов на другие адреса, отличные от указанных в заголовках пакетов.
SNAT(Source Network Address Translation) используется для изменения исходных адресов пакетов. С помощью этого действия можно скрыть структуру локальной сети, а заодно и разделить единственный внешний IP адрес между компьютерами локальной сети для выхода в Интернет. В этом случае брандмауэр, с помощью
SNAT, автоматически производит прямое и обратное преобразование адресов, тем самым давая возможность выполнять подключение к серверам в Интернете с компьютеров в локальной сети.
Маскировка (
MASQUERADE) применяется в тех же целях, что и
SNAT, но в отличие от последней,
MASQUERADEдает более сильную нагрузку на систему. Происходит это потому, что каждый раз, когда требуется выполнение этого действия – производится запрос IP адреса для указанного в действии сетевого интерфейса, в то время как для
SNATIP адрес указывается непосредственно. Однако, благодаря такому отличию,
MASQUERADEможет работать в случаях с динамическим IP адресом, т.е. когда вы подключаетесь к Интернет, скажем через
PPP,
SLIPили
DHCP.
3.4. Таблица Filter
Как следует из названия, в этой таблице должны содержаться наборы правил для выполнения фильтрации пакетов. Пакеты могут пропускаться далее, либо отвергаться (действия
ACCEPTи
DROPсоответственно), в зависимости от их содержимого. Конечно же, мы можем отфильтровывать пакеты и в других таблицах, но эта таблица существует именно для нужд фильтрации. В этой таблице допускается использование большинства из существующих действий, однако ряд действий, которые мы рассмотрели выше в этой главе, должны выполняться только в присущих им таблицах.
Глава 4. Механизм определения состояний
В данной главе все внимание будет уделено механизму определения состояний пакетов (state machine). По прочтении ее у вас должно сложиться достаточно четкое представление о работе механизма, а способствовать этому должен значительный объем поясняющих примеров.
4.1. Введение
Механизм определения состояния (state machine) является отдельной частью iptables и в действительности не должен бы так называться, поскольку фактически является механизмом трассировки соединений. Однако значительному количеству людей он известен именно как «механизм определения состояния» (state machine). В данной главе эти названия будут использоваться как синонимы. Трассировщик соединений создан для того, чтобы netfilter мог постоянно иметь информацию о состоянии каждого конкретного соединения. Наличие трассировщика позволяет создавать более надежные наборы правил по сравнению с брандмауэрами, которые не имеют поддержки такого механизма.
В пределах iptables, соединение может иметь одно из 4-х базовых состояний:
NEW,
ESTABLISHED,
RELATEDи
INVALID. Позднее мы остановимся на каждом из них более подробно. Для управления прохождением пакетов, основываясь на их состоянии, используется критерий
–state.
Трассировка соединений производится специальным кодом в пространстве ядра – трассировщиком (conntrack). Код трассировщика может быть скомпилирован как подгружаемый модуль ядра, так и статически связан с ядром. В большинстве случаев нам потребна более специфичная информация о соединении, чем та, которую поставляет трассировщик по-умолчанию. Поэтому трассировщик включает в себя обработчики различных протоколов, например
TCP,
UDPили
ICMP. Собранная ими информация затем используется для идентификации и определения текущего состояния соединения. Например – соединение по протоколу
UDPоднозначно идентифицируется по IP-адресам и портам источника и приемника.
В предыдущих версиях ядра имелась возможность включения/выключения поддержки дефрагментации пакетов. Однако, после того как трассировка соединений была включена в состав iptables/netfilter, надобность в этом отпала. Причина в том, что трассировщик не в состоянии выполнять возложенные на него функции без поддержки дефрагментации и поэтому она включена постоянно. Ее нельзя отключить иначе как отключив трассировку соединений. Дефрагментация выполняется всегда, если трассировщик включен.
Трассировка соединений производится в цепочке
PREROUTING, исключая случаи, когда пакеты создаются локальными процессами на брандмауэре, в этом случае трассировка производится в цепочке
OUTPUT. Это означает, что iptables производит все вычисления, связанные с определением состояния, в пределах этих цепочек. Когда локальный процесс на брандмауэре отправляет первый пакет из потока, то в цепочке
OUTPUTему присваивается состояние
NEW, а когда возвращается пакет ответа, то состояние соединения в цепочке
PREROUTINGизменяется на
ESTABLISHED, и так далее. Если же соединение устанавливается извне, то состояние
NEWприсваивается первому пакету из потока в цепочке
PREROUTING. Таким образом, определение состояния пакетов производится в пределах цепочек
PREROUTINGи
OUTPUTтаблицы nat.
4.2. Таблица трассировщика
Кратко рассмотрим таблицу трассировщика, которую можно найти в файле /proc/net/ip_conntrack. Здесь содержится список всех активных соединений. Если модуль
ip_conntrackзагружен, то команда
cat /proc/net/ip_conntrakдолжна вывести нечто, подобное:
tcp 6 117 SYN_SENT src=192.168.1.6 dst=192.168.1.9 sport=32775 \ dport=22 [UNREPLIED] src=192.168.1.9 dst=192.168.1.6 sport=22 \ dport=32775 use=2
В этом примере содержится вся информация, которая известна трассировщику, по конкретному соединению. Первое, что можно увидеть – это название протокола, в данном случае – tcp. Далее следует некоторое число в обычном десятичном представлении. После него следует число, определяющее «время жизни» записи в таблице (т.е. количество секунд, через которое информация о соединении будет удалена из таблицы). Для нашего случая, запись в таблице будет храниться еще 117 секунд, если конечно через это соединение более не проследует ни одного пакета. При прохождении каждого последующего пакета через данное соединение, это значение будет устанавливаться в значение по-умолчанию для заданного состояния. Это число уменьшается на 1 каждую секунду. Далее следует фактическое состояние соединения. Для нашего примера состояние имеет значение SYN_SENT. Внутреннее представление состояния несколько отличается от внешнего. Значение SYN_SENT говорит о том, что через данное соединение проследовал единственный пакет
TCP SYN. Далее расположены адреса отправителя и получателя, порт отправителя и получателя. Здесь же видно ключевое слово [UNREPLIED], которое сообщает о том, что ответного трафика через это соединение еще не было. И наконец приводится дополнительная информация по ожидаемому пакету, это IP адреса отправителя/получателя (те же самые, только поменявшиеся местами, поскольку ожидается ответный пакет), то же касается и портов.
Записи в таблице могут принимать ряд значений, все они определены в заголовочных файлах linux/include/netfilter-ipv4/ip_conntrack*.h. Значения по-умолчанию зависят от типа протокола. Каждый из IP-протоколов –
TCP,
UDPили
ICMPимеют собственные значения по-умолчанию, которые определены в заголовочном файле linux/include/netfilter-ipv4/ip_conntrack.h. Более подробно мы остановимся на этих значениях, когда будем рассматривать каждый из протоколов в отдельности.
ПРИМЕЧАНИЕ: Совсем недавно, в patch-o-matic, появилась заплата tcp-window-tracking, которая предоставляет возможность передачи значений всех таймаутов через специальные переменные, т.е. позволяет изменять их «на лету». Таким образом появляется возможность изменения таймаутов без необходимости пересборки ядра.
Изменения вносятся с помощью определенных системных вызовов, через каталог /proc/sys/net/ipv4/netfilter. Особое внимание обратите на ряд переменных /proc/sys/net/ipv4/netfilter/ip_ct_*.
После получения пакета ответа трассировщик снимет флаг [UNREPLIED] и заменит его флагом [ASSURED]. Этот флаг сообщает о том, что соединение установлено уверенно и эта запись не будет стерта по достижении максимально возможного количества трассируемых соединений. Максимальное количество записей, которое может содержаться в таблице зависит от значения по-умолчанию, которое может быть установлено вызовом функции ipsysctl в последних версиях ядра. Для объема ОЗУ 128 Мб это значение соответствует 8192 записям, для 256 Мб – 16376. Вы можете посмотреть и изменить это значение установкой переменной /proc/sys/net/ipv4/ip_conntrack_max.
4.3. Состояния в пространстве пользователя
Как вы уже наверняка заметили, в пространстве ядра, в зависимости от типа протокола, пакеты могут иметь несколько различных состояний. Однако, вне ядра пакеты могут иметь только 4 состояния. В основном состояние пакета используется критерием
–state. Допустимыми являются состояния
NEW,
ESTABLISHED,
RELATEDи
INVALID. В таблице, приводимой ниже, рассмтриваются каждое из возможных состояний.
Таблица 4-1. Перечень состояний в пространстве пользователя
(Состояние – Описание)
Состояние: NEW
Описание:Признак
NEWсообщает о том, что пакет является первым для данного соединения. Это означает, что это первый пакет в данном соединении, который увидел модуль трассировщика. Например если получен
SYNпакет являющийся первым пакетом для данного соединения, то он получит статус
NEW. Однако, пакет может и не быть
SYNпакетом и тем не менее получить статус
NEW. Это может породить определенные проблемы в отдельных случаях, но может оказаться и весьма полезным, например когда желательно «подхватить» соединения, «потерянные» другими брандмауэрами или в случаях, когда таймаут соединения уже истек, но само соединение не было закрыто.
Состояние: RELATED
Описание:Состояние
RELATEDодно из самых «хитрых». Соединение получает статус
RELATEDесли оно связано с другим соединением, имеющим признак
ESTABLISHED. Это означает, что соединение получает признак
RELATEDтогда, когда оно инициировано из уже установленного соединения, имеющего признак
ESTABLISHED. Хорошим примером соединения, которое может рассматриваться как
RELATED, является соединение
FTP-data, которое является связанным с портом
FTP control, а так же
DCCсоединение, запущенное из
IRC. Обратите внимание на то, что большинство протоколов
TCPи некоторые из протоколов
UDPвесьма сложны и передают информацию о соединении через область данных
TCPили
UDPпакетов и поэтому требуют наличия специальных вспомогательных модулей для корректной работы.
Состояние: ESTABLISHED
Описание:Состояние
ESTABLISHEDговорит о том, что это не первый пакет в соединении. Схема установки состояния
ESTABLISHEDдостаточна проста для понимания. Единственное требование, предъявляемое к соединению, заключается в том, что для перехода в состояние
ESTABLISHEDнеобходимо чтобы узел сети передал пакет и получил на него ответ от другого узла (хоста). После получения ответа состояние соединения
NEWили
RELATEDбудет изаменено на
ESTABLISHED.
Состояние: INVALID
Описание:Признак
INVALIDговорит о том, что пакет не может быть идентифицирован и поэтому не может иметь определенного статуса. Это может происходить по разным причинам, например при нехватке памяти или при получении
ICMP–сообщения об ошибке, которое не соответствует какому либо известному соединению. Наверное наилучшим вариантом было бы применение действия
DROPк таким пакетам.
Эти четыре состояния могут использоваться в критерии
–state. Механизм определения состояния позволяет строить чрезвычайно мощную и эффективную защиту. Раньше приходилось открывать все порты выше 1024, чтобы пропустить обратный трафик в локальную сеть, теперь же, при наличии механизма определения состояния, необходимость в этом отпала, поскольку появилась возможность «открывать» доступ только для обратного (ответного) трафика, пресекая попытки установления соединений извне.
4.4. TCP соединения
В этом и в последующих разделах мы поближе рассмотрим признаки состояний и порядок их обработки каждым из трех базовых протоколов
TCP,
UDPи
ICMP, а так же коснемся случая, когда протокол соединения не может быть классифицирован на принадлежность к трем, вышеуказанным, протоколам. Начнем рассмотрение с протокола TCP, поскольку он имеет множество интереснейших особенностей в отношении механизма определения состояния в iptables.
TCPсоединение всегда устанавливается передачей трех пакетов, которые инициализируют и устанавливают соединение, через которое в дальнейшем будут передаваться данные. Сессия начинается с передачи
SYNпакета, в ответ на который передается
SYN/ACKпакет и подтверждает установление соединения пакет
ACK. После этого соединение считается установленным и готовым к передаче данных. Может возникнуть вопрос: «А как же трассируется соединение?». В действительности все довольно просто.
Для всех типов соединений, трассировка проходит практически одинаково. Взгляните на рисунок ниже, где показаны все стадии установления соединения. Как видите, трассировщик, с точки зрения пользователя, фактически не следит за ходом установления соединения. Просто, как только трассировщик «увидел» первый (
SYN) пакет, то присваивает ему статус
NEW. Как только через трассировщика проходит второй пакет (
SYN/ACK), то соединению присваивается статус
ESTABLISHED. Почму именно второй пакет? Сейчас разберемся. Строя свой набор правил, вы можете позволить покидать локальную сеть пакетам со статусом
NEWи
ESTABLISHED, а во входящем трафике пропускать пакеты только со статусом
ESTABLISHEDи все будет работать прекрасно. И наоборот, если бы трассировщик продолжал считать соединение как
NEW, то фактически вам никогда не удалось бы установить соединение с «внешним миром», либо пришлось бы позволить прохождение
NEWпакетов в локальную сеть. С точки зрения ядра все выглядит более сложным, поскольку в пространстве ядра
TCPсоединения имеют ряд промежуточных состояний, недоступных в пространстве пользователя. В общих чертах они соответствуют спецификации
RFC 793 – Transmission Control Protocolна странице 21-23. Более подробно эта тема будет рассматриваться чуть ниже.
С точки зрения пользователя все выглядит достаточно просто, однако если посмотреть с точки зрения ядра, то все выглядит несколько сложнее. Рассмотрим порядок изменения состояния соединения в таблице /proc/net/ip_conntrack. После передачи первого пакета
SYN.
tcp 6 117 SYN_SENT src=192.168.1.5 dst=192.168.1.35 sport=1031 \ dport=23 [UNREPLIED] src=192.168.1.35 dst=192.168.1.5 sport=23 \ dport=1031 use=1
Как видите, запись в таблице отражает точное состояние соединения – был отмечен факт передачи пакета SYN (флаг SYN_SENT), на который ответа пока не было (флаг [UNREPLIED]). После получения пакета-ответа, соединение переводится в следующее внутреннее состояние:
tcp 6 57 SYN_RECV src=192.168.1.5 dst=192.168.1.35 sport=1031 \ dport=23 src=192.168.1.35 dst=192.168.1.5 sport=23 dport=1031 \ use=1
Теперь запись сообщает о том, что обратно прошел пакет
SYN/ACK. На этот раз соединение переводится в состояние SYN_RECV. Это состояние говорит о том, что пакет
SYNбыл благополучно доставлен получателю и в ответ на него пришел пакет-подтверждение (
SYN/ACK). Кроме того, механизм определения состояния «увидев» пакеты, следующие в обеих направлениях, снимает флаг [UNREPLIED]. И наконец после передачи заключительного
ACK–пакета, в процедуре установления соединения
tcp 6 431999 ESTABLISHED src=192.168.1.5 dst=192.168.1.35 \ sport=1031 dport=23 src=192.168.1.35 dst=192.168.1.5 \ sport=23 dport=1031 use=1
соединение переходит в состояние
ESTABLISHED(установленное). После приема нескольких пакетов через это соединение, к нему добавится флаг [ASSURED] (уверенное).
При закрытии,
TCPсоединение проходит через следующие состояния.
Как видно из рисунка, соединение не закрывается до тех пор пока не будет передан последний пакет
ACK. Обратите внимание – эта картинка описывает нормальный процесс закрытия соединения. Кроме того, если соединение отвергается, то оно может быть закрыто передачей пакета
RST(сброс). В этом случае соединение будет закрыто по истечение предопределенного времени.
При закрытии, соединение переводится в состояние TIME_WAIT, продолжительность которого по-умолчанию соответствует 2 минутам, в течение которого еще возможно прохождение пакетов через брандмауэр. Это является своего рода «буферным временем», которое дает возможность пройти пакетам, «увязшим» на том или ином маршрутизаторе (роутере).
Если соединение закрывается по получении пакета
RST, то оно переводится в состояние CLOSE. Время ожидания до фактического закрытия соединения по-умолчанию устанавливается равным 10 секунд. Подтверждение на пакеты
RSTне передается и соединение закрывается сразу же. Кроме того имеется ряд других внутренних состояний. В таблице ниже приводится список возможных внутренних состояний соединения и соответствующие им размеры таймаутов.
Таблица 4-2. Internal states
(Состояние – Время ожидания )
NONE – 30 минут
ESTABLISHED – 5 дней
SYN_SENT – 2 минуты
SYN_RECV – 60 секунд
FIN_WAIT – 2 минуты
TIME_WAIT – 2 минуты
CLOSE – 10 секунд
CLOSE_WAIT – 12 часов
LAST_ACK – 30 секунд
LISTEN – 2 минуты
Эти значения могут несколько изменяться от версии к версии ядра, кроме того, они могут быть изменены через интерфейс файловой системы /proc (переменные proc/sys/net/ipv4/netfilter/ip_ct_tcp_*). Значения устанавливаются в сотых долях секунды, так что число 3000 означает 30 секунд.
ПРИМЕЧАНИЕ: Обратите внимание на то, что со стороны пользователя, механизм определения состояния никак не отображает состояние флагов
TCPпакетов. Как правило – это не всегда хорошо, поскольку состояние
NEWприсваивается, не только пакетам
SYN.
