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 |
|
|