Различия между версиями 1 и 2
Версия 1 от 2008-07-08 21:31:47
Размер: 8837
Редактор: eSyr
Комментарий:
Версия 2 от 2008-07-09 00:02:07
Размер: 22236
Редактор: PavelSutyrin
Комментарий: такие пироги
Удаления помечены так. Добавления помечены так.
Строка 3: Строка 3:
В дкументации по iptables (iptables tutorial Андреассона в переводе Киселёва). Дстаточно неплох написана документация в плане того, что не сразу подводит к разным хитростям, и рассматривает картинку в начале. К трём задачам межсетевых украном дбавляется учёт. Она стоит особняком, поскольку он вторична к первым трём. в-вторых, задача учёта бесконечна. Мы можем называть учётом то, что количество трафика и количество сраб. разных правил, а можно пдсчитывать трафик по каждому клиенту и выставлять ему счёт.

##В выходные лектор на лориене вылжит исх. текст книжки, и все ссылки туда же.

Вот это последнее --- право манип. денеж. документами, наз. биллинг, и для этого нужна сертификация. У iptables её нет.


Iptables это возможнсть произвести все три действия на трёх уровнях в тот момент, когда сетевой пакет обрабатывается системой по трём возм. сценариям:
 * Кгда пакет приходит к нам
 * Когда пакета уходит от нас
 * Когда пакет перекладывается из одного интерфейса в другой
При этом, чт происх, когда хост сам к себе обращается? пакет перекладывается в loopback и приходит оттуда. Для удобства манип. трафиком и удобства реш. наиб. популярных задач, у этих путей есть общие части. Как выглядит вариант прохождения пакетов в трёх вариантов: бльшие блоки наз. цепчкаии, а что такое таблица, лектор расскажет чуть позже. Таким образом, если мы получили пакет в сети, мы его обрабатываем сразу, потом принимаем решение, что с ним делать дальше. Если этот пакет наш, то мы его обраб. дальше, то мы с ним что-то делаем в блке наших пакетов, иначе в блоке транз. пакетов и в конце марш., т же делается в обратном случае. Никому не заметно какой-то ассиметрии? Да, потому что марш. расп. в разных местах. И эт выливается в том, что когда мы пакет псылаем, то сначала принимает решение о маршрутизации, и только потом происх. обработка. Идея состоит в тм, что интерфейс, всё такое... Вобще, при работе с iptables надо иметь в виду, что это такое дао, котрому познать невозможно полностью. Даже сами создатели относятся к своём детищу как стихийному действу.


Правила объед. талицы, а таблицы с цепочки. Цепочки --- цепочки таблиц. поэтому ситуация... Таблицы имеют три названия (mangle, nat, filter). Таблица mangle предназначена для изменения пакетов, точенее, для изм. заголов. части. Короче гоовря, служебные поля пакетов. В табличке nat преобр. значимые поля пакетов. В табличке filter принято разм. команды, которые фильтруют пакеты. В принципЕ, можно создавать и свои собст. цепочки, которые сост. из неск. таблиц. Причина разделения одног блока обработки на неск. таблиц следующая: после того, как было написано куча всяких фаерволлов, в которых такого рода правила, а особенно правила ввида "а если не подх., то перескчить на правило такое-то, нед ай бог оно вверху", ребятч посм., какоова дисциплина. вы разм. бездну правил, которые делают следующее: а если пакет такой-то, то делать то-то. Они подумали, что существует 4 блока обработки, и есть три задачи --- модифкации, содерж. модификации (подмена ip), и задача фильтрации и перенап. в другие блоки. И что эти задачи надо разд. друг с другом. И вот тогда-то додумались о том.... блее того, лектор сильно подозревает, что даже примитивы, какие-то функции сетевые, они разные. То есть получается ситуация такая: можно предст. себе iptable как просто такой ориент. граф., сост. из 5 узлов. каждый узел --- ориент. граф, сост. в осн. из двух узлов или трёх. И каждая табличка --- список правил упорядочкенный, который работает по принципу first wins.

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

Это третья инкарнация --- до этого был ipchains, до этого --- netfilter.

Как следствие, авторы навяз. спец. дисциплину, взм. не без умысла, в которой мы не можем просм. все правила, которые прим. к пакету, а можем псм. все правила манглинга, фильтрации и перенаправления. В от с этим знанием и попр. поманип. таблицами руками. Для этог придтся пнастраивать слегка сервер.

