Разбираюсь с iptables...

1) Не парься со всякими диаграммами

2) смотри "Порядок прохождения таблиц и цепочек"
http://gazette.linux.ru.net/rus/articles/iptables-tutorial.html#TRAVERSINGOFT...

3) Цепочка в приведенном пункте 2) это крючок к которому можно
подцепить свою цепочку, или просто добавить свои правила
(Цепочка это набор правил)

4) Встроенные Цепочки (FORWARD,POSTROUTING,...)
это своего рода интерфейс к таблицам

5) Одни и тее таблици используются в разных путях
прохождения трафика (к локальной машине, транзитные пакеты)

6) Таблицы состоят из строк, где каждая строка, насколько я понял,
содержит в себе информацию о соединение, напрмер для случая
NAT: nat-таблица содержит информацию о соединение со стороны
локальной сети и внешеним интернетом, что бы можно было
знать с какокого внешнего сокета
(сокет это комбинация ип-адреса & порта ) какому внутреннему сокету
(локальный-ип & порт) перенаправлять содержимое получаемых пакетов



Если что не так, то пускай ЛОРовцы подправят

УДАЧИ, и если ты начинающий линуксоид постарайся не
обижаться на тех кто будет ответами ущемлять твое достоинство,
к сожалению у дружественного Linux-интерфеса есть много
хамов!


ЗЫ
не хочу заниматься саморекламой, но мною написана статья
http://www.dzti.edu.lv/isp-serv/index.php?l=2
для начинающих админов, в которой максимально упрощено
материал по iptables iproute2.

Сейчас подумал насчет 6-пункта, пример с НАТ таблицей,
и подумал объяснение НАТ неудачное, поcкольку
сведения о соединениях использующих НАТ содержтсья в файле
/proc/net/ip_conntrack

Честно признаюсь что для меня тоже не совсем ясно
понятие таблиц в iptables!

Так каждая таблица (mangle,nat,filter) содержит три цепочки

postrouting
prerouting
output

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

mangle_PREROUTING-->nat_PREROUTING-->mangle_FORWARD-->
-->filter_FORWARD-->mangle_POSTROUTING-->nat_POSTROUTING

сказали бы что каждую из цепочек можно дополнить своим правилом
тогда все было бы намного яснее!

А таблицы пускай были бы описаны в самой реализации где нибудбглубооокооооооооооо, и вообще не упоминали о них,
кроме для тех кто программирует iptables

> 1) Не парься со всякими диаграммами
Но подобные мнемосхемы - это имхо самый удобный
способ представления подобных вещей. И наглядный.
Если что-то куда-то откуда-то идёт, да ещё по дороге
в третье место заворачивает - почему бы не
изобразить это графически? ;-)

> 2) смотри "Порядок прохождения таблиц и цепочек"
Скачал, думаю: распечатать - или так читать.

> 3) Цепочка в приведенном пункте 2) это крючок к которому
> можно подцепить свою цепочку, или просто добавить свои
> правила (Цепочка это набор правил).
Если я правильно понял, пользовательские цепочки
сразу после вставки никуда не цепляются. На схеме
они будут как бы отдельно.
А из существующих цепочек мы можем специальными
правилами передавать нашим цепочкам управление.
При выходе из пользовательской цепочки управление
будет передано следующему правилу (после того,
которое вызвало пользовательскую цепочку).
Верно?

> мною написана статья
> http://www.dzti.edu.lv/isp-serv/index.php?l=2
Тоже взял и в раздумье: печатать или с монитора ;-)

> ...и если ты начинающий линуксоид...
Начинающий по части разбирательств с сетью.
> ...постарайся не, обижаться на тех кто
Да уж, есть такое дело на ЛОРе. Поначалу
удивляло, теперь привык. Просто стараюсь
не заразиться этим ;-)
Кстати, спасибо за предупреждение
и подробный ответ.

> Было бы интересно услышать ответ зачем вообще ввели понятие
> таблиц, ведь легче было бы сделать больше цепочек...
Мне почему-то кажется, что таблицы - это просто не совсем
удачный способ "рассортировать" правила (или цепочки?..)
по выполняемым функциям.

