Таблица <strong>mangle</strong> в цепочке <strong>PREROUTING</strong> - позволяет модифицировать пакет до принятия решения о маршрутизации.<br><br>
Доступны следующие действия:<br><br>
<ul><strong>TOS</strong> - Устанавливает значение поля Type of Service в заголовке IP пакета.Опция --set-tos указывает TOS-менеджеру, 
какое значение TOS устанавливать для пакетов, которые совпадают. Опция принимает числовое значение, либо в шестнадцатеричном, 
либо в десятичном виде. Поскольку значение TOS состоит из 8 бит, значение может быть 0-255, или в шестнадцатеричном виде 0x00-0xFF.<br><br>
<code>iptables -t mangle -A PREROUTING -p TCP --dport 22 -j TOS --set-tos 0x10</code><br><br>
Также, в случае IPv4 (iptables) в параметре --set-tos вы можете указать одно из допустимых символьных обозначений: 
Minimize-Delay (TOS 16, требование минимальной задержки), Maximize-Throughput (TOS 8, требование максимальной пропускной способности), 
Maximize-Reliability (TOS 4, максимальная надежность доставки), Minimize-Cost (TOS 2, минимальная стоимость), 
Normal-Service (TOS 0, специальные требования отсутствуют). В ip6tables использование этих обозначений не запрещено, 
однако в этом случае более корректным будет использование действия DSCP<br></ul>
<ul><strong>TTL</strong> - Устанавливает значение Time to Live в заголовке IP пакета.<br><br>
Следующее правило сделает ваш шлюз невидимым для большинства трассировщиков: <br><br>

<code>iptables -t mangle -I PREROUTING -j TTL --ttl-inc 1</code><br><br>

Обратите внимание, что автоматически выполняемая сетевым стеком ядра операция уменьшения TTL на единицу и проверки на равенство нулю 
выполняется после цепочки PREROUTING, но до цепочки FORWARD. Таким образом, переместив это правило в цепочку FORWARD, 
вы обеспечите «невидимость» следующего за вами шлюза.</ul>
<ul><strong>HL</strong> — изменяет поле Hop Limit в заголовке IPv6-пакета. Является аналогом IPv4-действия TTL и поддерживает те же операции</ul>
<ul><strong>MARK</strong> -  устанавливает или изменяет маркировку пакета. Имеет единственную опцию mark. Простой пример, 
который будет выделять пакеты с маркировкой 15:<br> <code>-m mark --mark 15</code><br>
Если указана маска, то перед сравнением с заданным значением маркировка каждого пакета комбинируется с этой маской 
посредством логической операции AND, то есть проверяется условие x & маска == значение (где x — маркировка текущего пакета). 
Такой подход позволит сравнивать значения отдельных бит.</ul>

<ul><strong>CONNMARK</strong> - устанавливает или изменяет маркировку соединения. Поддерживает те же опции, что и MARK, а также 
дополнительные опции --restore-mark (копирует маркировку соединения в маркировку пакета) и --save-mark (копирует маркировку пакета в маркировку соединения)<br><br>

<code>iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1</code><br><br>

Маркировка соединений позволяет классифицировать соединение в целом на основании информации об отдельном пакете. Выделив этот пакет, вы 
применяете к нему действие CONNMARK, и выбранную вами маркировку автоматически приобретают все пакеты в соединении. 
Впоследствии вы можете, например, модифицировать эти пакеты каким-либо образом, или использовать эту маркировку для маршрутизации или шейпинга пакетов. 
Таким образом, вы оперируете с соединением как с единым целым. Более того, эта маркировка автоматически копируется и на соединения, связанные с текущим.</ul>
<ul><strong>CLASSIFY</strong> - устанавливает CBQ-класс пакета для его последующей обработки шейпером (опция --set-class)</ul>
<ul><strong>ULOG</strong> -  позволяет передавать информацию об обработанных пакетах специальным демонам, таким, как ulogd</ul>
<ul><strong>NFLOG</strong> - более универсальный вариант ULOG, обеспечивающий передачу информации о пакете не напрямую 
в netlink-сокет (как это делает ULOG), а специальной подсистеме — logging backend. Например, бэкенд nfnetlink_log обеспечивает передачу данных 
в netlink-сокет, то есть с ним NFLOG работает аналогично ULOG.</ul>

<ul><strong>TCPMSS</strong> — устанавливает максимальный размер TCP-сегмента. Бывает крайне полезной при использовании VPN-подключения в том случае, 
если VPN-сервер блокирует ICMP-сообщения destination unreachable/fragmentation needed (тип 3, код 4), тем самым нарушая работу 
процедуры Path MTU discovery. С точки зрения клиента, эта проблема выглядит так: пинги проходят нормально, но при попытке открыть какую-либо веб-страницу, 
браузер «подвисает». При этом с самого шлюза все работает нормально. В этом случае достаточно применить на шлюзе следующую команду <br> <br>

<code>iptables -t mangle -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu</code><br><br>

Обратите внимание правило задаётся в цепочке <strong>FORWARD</strong> Правило обеспечит автоматическую установку размера 
сегмента в TCP-заголовках SYN- и RST,SYN-пакетов в соответствии с минимальным из известных нашему шлюзу значений MTU на пути следования пакета. 
Например, если пакет пришел с интерфейса eth0 (MTU 1500) и уходит через интерфейс ppp0 (MTU 1492), а суммарный размер заголовков сетевого и 
транспортного уровней составляет 40 байт (20 байт TCP и 20 байт IP), то целесообразно установить MSS равным 1452 байтам.<br><br>
Помимо возможности автоматического выбора TCP MSS, вы можете задать необходимое значение и вручную, используя параметр --set-mss значение. 
Это бывает полезным в том случае, если вам заведомо известно, что дальше на маршруте встречаются участки с еще меньшим MTU, а пограничные сервера этих 
участков опять же блокируют ICMP destination unreachable/fragmentation needed.</ul>

<ul><strong>TPROXY</strong> — реализует механизм полностью прозрачного проксирования. Такой подход отличается от традиционно 
используемого «прозрачного» проксирования (действие REDIRECT таблицы nat) тем, что заголовок пакета никак не модифицируется, 
в том числе не заменяется IP-адрес назначения (при традиционном прозрачном проксировании он заменяется на адрес проксирующего хоста).<br>
Кроме того, полностью прозрачное проксирование является прозрачным с точки зрения обеих общающихся сторон. Например, при проксировании 
обращений некоторой подсети клиентов к серверам из другой подсети, можно сделать так, чтобы не только клиенты считали, что обращаются напрямую к серверам, 
но и сервера «видели» настоящие исходные адреса клиентов и могли бы устанавливать с ними обратные соединения (например, в случае активного режима FTP). 
При традиционном же «прозрачном» проксировании, сервера могут видеть только адрес прокси-сервера.</ul> 

<ul><strong>TEE</strong> - это опция в iptables, которая используется для копирования пакетов из одного интерфейса в другой. Применяется в 
цепочках PREROUTING и POSTROUTING в таблице mangle.<br><br>
Когда вы используете -j TEE, вы также должны указать IP-адрес целевого узла с помощью опции --gateway. Все пакеты, 
проходящие через цепочку, где применяется это правило, будут скопированы и отправлены на указанный шлюз, но оригинальный пакет 
все равно будет передан в его исходном направлении. Это полезно, например, когда вы хотите анализировать трафик в реальном времени, не прерывая его передачу.<br><br>

<code>
iptables -t mangle -A PREROUTING -j TEE --gateway 10.0.0.1<br>
iptables -t mangle -A POSTROUTING -j TEE --gateway 10.0.0.1
</code></ul>