Вот это саме предст. о том. что цепочки предст. в таблицы --- это не правильне предст. В реальности таблицы предст. внутри цепочки.
{00:19:50}

В документации по iptables (iptables tutorial Андреассона в переводе
Киселёва) (ссылка?). Достаточно неплохо написанная документация в плане
того, что не сразу подводит читателя к разным хитростям, и более или менее
описывает, что происходит в iptables.

Что такое iptables. К трём задачам: ограничение, преобразование,
перенаправление, добавляется учёт. Она стоит слегка особняком, он вторична по
отношению к первым трём,
##о, эти числительные --PavelSutyrin''
т.к. в iptables у нас что-то
ограничивается, преобразуется, перенаправляется, так вот дополнительно это всё должно
учитываться. Во-вторых, задача учета бесконечна. Мы можем называть учётом,
например, подсчёт количества пропущенного трафика и количество
срабатываний тех или иных правил, а можем учётом назвать подсчёт трафика
по каждому клиенту и на основе этого выставлять ему счёт с бумажкой, и т.п.

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

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

Iptables это возможность произвести вышеуказанные три действия на трёх с
уровнях TCP/IP, главным образом на IP, в тот момент, когда сетевой пакет обрабатывается системой по
трём возможным путям:

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

Чтое же происходит, когда хост сам к себе обращается? Пакет
перекладывается в loopback и тут же из него приходит, т.е. здесь работают
сразу первый и второй пункты этого списка.

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

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

большие блоки pre-routing, input, forward, output, post-routing
называются цепочками, а что такое таблица,
лектор расскажет чуть позже, чтобы было понятно, а не непонятно.
Таким образом, если мы получили пакет в сети, мы его обрабатываем сразу,
мы что-то с ним вообще сразу делаем,
потом мы принимаем решение, что с этим обработанным пакетом делать дальше.
Если этот пакет наш, то мы с ним что-то делаем в блоке входящих пакетов,
если он не наш, мы что-то с ним делаем в блоке обработки транзитных пакетов,
и еще делаем после-маршрутную обработку.

Тоже самое в случае, когда пакет уходит от нас. Сначала мы принимаем решение
в ... chain, потом мы его обрабатываем, потом мы его еще раз обрабатываем
(''эти пассы нужно по схеме проименовать --PavelSutyrin'').
Никому не заметно в этой схеме какой-то асимметрии? Всем довольно логичная,
но немножко асимметричная. Мы не очень привыкли воспринимать симметрию верха и
низа, потому транспонируем ее, получится ли левая сторона
симметрична правой? Про стрелочки забываем. Да, несимметрична, потому что
маршрутизация располагается в разных местах. Из этого получается такая
особенность: когда мы пакет отсылаем, то вначале принимается решение о том,
как он маршрутизируется, и только потом он обрабатывается. Довольно странная
штука, но тем не менее, по моему это так. Я долго всматривался в схемы.

Давайте проверим, зайдем мы на opennet, посмотрим документацию по iptables.
Да, действительно, решение о маршрутизации происходит сразу.

При работе iptables надо иметь в виду, что там очень много всяких особенностей, что это такое дао,
которое до конца понять нельзя. Даже его авторы относятся к нему как некоей стихийной данности.

## {00:33:00}

Моя картинка отличается от обычных картинок тем, что в ней гораздо меньше элементов.
обычно в стандартных картинках в этом месте два элемента pre-routing,
в этом месте два элемента input, два элемента forward, три элемента output, ну и так далее.

(''сопоставить бы все это, нужно порыть картинок. --PavelSutyrin'')

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

Таблица mangle предназначена для изменения пакетов,
точнее, для изменения их всякой заголовочной части, там можно Quality Of
Service всякий, type of service, TTL, скорее всего там, меняются. Короче
говоря, служебные поля пакетов искажаются в табличке mangle.

В табличке nat происходит преобразование ip-адресов, network address
translation, т.е. преобразуются уже не служебные поля, а поля значащие,
например, в первую очередь пресловутый nat.

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

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

Во-первых, они подумали, что существует 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}}}. Наверняка там ничего нет.