> например для транзитных пакетов сделали бы следующие :
>
> mangle_PREROUTING-->nat_PREROUTING-->mangle_FORWARD-->
> -->filter_FORWARD-->mangle_POSTROUTING-->nat_POSTROUTING
В этом примере если я добавлю правило в конец
mangle_PREROUTING, а второе - в начало nat_PREROUTING,
то, ясное дело, первое выполнится перед вторым.
А в реальной жизни: если поставить одно правило
в конец цепи prerouting таблицы mangle, а второе -
в начало цепи prerouting таблицы nat, то какое
выполнится вперёд? Если я вообще ставлю вопрос
корректно ;-)

--Если я правильно понял, пользовательские цепочки
--сразу после вставки никуда не цепляются. На схеме
--они будут как бы отдельно.
при создание цепочки указывается таблица
например #iptables -t mangle -N CHK_BITTORRENT


--При выходе из пользовательской цепочки управление
--будет передано следующему правилу (после того,
--которое вызвало пользовательскую цепочку).
--Верно?
Не совсем корректно, это будет зависить от того
какие правила написаны в пользователькой цепочке,
так если есть правило -j ACCEPT то пакет закончит
свой путь хождения по всем цепочкам принадлежащим
таблице которой принадлежит цепочка,
а если -j RETURN то выйдет из цепочки и перейдет
на следующее правило за цепочкой



прохождение правил по иптаблам точно надо распечатать,
поскольку память может подвести


> mangle_PREROUTING-->nat_PREROUTING-->mangle_FORWARD-->
> -->filter_FORWARD-->mangle_POSTROUTING-->nat_POSTROUTING
- В этом примере если я добавлю правило в конец
- mangle_PREROUTING,
(в конец правила mangle_PREROUTING -- если ты занимаешся
маркировкой пактов, а маркировать пакеты необходимо
для управления трафиком ипроуте2 )

- а второе - в начало nat_PREROUTING,
(если у тебя нат-сервер то сюди ничего не надо ставить,
преобразование локальных ип-адресов в интернетовский
будет в nat_POSTROUTING)

- то, ясное дело, первое выполнится перед вторым.
все верно !

А в реальной жизни: если поставить одно правило
в конец цепи prerouting таблицы mangle (mangle_PREROUTING),
а второе - в начало цепи prerouting таблицы nat
nat_PREROUTING

все верно, сначала выполнятся правила
которые добавлены в mangle_PREROUTING
а затем которые добавлены в nat_PREROUTING

Сначала определись для каких целей ты пишешь правила,

для фаревола (вторжений из вне и атак):
смотри "Таблица 3-2. Для локального приложения"
так и есть filter_INPUT (или просто INPUT)
(iptables -A INPUT -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP)

