-
Notifications
You must be signed in to change notification settings - Fork 1
/
prerouting-mangle-descr
74 lines (63 loc) · 11.6 KB
/
prerouting-mangle-descr
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
Таблица <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>