{{{
[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
}}}

А вот где остальные цепочки? Там их нету.. Такое я виду впервые в жизни,
непонятно, что они там накрутили. Вообще-то он по умолчанию про все таблица
выдает. Что бы нам туда такое понаставлять, чтобы протестировать это руками.

## {00:47:00}
Строка 33: Строка 241:
|| 0 || 1 || 1 || 1 || || 1 || PavelSutyrin, DmitryChistikov || || || || 20 || 1 || 1 || 1 || || 1 || PavelSutyrin, DmitryChistikov || || ||

iptables: теория

{00:19:50}

В документации по iptables (iptables tutorial Андреассона в переводе Киселёва) (ссылка?). Достаточно неплохо написанная документация в плане того, что не сразу подводит читателя к разным хитростям, и более или менее описывает, что происходит в iptables.

Что такое iptables. К трём задачам: ограничение, преобразование, перенаправление, добавляется учёт. Она стоит слегка особняком, он вторична по отношению к первым трём,

т.к. в iptables у нас что-то ограничивается, преобразуется, перенаправляется, так вот дополнительно это всё должно учитываться. Во-вторых, задача учета бесконечна. Мы можем называть учётом, например, подсчёт количества пропущенного трафика и количество срабатываний тех или иных правил, а можем учётом назвать подсчёт трафика по каждому клиенту и на основе этого выставлять ему счёт с бумажкой, и т.п.

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

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

Iptables это возможность произвести вышеуказанные три действия на трёх с уровнях TCP/IP, главным образом на IP, в тот момент, когда сетевой пакет обрабатывается системой по трём возможным путям:

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

Чтое же происходит, когда хост сам к себе обращается? Пакет перекладывается в loopback и тут же из него приходит, т.е. здесь работают сразу первый и второй пункты этого списка.

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

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

большие блоки pre-routing, input, forward, output, post-routing называются цепочками, а что такое таблица, лектор расскажет чуть позже, чтобы было понятно, а не непонятно. Таким образом, если мы получили пакет в сети, мы его обрабатываем сразу, мы что-то с ним вообще сразу делаем, потом мы принимаем решение, что с этим обработанным пакетом делать дальше. Если этот пакет наш, то мы с ним что-то делаем в блоке входящих пакетов, если он не наш, мы что-то с ним делаем в блоке обработки транзитных пакетов, и еще делаем после-маршрутную обработку.

Тоже самое в случае, когда пакет уходит от нас. Сначала мы принимаем решение в ... chain, потом мы его обрабатываем, потом мы его еще раз обрабатываем (эти пассы нужно по схеме проименовать --PavelSutyrin). Никому не заметно в этой схеме какой-то асимметрии? Всем довольно логичная, но немножко асимметричная. Мы не очень привыкли воспринимать симметрию верха и низа, потому транспонируем ее, получится ли левая сторона симметрична правой? Про стрелочки забываем. Да, несимметрична, потому что маршрутизация располагается в разных местах. Из этого получается такая особенность: когда мы пакет отсылаем, то вначале принимается решение о том, как он маршрутизируется, и только потом он обрабатывается. Довольно странная штука, но тем не менее, по моему это так. Я долго всматривался в схемы.

Давайте проверим, зайдем мы на opennet, посмотрим документацию по iptables. Да, действительно, решение о маршрутизации происходит сразу.

При работе iptables надо иметь в виду, что там очень много всяких особенностей, что это такое дао, которое до конца понять нельзя. Даже его авторы относятся к нему как некоей стихийной данности.

Моя картинка отличается от обычных картинок тем, что в ней гораздо меньше элементов. обычно в стандартных картинках в этом месте два элемента pre-routing, в этом месте два элемента input, два элемента forward, три элемента output, ну и так далее.

(сопоставить бы все это, нужно порыть картинок. --PavelSutyrin)

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

Таблица mangle предназначена для изменения пакетов, точнее, для изменения их всякой заголовочной части, там можно Quality Of Service всякий, type of service, TTL, скорее всего там, меняются. Короче говоря, служебные поля пакетов искажаются в табличке mangle.

В табличке nat происходит преобразование ip-адресов, network address translation, т.е. преобразуются уже не служебные поля, а поля значащие, например, в первую очередь пресловутый nat.

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

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

Во-первых, они подумали, что существует 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. Наверняка там ничего нет.

[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

А вот где остальные цепочки? Там их нету.. Такое я виду впервые в жизни, непонятно, что они там накрутили. Вообще-то он по умолчанию про все таблица выдает. Что бы нам туда такое понаставлять, чтобы протестировать это руками.


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

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

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

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

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

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

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)