Для ограничение кол-ва соединений пользователей ЛАН
для которых НАТ то цепочка
filter_FORWARD
( # iptables -A FORWARD -p tcp --syn -i eth1 -m connlimit --connlimit-above 15 -j REJECT )

Для преобразования локальных-ип в интернетовский-ип
msngle_P
( # iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -j SNAT -to-source xxx.xxx.xxx.gw )

Для маркировки пакетов mangle_POSTROUTING

> А в реальной жизни: если поставить одно правило
> в конец цепи prerouting таблицы mangle, а второе -
> в начало цепи prerouting таблицы nat, то какое
> выполнится вперёд?
Manual по iptables с gazette.linux.ru.net есть ? Почему тогда возникает такой вопрос ?
Срочно весь manual переписать наизусть - сразу все вопросы отпадут !
P.S. Схема движения пакетов еще есть здесь:
http://www.docum.org/docum.org/kptd/

--Manual по iptables с gazette.linux.ru.net есть ?

Лично я считаю что указанный мануал написан
ужасно отвратительно!

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

Хм... Т.е. prerouting - это не то, чтобы цепь. Точнее, 
их таких, получается, несколько? 

Можно ли считать, что таблицы - это своеобразные структуры,
и пакеты идут по цепочкам - их элементам:

mangle.PREROUTING-->nat.PREROUTING-->... ?

То бишь:

mangle_type is record:
  PREROUTING: chain;
  INPUT: chain;
  FORWARD: chain;
  OUTPUT: chain;      
  POSTROUTING: chain;
end record;
mangle: mangle_type;

И если уж я завёл речь о строках, столбцах и ячейках
таблиц iptables, то корректно ли считать,
что строки - цепочки, столбцы - порядковые номера
правил в цепочках, а ячейки -правила?

То бишь:

filter |  1  |  2  |  3  |  4  | LAST
-------+-----+-----+-----+-----|------
INPUT  |rule |rule |rule |rule |POLICY 
OUTPUT |rule |rule |rule |     |POLICY  

1. Если мы добавляем пользовательские цепочки - то в какие точки в потоке пакетов они встают?

Пользовательские цепочки - нечто вроде процедур, сами по себе они никуда не "встают". Сначала создается цепочка ("процедура"), затем в нее добавляются правида ("код процедуры"), а затем в каком-то месте эта "процедура" должна вызываться. А вот в каком - указываешь ты лично посредством команды -j CHAN_NAME

2. Где-нибудь на этой схеме не хватает маршрутизации? Насколько она вообще правильная и полная?

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

>3. Из цепочки prerouting есть два выхода: в input и в forward. От чего зависит, по какому из них пойдёт конкретный пакет?

Ответ есть в любой документации по iptables, например тут - http://www.opennet.ru/docs/RUS/iptables/

>4. Для чего было введено понятие таблиц? Разве понятия цепочек правил недостаточно?

По моему, размышления над этим вопросом могут только запутать :) Особенно, если акцентировать внимание на слове "таблица". На практике, никаких дел с собственно "табличной" постановкой вопроса обычно иметь не приходится. Хотя изначально идея выглядела где-то так:

iptables is a generic table structure for the definition of rulesets. Each rule within an IP table consists of a number of classifiers (iptables matches) and one connected action (iptables target).

(с) http://netfilter.org

>5. Таблица - это всегда столбцы, строки и ячейки. Что такое столбцы, что есть строки и что в ячейках в случае iptables?

Не стоит так ставить вопрос, ответ см. выше. Ты так только себя путаешь.

>6. Можно ли сделать с помощью iptables что-нибудь напоминающее "режим обучения" большинства виндовых межсетевых экранов?

Смотря чему обучаться. Если имеется ввиду работа с _локальными_ процессами - да, через какой-то frontend "обучить" iptables можно.

>7. Есть ли в природе софтина, которая отображала бы приведённую выше схему (с возможностью конкретизации до каждой цепочки и правила),

"Визуальных" (и не очень визуальных) постоителей правил в Инете валом, если ты об этом.

>Лично я считаю что указанный мануал написан ужасно отвратительно!

Напиши лучше, умник.

>да и то без патч-о-матик иптаблы можно отправить на свалку

Есть вариант лучше - убить себя об стену.

>Хм... Т.е. prerouting - это не то, чтобы цепь. Точнее, их таких, получается, несколько?

Для каждой таблицы.

>Можно ли считать, что таблицы - это своеобразные структуры

Можно. Если ты - разработчик netfilter :) В остальных случаях, лучше не заморачитьвася такими вещами.

>И если уж я завёл речь о строках, столбцах и ячейках таблиц iptables, то корректно ли считать, что строки - цепочки, столбцы - порядковые номера правил в цепочках, а ячейки -правила?

Типа того. Сделай iptables -nL и увидишь то же самое.

> >да и то без патч-о-матик иптаблы можно отправить на свалку
> Есть вариант лучше - убить себя об стену.

Вообще интересно иногда посмотреть чей то профиль,
например для укр-го товарища: fagot *****

его домашняя страничка в разделе "Honey patchset":
http://fine.lanet.kiev.ua/?q=node/1

выдержка из странички :
Honey patchset - это набор собранных в кучу патчей для Linux-ядра и некоторых программ (сейчас - iproute2, iptables и pppd), добавляющих им некую полезную, на мой взгляд, функциональность. А именно:

Где у самого fagot по всей видимости имеется задача использования
НАТ-сервера, и как из нее следует что самому автору чиптаблы
в его чистом виде не удовлетворяют, а конкретнее он использует

