Различия между версиями 4 и 5
Версия 4 от 2008-07-09 03:53:09
Размер: 22267
Редактор: eSyr
Комментарий:
Версия 5 от 2008-07-13 13:07:10
Размер: 13232
Редактор: DmitryChistikov
Комментарий:
Удаления помечены так. Добавления помечены так.
Строка 3: Строка 3:
{00:19:50} Прежде всего --- ссылка на документацию: [[http://http://www.opennet.ru/docs/RUS/iptables/|iptables tutorial]] (Оскар Андреассон в переводе Андрея Киселева). Этот текст очень хорош: он начинает с азов и понемногу подводит читателя к сложным и интересным темам, довольно подробно описывая идущие в системе процессы.
Строка 5: Строка 5:
В документации по iptables (iptables tutorial Андреассона в переводе
Киселёва) ([[http://www.opennet.ru/docs/RUS/iptables/]]). Достаточно неплохо написанная документация в плане
того, что не сразу подводит читателя к разным хитростям, и более или менее
описывает, что происходит в iptables.
Итак, приступим. К трем задачам: ограничение, преобразование, перенаправление --- добавляется четвертая --- учет. Ее можно считать вторичной по отношению к указанным ранее, так как без них она не может существовать. Задача учета в некотором смысле бесконечна: мы можем назвать учетом, например, подсчет количества пропущенного трафика или количество срабатываний того или иного правила, а можем --- подсчет трафика по каждому клиенту (на основании этих данных мы будем выставлять клиентам счета).
Строка 10: Строка 7:
Что такое iptables. К трём задачам: ограничение, преобразование,
перенаправление, добавляется учёт. Она стоит слегка особняком, он вторична по
отношению к первым трём,
##о, эти числительные --PavelSutyrin''
т.к. в iptables у нас что-то
ограничивается, преобразуется, перенаправляется, так вот дополнительно это всё должно
учитываться. Во-вторых, задача учета бесконечна. Мы можем называть учётом,
например, подсчёт количества пропущенного трафика и количество
срабатываний тех или иных правил, а можем учётом назвать подсчёт трафика
по каждому клиенту и на основе этого выставлять ему счёт с бумажкой, и т.п.
Заметим, что с денежными расчетами ситуация особая. Одно дело --- показатели работы сетевых интерфейсов, и совсем другое --- алгоритм, по которому мы можем выписывать счета. Именно это --- право манипулировать денежными документами --- и называется биллинг. Для получения этого права нужна сертификация Роскомсвязи (?). Заметим, что сам рассматриваемый нами инструмент --- iptables --- такой сертификации не имеет (это привилегия больших программных систем, например UTM).
Строка 21: Строка 9:
А это уже биллинг. Вы понимаете, что одно дело --- наличие каких-то цифр на каких-то
интерфейсах, а другое дело --- четкий алгоритм, по которому мы можем
выписывать денежные документы. Вот это последнее --- право манипулировать
денежными документами --- называется биллинг, и для этого нужна сертификация
Роскомсвязи или чего-то такое. iptables такой сертификации не имеет, а то что
имеет такую сертификацию, это такие большие системы... UTM, да. UTM та еще
кривулька.
(''В выходные лектор на лориене выложит исходный текст книжки, и все ссылки нужно делать на нёё, чтобы локальные были'')
Строка 29: Строка 11:
(''В выходные лектор на лориене выложит исходный текст книжки, и все
ссылки нужно делать на нёё, чтобы локальные были'')
iptables позволяет производить действия указанных нами типов (большей частью --- на уровне IP). Сетевой пакет может обрабатываться нашей системой в трех возможных ситуациях:
Строка 32: Строка 13:
Iptables это возможность произвести вышеуказанные три действия на трёх с
уровнях TCP/IP, главным образом на IP, в тот момент, когда сетевой пакет обрабатывается системой по
трём возможным путям:
 * пакет приходит на нашу машину и потребляется некоторым процессом;
 * пакет производится некоторым процессом нашей машины и покидает ее;
 * пакет перекладывается из одного сетевого интерфейса в другой.
Строка 36: Строка 17:
 * Когда пакет приходит к нам, потребляется некоторым процессом нашей машины
 * Когда пакета уходит от нас, производится некоторым процессом нашей машины
 * Когда пакет перекладывается из одного сетевого интерфейса в другой
Заметим, что когда хост обращается сам к себе, пакет уходит в интерфейс loopback и тут же из него появляется (здесь работают сразу первый и второй
пункты).
Строка 40: Строка 20:
Чтое же происходит, когда хост сам к себе обращается? Пакет
перекладывается в loopback и тут же из него приходит, т.е. здесь работают
сразу первый и второй пункты этого списка.

Для удобства манипуляции сетевым трафиком и удобства решения наиболее
популярных задач, у этих трех путей пакетов есть общие части.
Как выглядит граф прохождения пакетов в трёх вариантах:
Для удобства манипуляции сетевым трафиком и решения наиболее популярных задач у этих трех "путей пакетов через хост" есть общие
части, что прекрасно видно на следующей схеме:
Строка 50: Строка 25:
большие блоки pre-routing, input, forward, output, post-routing
называются цепочками, а что такое таблица,
лектор расскажет чуть позже, чтобы было понятно, а не непонятно.
Таким образом, если мы получили пакет в сети, мы его обрабатываем сразу,
мы что-то с ним вообще сразу делаем,
потом мы принимаем решение, что с этим обработанным пакетом делать дальше.
Если этот пакет наш, то мы с ним что-то делаем в блоке входящих пакетов,
если он не наш, мы что-то с ним делаем в блоке обработки транзитных пакетов,
и еще делаем после-маршрутную обработку.
Большие блоки PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING называются цепочками. Заметим, что все возможные пути проходят хотя бы через одно принятие решения о маршрутизации, причем порядок действий для исходящих и входящих пакетов в некотором смысле несимметричен.
Строка 60: Строка 27:
Тоже самое в случае, когда пакет уходит от нас. Сначала мы принимаем решение
в ... chain, потом мы его обрабатываем, потом мы его еще раз обрабатываем
(''эти пассы нужно по схеме проименовать --PavelSutyrin'').
Никому не заметно в этой схеме какой-то асимметрии? Всем довольно логичная,
но немножко асимметричная. Мы не очень привыкли воспринимать симметрию верха и
низа, потому транспонируем ее, получится ли левая сторона
симметрична правой? Про стрелочки забываем. Да, несимметрична, потому что
маршрутизация располагается в разных местах. Из этого получается такая
особенность: когда мы пакет отсылаем, то вначале принимается решение о том,
как он маршрутизируется, и только потом он обрабатывается. Довольно странная
штука, но тем не менее, по моему это так. Я долго всматривался в схемы.
Обработка пакетов, проходящих через iptables, происходит с помощью правил. Правила объединены в таблицы, а таблицы --- в цепочки. Можно считать, что цепочки --- это именно цепочки таблиц, которые друг другу передают пакеты. Таблицы могут иметь одно из трех названий: mangle, nat, filter.
Строка 72: Строка 29:
Давайте проверим, зайдем мы на opennet, посмотрим документацию по iptables.
Да, действительно, решение о маршрутизации происходит сразу.
 ''Кажется, сейчас есть еще и raw --- проверить.'' -- DmitryChistikov <<DateTime(2008-07-13T14:07:09+0400)>>
Строка 75: Строка 31:
При работе iptables надо иметь в виду, что там очень много всяких особенностей, что это такое дао,
которое до конца понять нельзя. Даже его авторы относятся к нему как некоей стихийной данности.
Таблица mangle предназначена для преобразований в заголовках пакетов. Здесь можно изменять QoS, ToS, TTL и другие служебные параметры.
Строка 78: Строка 33:
## {00:33:00} В таблице nat происходит преобразование IP-адресов - network address translation (NAT). Это, вообще говоря, тоже изменение в заголовках, но поскольку оно затрагивает адреса отправителя и получателя (а следовательно, непосредственно влияет на решение о маршрутизации), то вынесено в отдельную таблицу.
Строка 80: Строка 35:
Моя картинка отличается от обычных картинок тем, что в ней гораздо меньше элементов.
обычно в стандартных картинках в этом месте два элемента pre-routing,
в этом месте два элемента input, два элемента forward, три элемента output, ну и так далее.
В таблице filter размещаются правила, которые занимаются собственно фильтрацией пакетов. Здесь принимаются решения о выбрасывании пакета, о перекладывании его в другую цепочку. Можно создавать и свои собственные цепочки, состоящие по умолчанию из пустых таблиц.
Строка 84: Строка 37:
(''сопоставить бы все это, нужно порыть картинок. --PavelSutyrin'') Причина разделения одного блока обработки пакетов на несколько таблиц в следующем. После того, как было написано множество различных конвейерных обработчиков данных, разработчиками был проведен анализ того, как именно используются эти конструкции. Понятно, что если есть лишь один список правил вида "если для пакета выполнено такое-то условие, то нужно выполнить такое-то действие", то работоспособность так устроенного файрвола полностью зависит от дисциплины использования.
Строка 86: Строка 39:
Обработка пакетов, проходящих через iptables, происходит с помощью правил.
Правила объединены в таблицы, а таблицы объединены цепочки.
Собственно говоря, цепочки --- это цепочки таблиц, которые друг другу
передают пакеты, поэтому ситуация, ровно как это и написано по документации...
Таблицы имеют три названия. Главных таблиц три: mangle, nat, filter.
Во-первых, было выделено 5 основных блоков, в которых происходит обработка пакетов. Во-вторых, было произведено разделение на 3 основные задачи --- служебная модификация пакетов, содержательная модификация (подмена IP-адресов) и фильтрация. Эти задачи соответствуют таблицам iptables, а блоки обработки --- основным цепочкам.
Строка 92: Строка 41:
Таблица mangle предназначена для изменения пакетов,
точнее, для изменения их всякой заголовочной части, там можно Quality Of
Service всякий, type of service, TTL, скорее всего там, меняются. Короче
говоря, служебные поля пакетов искажаются в табличке mangle.
Итак, устройство iptables можно представить в виде ориентированного графа с пятью вершинами (это цепочки). Каждая вершина --- тоже ориентированный граф, в котором обыкновенно две или три вершины (таблицы). Каждая таблица --- упорядоченный набор (список) правил вида "если для пакета выполняется такое-то условие, сделать то-то" (по сути дела, пар "условие --- действие"). Перемещение осуществляется следующим образом: последовательно проверяются все условия, причем как только одно из них выполнено, немедленно применяется соответствующее действие. Если при этом пакет продолжает свое путешествие (он не был выброшен или, наоборот, принят в данной таблице) то будут проверяться следующие условия и так далее. При выходе из таблицы пакет переходит в следующую таблицу, а при выходе из всех таблиц цепочки --- в следующую цепочку. Принятие пакета в одной из таблиц также означает переход к следующей.
Строка 97: Строка 43:
В табличке nat происходит преобразование ip-адресов, network address
translation, т.е. преобразуются уже не служебные поля, а поля значащие,
например, в первую очередь пресловутый nat.
К сожалению, разработчики iptables при описании своего продукта обычно излагают внутреннее его устройство. Поэтому в документации (в том числе и в iptables tutorial) принято другое соглашение о логической структуре: цепочки объединяются в таблицы (таблица --- это группа цепочек одного типа, расположенных в разных местах). Понятно, что такая договоренность относится лишь к способу представления, но не к функционированию файрвола. Заметим, однако, что команд типа "показать по порядку все правила всех типов для исходящих пакетов" в стандартной поставке нет.
Строка 101: Строка 45:
В табличке filter принято размещать команды, которые фильтруют пакеты,
т.е. которые принимают решение о выбрасывании пакета, о перекидывании его в
другую цепочку, или что-то еще. В принципе, можно создавать и свои собственные.
цепочки, которые по умолчанию состоят из нескольких таблиц, пустых.
Заметим, что можно встретить иное название этой же системы --- netfilter. Так по традиции называется соответствующая часть ядра. Можно считать также, что это оригинальное название первого поколения сетевого фильтра. После netfilter использовалась система ipchains, которую называют сетевым фильтром второго поколения, iptables же --- название третьего поколения. В последнее время название iptables более распространено и почти всегда означает не только утилиту управления, но и всю систему в целом.
Строка 106: Строка 47:
Причина разделения одного блока обработки пакетов на
несколько таблиц следующая: после того, как было написано куча всяких
фаерволлов, предыдущих, самодельных,
в которых такого рода правила, а особенно правила
вида "а если не подходит, то перескочить на правило такое-то, не дай
Бог оно окажется вверху", после того, как было написано много-много такого
рода конвейерных обработчиков данных, которые превращали наш интернет-траффик в
полное месиво, неработоспособное вообще, ребята посмотрели, какова вообще
дисциплина. Представьте, что у вас есть всего один список, в котором вы
размещаете бездну правил, каждое из которых выглядит следующим образом:
первая часть --- условие, "если пакет такой-то" вторая часть --- действие с
пакетом, если условие выполнено, т.е. "делать то-то". И таких правил в столбик
несколько тысяч. И вы от руки добавляете произвольные правила в любое место.
С таким способом сделать файрвол неработоспособным очень легко. Народ начал
задумываться, а какова дисциплина.

Во-первых, они подумали, что существует 4 основных блока обработки, где можно
с пакетами что-то делать, и во-вторых, что есть три задачи --- служебной
модификации пакетов, задача содержательной модификации (в основном связана с
подменой ip-адресов), и задача фильтрации и перенаправления в другие блоки.

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

лектор сильно подозревает, что даже примитивы, какие-то
функции сетевые, которые используются в табличках типа mangle, nat, и filter
--- они разные. Там разное хочется от пакета.

То есть получается ситуация такая: можно себе представить себе iptables
как просто такой ориентированный граф, состоящий из
5 узлов. каждый узел --- тоже ориентированный граф, состоящий в основном
из двух узлов или трёх, в зависимости от количества табличек, входящих в
соотв. цепочку. И, наконец, каждая табличка --- даже не ориентированный граф,
а упорядоченный список правил,
там даже нельзя перепрыгнуть на правило номер столько-то, а можно
перепрыгнуть только на другую цепочку, который работает по принципу first
wins, как только условие на пакет выполняется, над ним выполняется то
действие, которое прописано в соотв. строке, после чего в данной табличке он
обрабатываться перестает и мы начинаем путешествовать по графу, переходим в
следующую табличку, а если табличка пустая, то переходим в следующую цепочку,
если, конечно, решение относительно пакета не было "отбросить", в этом случае
он больше никем обрабатываться не будет.

К сожалению, разработчики iptables, когда описывали iptables, излагали частично
то, как он реализован. Поэтому во всей документации, вы можете прочесть,
написано то, что вы, Дима, говорили вчера ([[../080707/04RoutingTheory]])
что цепочки объединены в таблицы. На самом, это ниоткуда не следует. На самом
деле, наоборот. В реальности, происходит следующее: есть
специальный блок, который занимается mangle'ингом, и вот таблицы такого
типа, mangling, вставляются сюда, сюда, сюда, повсюду. Есть специальный блок,
который занимается nat'ом, и таблицы nat вставляются сюда, ну и так далее.
Хуже всего, с моей точки зрения, как человека, который первый файрволл,
который настраивал, был ipfw, что даже команды такой --- посмотреть все
правила iptables в том порядке, в котором их проходит пакет --- такой команды
просто нет. Ни штатной, ни какой-то еще. Может быть есть какой-то специальный
пакет, который показывает все правила iptables в виде дерева.
(Он показывает все правила по исполнителям), вот-вот-вот, начинаются
извращения, вы же понимаете. Ни графа нету, ни даже способа показать все
правила, через которые проходит пакет при прохождении iptable в зависимости от
его типа, даже такого нет. Но три разных вида таких линейных списков, большой
граф у нас имеет всего три пути, у него два истока, два стока, всё.

netfilter -- это старое название, которое относится к каким-то старым
компонентам. Все вместе называется iptables, включая утилиту управления и
ядерную часть. Это уже не первая, а третья инкарнация сетевых фильтров, до
этого был, до этого был ipchains, до этого --- netfilter. Но netfilter были
все разрозненное, это была такие зачатки, патчи в ядре, которые что-то делали
с пакетами. Как они управлялись, я не помню, тогда я к линуксу не подходил, я
ipchains-то и не трогал особо, он был еще более мутный.

В итоге, авторы, возможно не без умысла, навязывают нам специальную дисциплину
просмотра всех правил в этом массиве, которая сводится к тому, что мы не можем
посмотреть все правила вообще, который пройдёт пакет той или иной судьбы,
а можем только посмотреть только все правила, которые будут производится в нем
в смысле mangle'инга, в смысле nat'инга и в смысле filter'инга. Теперь по
русски: служебная модификация, содержательная модификация и
фильрация-перенаправление. Вот с этими знаниями попробуем поманипулировать
этими таблицами руками.

Видимо, придётся понастраивать слегка сервер.

Вот это самое представление о том. что цепочки объединяются в таблицы --- это
не правильное представление, они не объединяются в таблица. Может быть, это
детали русского перевода. В реальности таблицы объединяются внутри цепочки.
Проще представлять себе это как множество таблиц типа mangle, множество таблиц
типа nat, множество таблиц типа filter, объединенных в нужных местах в
цепочки. К сожалению, я, кажется, единственный человек, который говорит именно
так, потому что куда ни плюнь, везде написано то, что вы, Дим, вчера говорили,
и глядя на это, абсолютно перестаешь понимать, что на самом деле происходит, я
перестаю, по крайней мере, вчера я перестал.

Ну что, скажем {{{iptables-save}}}. Наверняка там ничего нет.
Посмотрим теперь, какие правила действуют сейчас в нашей системе:
Строка 201: Строка 50:
[root@demo net]# iptables-save 
# Generated by iptables-save v1.3.7 on Tue Jul 8 18:17:08 2008
  
*mangle
  :PREROUTING ACCEPT [428:365625]
  :INPUT ACCEPT [394:361829]
  :FORWARD ACCEPT [7:296]
  :OUTPUT ACCEPT [278:27722]
  
:POSTROUTING ACCEPT [361:43691]
  COMMIT
# Completed on Tue Jul 8 18:17:08 2008
# Generated by iptables-save v1.3.7 on Tue Jul 8 18:17:08 2008
  
*nat
  :PREROUTING ACCEPT [36:4238]
  :POSTROUTING ACCEPT [30:2757]
  :OUTPUT ACCEPT [29:2705]
  -A POSTROUTING -o eth0 -j SNAT --to-source 10.0.2.15
  
COMMIT
# Completed on Tue Jul 8 18:17:08 2008
# Generated by iptables-save v1.3.7 on Tue Jul 8 18:17:08 2008
  
*filter
  :INPUT ACCEPT [65:29557]
  :FORWARD ACCEPT [7:296]
  :OUTPUT ACCEPT [69:10645]
  :stdin - [0:0]
  COMMIT
# Completed on Tue Jul 8 18:17:08 2008
[root@demo net]# iptables-save
# Generated by iptables-save v1.3.7 on Tue Jul 8 18:13:06 2008
*mangle
:PREROUTING ACCEPT [428:365625]
:INPUT ACCEPT [394:361829]
:FORWARD ACCEPT [7:296]
:OUTPUT ACCEPT [278:27722]
:POSTROUTING ACCEPT [361:43691]
COMMIT
# Completed on Tue Jul 8 18:13:06 2008
# Generated by iptables-save v1.3.7 on Tue Jul 8 18:13:06 2008
*nat
:PREROUTING ACCEPT [36:4238]
:POSTROUTING ACCEPT [30:2757]
:OUTPUT ACCEPT [29:2705]
COMMIT
# Completed on Tue Jul 8 18:13:06 2008
# Generated by iptables-save v1.3.7 on Tue Jul 8 18:13:06 2008
*filter
:INPUT ACCEPT [65:29557]
:FORWARD ACCEPT [7:296]
:OUTPUT ACCEPT [69:10645]
:stdin - [0:0]
COMMIT
# Completed on Tue Jul 8 18:13:06 2008
Строка 229: Строка 77:
А вот где остальные цепочки? Там их нету.. Такое я вижу впервые в жизни,
непонятно, что они там накрутили. Вообще-то он по умолчанию про все таблица
выдает. Что бы нам туда такое понаставлять, чтобы протестировать это руками.

## {00:47:00}
Как видно, в настоящее время пользовательских правил нет.

iptables: теория

Прежде всего --- ссылка на документацию: iptables tutorial (Оскар Андреассон в переводе Андрея Киселева). Этот текст очень хорош: он начинает с азов и понемногу подводит читателя к сложным и интересным темам, довольно подробно описывая идущие в системе процессы.

Итак, приступим. К трем задачам: ограничение, преобразование, перенаправление --- добавляется четвертая --- учет. Ее можно считать вторичной по отношению к указанным ранее, так как без них она не может существовать. Задача учета в некотором смысле бесконечна: мы можем назвать учетом, например, подсчет количества пропущенного трафика или количество срабатываний того или иного правила, а можем --- подсчет трафика по каждому клиенту (на основании этих данных мы будем выставлять клиентам счета).

Заметим, что с денежными расчетами ситуация особая. Одно дело --- показатели работы сетевых интерфейсов, и совсем другое --- алгоритм, по которому мы можем выписывать счета. Именно это --- право манипулировать денежными документами --- и называется биллинг. Для получения этого права нужна сертификация Роскомсвязи (?). Заметим, что сам рассматриваемый нами инструмент --- iptables --- такой сертификации не имеет (это привилегия больших программных систем, например UTM).

(В выходные лектор на лориене выложит исходный текст книжки, и все ссылки нужно делать на нёё, чтобы локальные были)

iptables позволяет производить действия указанных нами типов (большей частью --- на уровне IP). Сетевой пакет может обрабатываться нашей системой в трех возможных ситуациях:

  • пакет приходит на нашу машину и потребляется некоторым процессом;
  • пакет производится некоторым процессом нашей машины и покидает ее;
  • пакет перекладывается из одного сетевого интерфейса в другой.

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

Для удобства манипуляции сетевым трафиком и решения наиболее популярных задач у этих трех "путей пакетов через хост" есть общие части, что прекрасно видно на следующей схеме:

(сюда бы картинку! Во вложениях к лекции пусто, ждём выкладки книжки?.. --PavelSutyrin)

Большие блоки PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING называются цепочками. Заметим, что все возможные пути проходят хотя бы через одно принятие решения о маршрутизации, причем порядок действий для исходящих и входящих пакетов в некотором смысле несимметричен.

Обработка пакетов, проходящих через iptables, происходит с помощью правил. Правила объединены в таблицы, а таблицы --- в цепочки. Можно считать, что цепочки --- это именно цепочки таблиц, которые друг другу передают пакеты. Таблицы могут иметь одно из трех названий: mangle, nat, filter.

  • Кажется, сейчас есть еще и raw --- проверить. -- DmitryChistikov 2008-07-13 13:07:09

Таблица mangle предназначена для преобразований в заголовках пакетов. Здесь можно изменять QoS, ToS, TTL и другие служебные параметры.

В таблице nat происходит преобразование IP-адресов - network address translation (NAT). Это, вообще говоря, тоже изменение в заголовках, но поскольку оно затрагивает адреса отправителя и получателя (а следовательно, непосредственно влияет на решение о маршрутизации), то вынесено в отдельную таблицу.

В таблице filter размещаются правила, которые занимаются собственно фильтрацией пакетов. Здесь принимаются решения о выбрасывании пакета, о перекладывании его в другую цепочку. Можно создавать и свои собственные цепочки, состоящие по умолчанию из пустых таблиц.

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

Во-первых, было выделено 5 основных блоков, в которых происходит обработка пакетов. Во-вторых, было произведено разделение на 3 основные задачи --- служебная модификация пакетов, содержательная модификация (подмена IP-адресов) и фильтрация. Эти задачи соответствуют таблицам iptables, а блоки обработки --- основным цепочкам.

Итак, устройство iptables можно представить в виде ориентированного графа с пятью вершинами (это цепочки). Каждая вершина --- тоже ориентированный граф, в котором обыкновенно две или три вершины (таблицы). Каждая таблица --- упорядоченный набор (список) правил вида "если для пакета выполняется такое-то условие, сделать то-то" (по сути дела, пар "условие --- действие"). Перемещение осуществляется следующим образом: последовательно проверяются все условия, причем как только одно из них выполнено, немедленно применяется соответствующее действие. Если при этом пакет продолжает свое путешествие (он не был выброшен или, наоборот, принят в данной таблице) то будут проверяться следующие условия и так далее. При выходе из таблицы пакет переходит в следующую таблицу, а при выходе из всех таблиц цепочки --- в следующую цепочку. Принятие пакета в одной из таблиц также означает переход к следующей.

К сожалению, разработчики iptables при описании своего продукта обычно излагают внутреннее его устройство. Поэтому в документации (в том числе и в iptables tutorial) принято другое соглашение о логической структуре: цепочки объединяются в таблицы (таблица --- это группа цепочек одного типа, расположенных в разных местах). Понятно, что такая договоренность относится лишь к способу представления, но не к функционированию файрвола. Заметим, однако, что команд типа "показать по порядку все правила всех типов для исходящих пакетов" в стандартной поставке нет.

Заметим, что можно встретить иное название этой же системы --- netfilter. Так по традиции называется соответствующая часть ядра. Можно считать также, что это оригинальное название первого поколения сетевого фильтра. После netfilter использовалась система ipchains, которую называют сетевым фильтром второго поколения, iptables же --- название третьего поколения. В последнее время название iptables более распространено и почти всегда означает не только утилиту управления, но и всю систему в целом.

Посмотрим теперь, какие правила действуют сейчас в нашей системе:

[root@demo net]# iptables-save
# Generated by iptables-save v1.3.7 on Tue Jul  8 18:13:06 2008
*mangle
:PREROUTING ACCEPT [428:365625]
:INPUT ACCEPT [394:361829]
:FORWARD ACCEPT [7:296]
:OUTPUT ACCEPT [278:27722]
:POSTROUTING ACCEPT [361:43691]
COMMIT
# Completed on Tue Jul  8 18:13:06 2008
# Generated by iptables-save v1.3.7 on Tue Jul  8 18:13:06 2008
*nat
:PREROUTING ACCEPT [36:4238]
:POSTROUTING ACCEPT [30:2757]
:OUTPUT ACCEPT [29:2705]
COMMIT
# Completed on Tue Jul  8 18:13:06 2008
# Generated by iptables-save v1.3.7 on Tue Jul  8 18:13:06 2008
*filter
:INPUT ACCEPT [65:29557]
:FORWARD ACCEPT [7:296]
:OUTPUT ACCEPT [69:10645]
:stdin - [0:0]
COMMIT
# Completed on Tue Jul  8 18:13:06 2008

Как видно, в настоящее время пользовательских правил нет.


Сведения о ресурсах

Готовность (%)

Продолжительность (ак. ч.)

Подготовка (календ. ч.)

Полный текст (раб. д.)

Предварительные знания

Level

Maintainer

Start date

End date

20

1

1

1

1

PavelSutyrin, DmitryChistikov


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex

PspoClasses/080708/01IptablesTheory (последним исправлял пользователь MaximByshevskiKonopko 2008-10-09 21:31:29)