icq через iproute2+iptables

[Mam(O)n]

Ещё одна картинка. В ней первичная маршрутизация также до цепочек.

Да сколько я не видел картинок, на них эта глупость тянется от художника к художнику. Я более склонен доверять официальным man'ам, нежли свободным писателям... Сам подумай, как может работать nat/OUTPUT после маршрутизации? А ведь без проблем можно за'dnat'ить трафик, предназначавшийся в инет, себе обратно в сеть! Такое возможно только до маршрутизации..

Если нет, то подскажи где я неправильно делаю?

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

[AnrDaemon]

Проблема не в картинке, проблема в её читателе.
Там же английским по белому нарисовано, где происходит (должна происходить) перезапись маршрутизирующей информации.

Код: [Выделить]

+-------+-------+
|    OUTPUT     |
|    ROUTING    |
+-------+-------+
        |
+-------+-------+
|    IPTABLES   |
|     OUTPUT    |
| +-----------+ |
| | conntrack |
| +-----+-----+ |
| |   mangle  | | <- MARK WRITE
| +-----+-----+ |
| |    nat    | | <-DEST REWRITE
| +-----+-----+ |     DNAT or REDIRECT
| |   filter  | |
| +-----+-----+ |
+-------+-------+
Да, вашу мать, OUTPUT ROUTING происходит до попадания пакетов на разбор в таблицы, но вы то своим умишком тоже должны соображать, что это предварительный роутинг, так сказать, настоятельные пожелания отправителя о том, куда пакет должен быть доставлен. Которые вовсе не обязательно соответствуют реалиям локальной сети. Каковые (реалии) вы вправляете в пакет в таблице nat.

[fisher74]

Не ругайся.
Я и не говорил. что пакеты не уходят куда надо, я попытался объяснить свою теорию, почему клиент не соединяется.
Считаешь что я не прав? Видишь где я ошибаюсь? Помоги, подтолкни... только не в яму
Где у меня косяк? За тем тему и создал, тем более гугл пока тоже не раскрыл сию тайну.

[AnrDaemon]

Чисто эмпирически - обратные пакеты не попадают к программе.
А конкретно - надо смотреть дампы, чтобы понять.

[Mam(O)n]

Да, вашу мать, OUTPUT ROUTING происходит до попадания пакетов на разбор в таблицы

Белым по чёрному написано в мане

Код: [Выделить]

OUTPUT (for  altering  locally-generated packets [u]before routing[/u])
и чья мать по вашему права?

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

В чем смысл этого предварительного роутинга и какую он играет роль в дальнейшем движении пакета? Почему в той диаграме указан блок т.н. предварительного роутинга и не указан блок окончательного роутинга, когда становятся известны интерфейсы назначения (-o)?

Вопросов бы не возникло, если этот блок назывался бы "source distinction", т.е. выбор адреса источника в зависимости от узла назначения в зависимости от возможного маршрута. Но на громкое "routing" это действие как то не тянет...

[AnrDaemon]

Как без роутинга определить, через какой интерфейс пакет пойдёт?
А ведь эта информация доступна в PREROUTING.

[Mam(O)n]

через какой интерфейс пакет пойдёт? А ведь эта информация доступна в PREROUTING.

sudo iptables -t nat -A PREROUTING -o eth1
iptables v1.4.4: Can't use -o with PREROUTING

Try `iptables -h' or 'iptables --help' for more information.

Вот нарыл диаграмму из документа "Linux netfilter Hacking HOWTO"

Код: (http://www.netfilter.org/documentation/HOWTO//netfilter-hacking-HOWTO-3.html#ss3.2) [Выделить]

   --->PRE------>[ROUTE]--->FWD---------->POST------>
       Conntrack    |       Mangle   ^    Mangle
       Mangle       |       Filter   |    NAT (Src)
       NAT (Dst)    |                |    Conntrack
       (QDisc)      |             [ROUTE]
                    v                |
                    IN Filter       OUT Conntrack
                    |  Conntrack     ^  Mangle
                    |  Mangle        |  NAT (Dst)
                    v                |  FilterНо все равно что то сомнения относительно output/filter
Пользователь решил продолжить мысль 24 Сентября 2010, 09:58:47:Хм. А ведь действительно, информация о исходящем интерфейсе отлично доступна в nat/OUTPUT. Захрена только она там нужна, если после все равно еще раз маршрутизируется, хз...
 
Тогда, кмк, получается так:
local process -> prerouting -> mangle/OUTPUT -> nat/OUTPUT -> routing -> filter/OUTPUT

[AnrDaemon]

Остаётся только развести руками и пожать плечами.
Сделали так... Зачем - не ведаю. Видимо, кому-то нужно было.