Сетевые технологии
NAT
Потоки трафика

Любое преобразование NAT включает в себя, как минимум, два действия: преобразование адресов и портов в первом пакете и обратное преобразование в ответном пакете. Более того, практически для любого типа полезного трафика пакетов бывает существенно больше одного и в прямом, и в обратном направлениях. Поэтому первейшая задача NAT состоит в том, чтобы выделить из всего трафика некоторую совокупность взаимосвязанных пакетов, к которым должна быть применена одна и та же пара преобразований (прямое и обратное). Такая совокупность пакетов называется потоком. Строгая интерпретация этого понятия зависит от типа трафика. Поток имеет ограниченное время жизни, по истечении которого запись из таблицы NAT удаляется. Подробное описание механизма идентификации потоков в Linux содержится в документе: Oskar Andreasson. Iptables Tutorial. Chapter 7. The state machine.

Для каждого потока создается соответствующая запись в таблице NAT, непосредственно определяющая уникальное сочетание адресов и портов источника и назначения.

Для пакетов TCP поток определяется наиболее просто, поскольку данный протокол по природе своей ориентирован на соединения. Потоком считается вся последовательность отправленных и полученных пакетов, относящихся к одному TCP-соединению, начиная от трехшаговой процедуры установления соединения (SYN — SYN/ACK — ACK) и заканчивая разрывом соединения. Между этими двумя процедурами соединение находится в состоянии ESTABLISHED и по нему передаются данные. Время жизни соединения зависит от текущей фазы соединения, в частности:

После прохождения очередного пакета отсчет времени жизни соединения начинается заново. Полный список таймаутов для различных фаз TCP-соединения, установленных по умолчанию, приведен в вышеупомянутом документе. При необходимости эти значения могут быть изменены средствами OC Linux.

Для пакетов UDP принадлежность пакетов к тому или иному потоку определяется на основе сочетания адресов и номеров портов. Время жизни потока после посылки первого пакета (т.е. пакета, который не ассоциируется ни с одним существующим потоком) — 30 секунд. Если за это время получен один ответный пакет, то поток считается установленным и время жизни увеличивается до 180 секунд. Если в течение 180 секунд не принято и не получено ни одного пакета, относящегося к данному потоку, запись о потоке уничтожается.

Для пакетов ICMP понятие потока применяется только к типам пакетов, подразумевающим парное взаимодействие Request/Reply (например, Echо Request / Echo Reply). Поток в современных ядрах Linux идентфицируется как последовательность пакетов с одинаковым идентификатором (ICMP ID). Время жизни потока — 30 секунд.

Смешанные потоки TCP/ICMP или UDP/ICMP могут возникать, например, когда в ответ на попытку установления TCP-соединения или попытку отправки UDP-датаграммы приходит пакет ICMP Host Unreachable или Network Unreachable. Такие пакеты обрабатываются по правилам ранее открытого потока TCP или UDP, соответственно. После этого запись о потоке уничтожается.

Для пакетов остальных протоколов транспортного подуровня, работающих поверх IP (например, для NETBLT, MUX или EGP) используется эвристический механизм, аналогичный UDP. Время жизни потока по умолчанию — 600 секунд.

Сложные протоколы прикладного уровня подразумевают или допускают использование одновременно нескольких портов TCP или UDP. К таким протоколам относятся FTP, TFTP, IRC и Amanda. Например, FTP использует порты TCP 21 (ftp) и 20 (ftp-data). Все такие порты учитываются и обрабатываются в рамках одного потока, но для этого должны быть включены дополнительные инструменты NAT — HELPERS ("помощники").

Для некоторых прикладных протоколов могут устанавливаться индивидуальные таймауты NAT на разных этапах взаимодействия, а также учитываться специфические типы пакетов. Это делается также с помощью HELPERS.

Многие прикладные программы и туннельные технологии используют пакеты keepalive, которые периодически передаются в отсутствие полезного трафика. Назначение этого механизма состоит не только в том, чтобы проверить, жив ли ещё партёр, но и в том, чтобы поддерживать записи NAT на промежуточных узлах в рабочем состоянии.

Обратно в узел .ip.nat...

© Network Systems Group 2015–2024 Отдел документации