Документація українською/ Адміністрування/ Iptables - мережевий екран netfilter firewall/ Механізм визначення стану зєднання та трасування пакетів
← Порядок проходження таблиць і ланцюжків netfilter/iptables мережевими пакетами | Iptables - мережевий екран netfilter firewall | Побудова правил iptables →

Механізм визначення стану (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. Отже, визначення стану пакетів виробляєтьD1;я у межах ланцюжків PREROUTING і OUTPUT таблиці nat.

Таблиця трасувальника

Розглянемо коротко таблицю трасувальника, яку знайти в файлі /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 секунд, коли, звісно цю з'єднання більше прослідує жодного пакета. Під час проходження кожного наступного пакета через дане з'єднання, це значення встановлюватиметься в значення за замовчуванням для заданого стану. Ця кількість зменшується кожну секунду. Далі йде фактичний стан зєднання. У нашій прикладу стан має значення 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 стану. Здебільшого стан пакета використовується критерієм --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 свідчить, що пакет може бути ідентифікований і тому може мати певного статусу. Це може статися з різних причин, на 3F;риклад нестачі пам'яті або за отриманні ICMP-повідомлення про помилку, яке відповідає якому або відомому з'єднанню. Напевно найкращим варіантом було б застосування дії DROP до таких пакетів.

Ці чотири стани можна використовувати критеріям --state. Механізм визначення стану дозволяє будувати надзвичайно потужну і ефективний захист. Раніше доводилося відкривати все порти вище 1024, щоб пропустити зворотний трафік в локальну мережу, а тепер, за наявності механізму визначення стану, потреба у цьому відпала, оскільки з'явилася можливість "відкривати" доступ лише зворотного (відповідного) трафіку, пресекая спроби встановлення зєднання ззовні.

TCP зєднання

У цьому у наступних розділах ми ближче розглянемо ознаки станів і Порядок їх опрацювання кожним із трьох базових протоколів TCP, UDP і ICMP, а як і торкнемося випадку, коли протокол зєднання може бути класифікований на належність до трьом, вищевказаним, протоколів. Почнемо розгляд з протоколу TCP, бо має безліч цікавих особливостей щодо механізму визначення стану в iptables.

TCP з'єднання завжди встановлюється передачею трьох пакетів, які инициализируют і встановлюють з'єднання, крізь який надалі передаватися дані. Сесія починається з передачі SYN пакета, у відповідь який передається SYN/ACK пакет і навіть доводить з'єднання пакет ACK. Після цього з'єднання вважається встановленою і готовий до передачі даних. Може запитати: "Звичайно трассируется з'єднання?". Насправді все досить просто.

Всім типів зєднання, трасування проходить практично однаково. Погляньте малюнок нижче, де показані все стадії встановлення зєднання. Як бачите, трасувальник, з погляду користувача, фактично не стежить над перебігом встановлення зєднання. Просто, щойно трасувальник "побачив" перший (SYN) пакет, то привласнює йому статус NEW. Щойно через трасувальника проходить другий пакет (SYN/ACK), то з'єднанню присвоюється статус ESTABLISHED. Почму саме другий пакет? Зараз розберемося. Будуючи свій набір правил, ви можете дозволити залишати локальну мережу пакетів зі статусом NEW і ESTABLISHED, тоді як у входить трафіку пропускати пакети лише з статусом ESTABLISHED і буде працювати чудово. І навпаки, якби трасувальник продовжував вважати з'єднання як NEW, то фактично вам будь-коли можна було б встановити з'єднання з "зовнішнім світом", або довелося б дозволити проходження NEW пакетів в локальну мережу. З погляду ядра усе виглядає складнішим, що у просторі ядра TCP зєднання мають низку проміжних станів, недоступних у просторі користувача. У найзагальніших рисах вони відповідають специфікації [#RFC793 RFC 793 - Transmission Control Protocol] сторінка 21-23. Докладніше цю тему розглядатиметься трохи нижче.

?state-tcp-connecting.jpg

З погляду користувача усе виглядає не так важко, та якщо з погляду ядра, усі видається трохи складніше. Розглянемо порядок зміни стану з'єднання перетворені на таблиці /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 з'єднання проходить через такі стану.

?state-tcp-closing.jpg

Як очевидно з малюнка, з'єднання не закривається до того часу поки що не переданий останній пакет ACK. Зверніть увагу -- ця картинка описує нормальний процес закриття зєднання. З іншого боку, якщо з'єднання відхиляється, воно може бути закритий передачею пакета RST (скидання). І тут з'єднання буде закрито за витікання визначеного часу.

При закритті, з'єднання пе 40;етворюється на стан 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.

Ця якість трасувальника можна використовувати для надлишкового файерволлинга (firewalling), але для випадку домашньої локальної мережі, у якій використовується лише одне брендмаудер дуже погано. Проблема докладніше обговорюється розділ [#NEWNOTSYN Пакети зі статусом NEW і з скинутими битому SYN] докладання [#COMMONPROBLEMS Загальні проблеми й запитання]. Альтернативним варіантом розв'язання проблеми може бути установка латки tcp-window-tracking з patch-o-matic, яка вможливить прийняття рішень на залежність від значення TCP window.

UDP зєднання

За суттю, UDP зєднання немає ознаки стану. Цьому є кілька причин, основна полягає у цьому, що це протокол коштів встановлення й закриття зєднання, але найбільший недолік -- відсутність інформацію про черговості надходження пакетів. Прийнявши дві дейтаграми UDP, неможливо напевно у порядку вони відправили. Проте, навіть за цієї дедалі ще встановлюють стан зєднання. Нижче наводиться малюнок того, що таке з'єднання з погляду трасувальника.

?state-udp-connection.jpg

З малюнка видно, що певний стан UDP зєднання визначається схоже само як й загальний стан TCP зєднання, з погляду з користувальницького простору. Зсередини йому це бачиться трохи інакше, хоча баг 30;то в чому схоже. Спочатку розглянемо запис, що з'явилася після передачі першого пакета UDP.

udp      17 20 src=192.168.1.2 dst=192.168.1.5 sport=137 dport=1025 \
     [UNREPLIED] src=192.168.1.5 dst=192.168.1.2 sport=1025 \
     dport=137 use=1

Перше, що бачимо -- цю назву протоколу (udp) та її номер (див. /etc/protocols прим. перев.). Третє значення -- що залишилося "тривалість життя" запис у секундах. Далі йдуть характеристики пакета, котрий пройшов брендмаудер -- це адреси - й порти відправника і одержувача. Але тут видно, що це першу чергу в сесії (прапор [UNREPLIED]). І завершують запис адреси - й порти відправника і одержувача очікуваного пакета. Таймаут такому записі за умовчанням становить 30 секунд.

udp      17 170 src=192.168.1.2 dst=192.168.1.5 sport=137 \
     dport=1025 src=192.168.1.5 dst=192.168.1.2 sport=1025 \
     dport=137 use=1

Коли сервер "побачив" у відповідь першу чергу, з'єднання вважається ESTABLISHED (встановленим), єдине на відміну від попередньої записи у відсутності прапора [UNRREPLIED] та, крім того, тайм-аут для записи став рівним 180 секундам. Після цього й лише додатися прапор [ASSURED] (впевнене з'єднання), який був описаний вище. Прапор [ASSURED] встановлюється тільки після проходження певної кількості пакетів через з'єднання.

udp      17 175 src=192.168.1.5 dst=195.22.79.2 sport=1025 \
     dport=53 src=195.22.79.2 dst=192.168.1.5 sport=53 \
     dport=1025 [ASSURED] use=1

Тепер з'єднання стало "впевненим". Запис в таблиці виглядає практично як і і попереднього прикладі, крім прапора [ASSURED]. Якщо недоїмку протягом 180 секунд через з'єднання не пройде хоча б тільки пакет, то запис буде видалена з таблиці. Це досить маленький проміжок часу, але цілком достатньо більшості застосувань. "Час життя" відраховується від часу проходження останнього пакета і за появу нового, час переустанавливается на свій початкова значення, це справедливе й ж для решти типів внутрішніх станів.

ICMP зєднання

ICMP пакети задіяні лише передачі управляючих повідомлень і організують постійного зєднання. Проте, існує 4 типу ICMP пакетів, що викликають передачу відповіді, тому можуть мати два стану: NEW і ESTABLISHED. До цих пакетів ставляться ICMP Echo Request/Echo Reply, ICMP Timestamp Request/Timestamp Reply, ICMP Information Request/Information Reply і ICMP Address Mask Request/Address Mask Repl_y. У тому числі -- ICMP Timestamp Request/Timestamp Reply і ICMP Information Request/Information Reply_ вважаються застарілими і тому, здебільшого, може бути безболісно скинули (DROP). Погляньте малюнок нижче.

?state-icmp-ping.jpg

Як очевидно з цього малюнка, сервер виконує Echo Request (эхо-запрос) до клієнта, який (запит) розпізнається брендмаудером як NEW. Саме це запит клієнт відповідає пакетом Echo Reply, і тепер пакет розпізнається як має стан ESTABLISHED. Після проходження першого пакета (Echo Request) в ip_conntrack з'являється запис:

icmp     1 25 src=192.168.1.6 dst=192.168.1.10 type=8 code=0 \
     id=33029 [UNREPLIED] src=192.168.1.10 dst=192.168.1.6 \
     type=0 code=0 id=33029 use=1

Ця запис трохи відрізняється від записів, властивих протоколів TCP і UDP, хоча точно як і присутні і назву протоколу, й час таймаута і адреси передавача і приймача, але далі з'являються три нових поля - type, code і id. Поле type містить тип ICMP, полі code - код ICMP. Значення типів і кодів ICMP наводяться при застосуванні [#ICMPTYPES Типи ICMP]. І останнє полі id містить ідентифікатор пакета. Кожен ICMP-пакет має власний ідентифікатор. Коли приймач, у відповідь ICMP-запит посилає відповідь, він підставляє в окремий пакет відповіді цей ідентифікатор, завдяки чому, передавач може коректно розпізнати у відповідь який запит надійшла відповідь.

Наступне полі -- прапор [UNREPLIED], котрий зустрічався нам раніше. Він означає, що прибув першу чергу у поєднанні. Завершується запис характеристиками очікуваного пакета відповіді. Сюди включаються адреси відправника і одержувача. Що ж до типу, і коду ICMP пакета, всі вони відповідають правильним значенням очікуваного пакета ICMP Echo Reply. Идентификатор пакета-ответа хоча б, що у пакеті запиту.

Пакет відповіді розпізнається вже проводяться як ESTABLISHED. Проте, знаємо, що буває після передачі пакета відповіді, цю з'єднання уже не очікується, тому після проходження відповіді через netfilter, запис в таблиці трасувальника знищується.

У кожному разі запит сприймається як NEW, а відповідь як ESTABLISHED.

Зауважте у своїй, що пакет відповіді повинен збігатися за своїми характеристиками (адреси відправника і одержувача, тип, код і ідентифікатор) з зазначеними у запису в таблиці трасувальника, це справедливе й ж для решти типів трафіку.

ICMP запити мають тайм-аут, за замовчуванням, 30 секунд. Цього часу, здебільшого, предосить. Час таймаута можна змінити в /proc/sys/net/ipv4/netfilter/ip_ct_icmp_timeout. ( Нагадую, що перемінні типу /proc/sys/net/ipv4/netfilter/ip_ct*_ стають доступні тільки після установки "латки" tcp-window-tracking з patch-o-matic прим. перши.).

Значна частка власності ICMP використовується передачі повідомлень у тому, що приміром із тим чи іншим UDP чи TCP з'єднанням. Всвязи з цим вони часто розпізнаються як пов'язані (RELATED) до існуючого з'єднанням. Простим прикладом можуть бути повідомлення ICMP Host Unreachable чи ICMP Network Unreachable. Вони завжди народжуються під час спроби з'єднатися з вузлом мережі коли цей вузол чи мережу недоступні, у разі останній маршрутизатор поверне відповідний ICMP пакет, який розпізнано як RELATED. На малюнку нижче показано як.

?state-tcp-icmp-reply.jpg

У цьому вся прикладі деякому вузлу передається запит на з'єднання (SYN пакет). Він придбає статус NEW на брендмаудере. Проте, на той час часу, мережу виявляється недоступною, тому роутер повертає пакет ICMP Network Unreachable. Трасувальник зєднання розпізнає цей пакет як RELATED, завдяки вже наявної запис у таблиці, отже пакет благополучно буде передано клієнту, і потім обірве невдалий з'єднання. Тим часом, брендмаудер знищить запис в таблиці, бо даного зєднання отримали повідомлення про помилку.

Це ж відбувається з UDP зєднанняами -- якщо виявляються такі проблеми. Усі повідомлення ICMP, передані у відповідь UDP з'єднання, розглядаються як RELATED. Погляньте наступний малюнок.

?state-udp-icmp-reply.jpg

Датаграмма UDP передається на сервер. З'єднанню присвоюється статус NEW. Проте доступом д 3E; мережі заборонено (брендмаудером чи роутером), тому назад повертається повідомлення ICMP Network Prohibited. Брандмауэр розпізнає це повідомлення як що з відкритим UDP з'єднанням, привласнює йому статус RELATED і передає клієнту. Після цього запис в таблиці трасувальника знищується, а клієнт благополучно обриває з'єднання.

Поведінка за замовчуванням

У окремих випадках механізм визначення стану неспроможна розпізнати протокол обміну і, неспроможна вибрати стратегію обробки цього зєднання. І тут він переходить до заданої за замовчуванням поведінці. Поведінка за замовчуванням використовується, наприклад з обслуговування протоколів NETBLT, MUX і EGP. Поведінка по-молчанию багато в чому схоже з трассировкой UDP зєднання. Першому пакету присвоюється статус NEW, а всім наступним - статус ESTABLISHED.

З використанням поведінки за замовчуванням, всім пакетів використовується один і той ж значення таймаута, що можна змінити в /proc/sys/net/ipv4/netfilter/ip_ct_generic_timeout. По-умолчанию це значення одно 600 секундам, чи 10 хвилинах Залежно від типу трафіку, цей час не може змінюватися, особливо коли з'єднання встановлюється по спутниковому каналу.

Трасування комплексних протоколів

Є низка комплексних протоколів, коректна трасування яких понад складна. Прмером можуть бути протоколи ICQ, IRC і FTP. Кожен з цих протоколів несе додаткову інформацію про з'єднання у сфері даних пакета. Відповідно коректна трасування таких зєднання вимагає підключення додаткових допоміжних модулів.

Як першого прикладу розглянемо протокол FTP. Протокол FTP спочатку відкриває одиночне з'єднання, що називається "сеансом управління FTP" (FTP control session). За виконання команд не більше цього сеансу, передачі супутніх даних відкриваються додаткові порти. Ці зєднання може бути активними чи пасивними. Під час створення активного зєднання клент передає FTP серверу номер порту і IP адресу для зєднання. Потім клент відкриває порт, сервер підключає до заданому порD2;у клієнта свій порт з номером 20 (відомого як FTP-Data) і передає дані через встановлений з'єднання.

Проблема у цьому, що брендмаудер не знає про ці додаткових підключеннях, оскільки всю інформацію про неї передається через область даних пакета. Через це брендмаудер не дозволить серверу з'єднатися із зазначеним портом клієнта.

Рішення проблеми полягає у додаванні спеціального допоміжного модуля трасування, який відстежує, специфичную для даного протоколу, інформацію у сфері даних пакетів, що передаються у рамках сеансу управління. Під час створення такого зєднання, допоміжний модуль коректно сприйме передану інформації і створить відповідну запис в таблиці трасувальника зі стат 43;сом RELATED, завдяки чому з'єднання буде встановлено. Малюнок нижче пояснює порядок виконання подібного зєднання.

?state-tcp-server-subconn.jpg

Пасивний FTP діє протилежним чином. Клієнт посилає запит серверу отримання даних, а сервер CF;овертає клієнту IP адреса київська і номер порту для підключення. Клієнт підключає свій 20-ї порт (FTP-data) до зазначеного порту серверу та отримує запитані дані. Якщо ваша FTP сервер перебуває поза брендмаудером, то, вам знадобиться цей допоміжний модуль у тому, щоб сервер зміг обслуговувати клієнтів із Інтернет. Це ж стосується випадку, як ви хочете обмежити своїх користувачів лише можливістю підключення до HTTP і FTP серверам до Інтернету і закрити й інші порти. Малюнок нижче показує як виконується пасивне з'єднання FTP.

?state-tcp-client-subconn.jpg

Деякі допоміжні модулі вже введено до складу ядра. Якщо бути точнішим, то склад ядра включені допоміжні модулі для протоколів FTP і IRC. Якщо вашому розпорядженні немає необхідного допоміжного модуля, то, вам варто звернутися до patch-o-matic, який містить дуже багато допоміжних модулів для трасування таких протоколів, як ntalk чи H.323. Якщо й тут не знайшли те, що ви повинні, те в них є ще варіанти: ви можете звернутися до CVS iptables, якщо шуканий допоміжний модуль ще було входить у patch-o-matic, або можете ввійти у контакти з розробниками netfilter і навіть довідатися вони -- чи є такий модуль й планується він до випуску. Якщо й тут ви зазнали невдачі, то напевно вам слід прочитати [#NETFILTERHACKINGHOWTO Rusty Russell's Unreliable Netfilter Hacking HOW-TO].

Допоміжні модулі може бути зкомпільовані як у вигляді завантажувальних модулів ядра, і статично пов'язані з ядром. Якщо вони самі зкомпільовані як модулі, ви можете завантажити їх командою:

modprobe ip_conntrack_*

Зверніть увагу, що механізм визначення стану немає жодного ставлення до трансляції мережевих адрес (NAT), тому вам може знадобитися більше додаткових модулів, коли ви виконуєте таку трансляцію. Припустимо, що ви виконуєте трансляцію адрес і трассировку FTP зєднання, тоді вам необхідний також і відповідний допоміжний модуль NAT. Імена допоміжних модулів NAT розпочинаються з ip_nat, відповідно до угодою про іменах. У разі модуль називається ip_nat_ftp. Для протоколу IRC такий модуль називатиметься ip_nat_irc. Тому ж самому угоді дотримуються і назви допоміжних модулів трасувальника, наприклад: ip_conntrack_ftp і ip_conntrack_irc_.