-------------
Патчи для ядра и iptables, реализующие IMQ-устройство. Также включен imq-nat патч - без него (при использовании NAT) подключать фильтры на основе IP-адресов бесполезно.
-------------

Так что не надо писать что иптаблы по умолчанию (без патчей)
есть дело полезное, так как в них fagot не нашел:
1) ограничения соединений
2) IMQ
3) pptp
4) ttl
5) mport
6) esfq

В итоге fagot сам не удовлетворен функциональностью
иптаблами без наложения на них патчей !!!


ЗЫ
сайт fagot неплохой, если бы в нем:
1) работали ссылки
2) можно было бы скачать хоть один из наборов
http://fine.lanet.kiev.ua/articles/honey/ps/hps1-2.4.32.tar.gz
(The requested URL /articles/honey/ps/hps1-2.4.32.tar.gz was not found on this server.)

3) Помимо слов, о там как хорош набор патчей, были приведены
скрипты (а не вырезки с манов) того как fagot их использует

Используя дополнительные патчи, я не утверждаю, что "без патч-о-матик иптаблы можно отправить на свалку". Мало того, что это бред и глупость, так еще и неуважение к авторам iptables (да и POM, по совместительству).

Мой сайт находится в процессе переноса, ссылки не работают временно.

>Помимо слов, о там как хорош набор патчей, были приведены скрипты (а не вырезки с манов) того как fagot их использует

За деньги - пожалуйста.

P.S В будущем, сообщения, отформатированные подобным образом (с отступом перед подписью) буду удалять. Соизволь так больше не писать.

Если бы сообщения не удалялись, а кое кто мого дочитывать строки до конца,

то оригинальное сообщение выглядело бы следующим обращом

да и то без патч-о-матик иптаблы можно отправить на свалку ДЛЯ СЛУЧАЯ НАТ СЕРВЕРА (эту цитату fagot явно решил не брать во внимание)

-->Помимо слов, о там как хорош набор патчей, --- были приведены скрипты (а не вырезки с манов) того как fagot их -- использует -- За деньги - пожалуйста Вот она хохляцкая натура :)

А вот пожалуйста мои скрипты, пользуйтесь бемплатно, если найдете что улучшить то пожалуйста... только если не влом сообщите мне об изменениях

Скрипт компиляции http://www.tmf.rtu.lv/isp/ISP-compile-2.6.18.1.sh

Скрипт конфигурации ядра http://www.tmf.rtu.lv/isp/ISP.config

Скрипты запуска http://www.tmf.rtu.lv/isp/scripts/000-ipt-clear.sh http://www.tmf.rtu.lv/isp/scripts/010-ip2mac.sh-test http://www.tmf.rtu.lv/isp/scripts/030-protect.sh http://www.tmf.rtu.lv/isp/scripts/040-connlimit.sh http://www.tmf.rtu.lv/isp/scripts/050-limit.sh http://www.tmf.rtu.lv/isp/scripts/060-snat.sh http://www.tmf.rtu.lv/isp/scripts/070-ip-sentinel.sh http://www.tmf.rtu.lv/isp/scripts/080-mark-traff.sh http://www.tmf.rtu.lv/isp/scripts/090-shape-download.sh http://www.tmf.rtu.lv/isp/scripts/100-shape-upload.sh

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

В скриптах управления скоростью сделано два корневых класса для загранки и для местного трафика.

В дальнейшем, переаботаботаю, дополню и так далее короче для более полной информации смотрите http://www.dzti.edu.lv/isp-serv/

ЗЫ fagoot --> постарайся относится ко мне более терпимо, и конечно прежде чем писать коменты на мои коментарии прочитывать предложения до конца, а не стопориться на пол предложении.

Ещё небольшой вопросик ;-) Если пакет подпал под действие REJECT, то, как я понял, он аннулируется, а в ответ на него "автору" посылается сообщение об ошибке. Так вот, это сообщение проходит как-нибудь через цепочки iptables?

Нет, не проходит.

Ну что ж - всем спасибо, теперь iptables стали для меня гораздо понятнее.