[Sysadmins] два шлюза и проброс во внутреннюю сеть

[Sysadmins] два шлюза и проброс во внутреннюю сеть

[altlinux]

всем привет!
есть два шлюза в инет (канал U и канал S) и сервер во внутренней сети на 
котором есть ftp. Нужно обеспечить доступ к ftp с этих двух каналов. 
Шлюзом по умолчанию является канал U. Если я с инета пытаюсь соединиться 
через канал S то пакеты доходят до внутреннего ftp, но возращаются не 
через канал S, а через шлюз по умолчанию т.е. U.
проброс осуществляется
$IPTABLES -t nat -A PREROUTING -p TCP -d $EXTERNAL_U_ADDRESS --dport 21 
-j DNAT --to-destination 192.168.100.8:21
$IPTABLES -t nat -A PREROUTING -p TCP -d $EXTERNAL_S_ADDRESS --dport 21 
-j DNAT --to-destination 192.168.100.8:21
Как можно решить эту проблему.

Re: [Sysadmins] два шлюза и проброс во внутреннюю сеть

[Peter V. Saveliev]

On Wednesday 31 October 2007, altlinux@aaanet.ru wrote:
> всем привет!
> есть два шлюза в инет (канал U и канал S) и сервер во внутренней сети на
> котором есть ftp. Нужно обеспечить доступ к ftp с этих двух каналов.
> Шлюзом по умолчанию является канал U. Если я с инета пытаюсь соединиться
> через канал S то пакеты доходят до внутреннего ftp, но возращаются не
> через канал S, а через шлюз по умолчанию т.е. U.
> проброс осуществляется
> $IPTABLES -t nat -A PREROUTING -p TCP -d $EXTERNAL_U_ADDRESS --dport 21
> -j DNAT --to-destination 192.168.100.8:21
> $IPTABLES -t nat -A PREROUTING -p TCP -d $EXTERNAL_S_ADDRESS --dport 21
> -j DNAT --to-destination 192.168.100.8:21
> Как можно решить эту проблему.
>

в идеале -- самое простое -- это иметь по интерфейсу к каждому из шлюзов. 
Тогда:

ip route add default via S table S
ip route add default via U table U
ip route add default via U table main
ip rule add dev ethS table S
ip rule add dev ethU table U

Эта схема опробована и работает на мэйл-сервере, который глядит в две разных 
AS.

Возможно, что можно следить и не по интерфейсам, а по меткам, но это не 
пробовал, а с интерфейсами работает.

-- 
Peter V. Saveliev

Re: [Sysadmins] два шлюза и проброс во внутреннюю сеть

[altlinux]

а у вас этот почтовик на самом сервере или в локальной сети?
если сервис на самом сервере проблем нет, а вот с пробросом во 
внутреннюю сеть .....
> On Wednesday 31 October 2007, altlinux@aaanet.ru wrote:
>   
>> всем привет!
>> есть два шлюза в инет (канал U и канал S) и сервер во внутренней сети на
>> котором есть ftp. Нужно обеспечить доступ к ftp с этих двух каналов.
>> Шлюзом по умолчанию является канал U. Если я с инета пытаюсь соединиться
>> через канал S то пакеты доходят до внутреннего ftp, но возращаются не
>> через канал S, а через шлюз по умолчанию т.е. U.
>> проброс осуществляется
>> $IPTABLES -t nat -A PREROUTING -p TCP -d $EXTERNAL_U_ADDRESS --dport 21
>> -j DNAT --to-destination 192.168.100.8:21
>> $IPTABLES -t nat -A PREROUTING -p TCP -d $EXTERNAL_S_ADDRESS --dport 21
>> -j DNAT --to-destination 192.168.100.8:21
>> Как можно решить эту проблему.
>>
>>     
>
> в идеале -- самое простое -- это иметь по интерфейсу к каждому из шлюзов. 
> Тогда:
>
> ip route add default via S table S
> ip route add default via U table U
> ip route add default via U table main
> ip rule add dev ethS table S
> ip rule add dev ethU table U
>
> Эта схема опробована и работает на мэйл-сервере, который глядит в две разных 
> AS.
>
> Возможно, что можно следить и не по интерфейсам, а по меткам, но это не 
> пробовал, а с интерфейсами работает.
>
>   

Re: [Sysadmins] два шлюза и проброс во внутреннюю сеть

[Peter V. Saveliev]

В сообщении от Thursday 01 November 2007 10:25:21 altlinux@aaanet.ru 
написал(а):
> а у вас этот почтовик на самом сервере или в локальной сети?

Да, сам сервер двумя внешними ip/24 глядит через два разных раутера в две 
разные автономные системы.

> если сервис на самом сервере проблем нет, а вот с пробросом во
> внутреннюю сеть .....

Вообще говоря, есть трансанальный воркэраунд для такого случая. Поток с одного 
провайдера на mail-сервер заворачиваем в один vlan, с другого -- в другой. На 
самом mail-сервере имеем абсолютно ту же картинку, что я и описал: ip rule по 
интерфейсам (vlan-интерфейсы) в разные таблицы.

Если честно, я ещё не смотрел, почему ядро разворачивает _исходящий_ поток 
через таблицу на основании интерфейса _входящего_ потока, но тем не ме, 
работает (если ещё не починили ;) или не починят в будущем)

<skip />

-- 
Peter V. Saveliev

Re: [Sysadmins] два шлюза и проброс во внутреннюю сеть

[altlinux]

сервак на который происходит проброс под windows.
1. не подскажите, а поможет ли мне если я на сервере(шлюзе) добавлю алиас IP адрес и добавлю таблицу маршрутов для этих адресов и на сервере на который осуществляется проброс добавить алиас IP адрес, вместо отдельных сетей/vlan.
2. и еще один вопрос, нет ли какого нибудь TCP прокси который бы пробрасывал трафик, который мог бы заменить dnat 


> В сообщении от Thursday 01 November 2007 10:25:21 altlinux@aaanet.ru 
> написал(а):
>   
>> а у вас этот почтовик на самом сервере или в локальной сети?
>>     
>
> Да, сам сервер двумя внешними ip/24 глядит через два разных раутера в две 
> разные автономные системы.
>
>   
>> если сервис на самом сервере проблем нет, а вот с пробросом во
>> внутреннюю сеть .....
>>     
>
> Вообще говоря, есть трансанальный воркэраунд для такого случая. Поток с одного 
> провайдера на mail-сервер заворачиваем в один vlan, с другого -- в другой. На 
> самом mail-сервере имеем абсолютно ту же картинку, что я и описал: ip rule по 
> интерфейсам (vlan-интерфейсы) в разные таблицы.
>
> Если честно, я ещё не смотрел, почему ядро разворачивает _исходящий_ поток 
> через таблицу на основании интерфейса _входящего_ потока, но тем не ме, 
> работает (если ещё не починили ;) или не починят в будущем)
>
> <skip />
>
>   

Re: [Sysadmins] два шлюза и проброс во внутреннюю сеть

[Peter V. Saveliev]

В сообщении от Friday 02 November 2007 08:57:36 altlinux@aaanet.ru написал(а):
> сервак на который происходит проброс под windows.

Час от часу не легче :))

Короче, Вы можете разгребать ответы в ту же AS, откуда были запросы, но для 
этого Вам нужно знать или хранить, откуда эти запросы таки пришли. Если 
сервис не на самом шлюзе, тогда у routing engine просто нет шансов узнать, к 
какому запросу относится ответ, не залезая в connection tracking. А туда оно 
лазить не умеет, iirc.

Поскольку перед нами не стоит задачи научить rpdb смотреть в таблицы 
connection tracking (что было бы нарушением иерархии протоколов -- ip не 
должен ничего знать про вышележащее (что не мешает tcp нарушать иерархию, 
однако, но опустим этот момент)), самое простое -- изолировать траффик. Можно 
раскидать на разные интерфейсы, разные vlan или разные ip.

> 1. не подскажите, а поможет ли мне если я на сервере(шлюзе) добавлю алиас
> IP адрес и добавлю таблицу маршрутов для этих адресов и на сервере на
> который осуществляется проброс добавить алиас IP адрес, вместо отдельных
> сетей/vlan.

Может сработать.

> 2. и еще один вопрос, нет ли какого нибудь TCP прокси который 
> бы пробрасывал трафик, который мог бы заменить dnat

# apt-cache show simpleproxy
Package: simpleproxy
<skip />
Description: Simple TCP/IP proxy
 Simpleproxy program acts as simple TCP proxy. It listens on a local
 socket, and any connection to this port will be forwarded to another
 socket at the remote host. It can also use an HTTPS proxy server to
 forward connections, and can be configured via command line as well as a
 config file.

Ну, есть ещё xinetd.

<skip />

-- 
Peter V. Saveliev

Re: [Sysadmins] два шлюза и проброс во внутреннюю сеть

[altlinux]

Большое спасибо !!!
буду теперь решать проблему, единственно непонял чем мне xinetd может 
помочь, извиняюсь за незнание.
> В сообщении от Friday 02 November 2007 08:57:36 altlinux@aaanet.ru написал(а):
>   
>> сервак на который происходит проброс под windows.
>>     
>
> Час от часу не легче :))
>
> Короче, Вы можете разгребать ответы в ту же AS, откуда были запросы, но для 
> этого Вам нужно знать или хранить, откуда эти запросы таки пришли. Если 
> сервис не на самом шлюзе, тогда у routing engine просто нет шансов узнать, к 
> какому запросу относится ответ, не залезая в connection tracking. А туда оно 
> лазить не умеет, iirc.
>
> Поскольку перед нами не стоит задачи научить rpdb смотреть в таблицы 
> connection tracking (что было бы нарушением иерархии протоколов -- ip не 
> должен ничего знать про вышележащее (что не мешает tcp нарушать иерархию, 
> однако, но опустим этот момент)), самое простое -- изолировать траффик. Можно 
> раскидать на разные интерфейсы, разные vlan или разные ip.
>
>   
>> 1. не подскажите, а поможет ли мне если я на сервере(шлюзе) добавлю алиас
>> IP адрес и добавлю таблицу маршрутов для этих адресов и на сервере на
>> который осуществляется проброс добавить алиас IP адрес, вместо отдельных
>> сетей/vlan.
>>     
>
> Может сработать.
>
>   
>> 2. и еще один вопрос, нет ли какого нибудь TCP прокси который 
>> бы пробрасывал трафик, который мог бы заменить dnat
>>     
>
> # apt-cache show simpleproxy
> Package: simpleproxy
> <skip />
> Description: Simple TCP/IP proxy
>  Simpleproxy program acts as simple TCP proxy. It listens on a local
>  socket, and any connection to this port will be forwarded to another
>  socket at the remote host. It can also use an HTTPS proxy server to
>  forward connections, and can be configured via command line as well as a
>  config file.
>
> Ну, есть ещё xinetd.
>
> <skip />
>
>   

Re: [Sysadmins] два шлюза и проброс во внутреннюю сеть

[Peter V. Saveliev]

В сообщении от Friday 02 November 2007 10:36:14 altlinux@aaanet.ru написал(а):
> Большое спасибо !!!
> буду теперь решать проблему,

Главное, напишите, как решилось. Или не решилось, и будем пытацо решить 
дальше.

> единственно непонял чем мне xinetd может 
> помочь, извиняюсь за незнание.

Ой, ну как же. Читаем man xinetd.conf, ищем строчку redirect. Но вообще, 
simpleproxy может оказаться проще.

<skip />


-- 
Peter V. Saveliev

Re: [Sysadmins] два шлюза и проброс во внутреннюю сеть

[altlinux]

simpleproxy 
решил проблему за 5 мин
спасибо большое!!!

> В сообщении от Friday 02 November 2007 10:36:14 altlinux@aaanet.ru написал(а):
>   
>> Большое спасибо !!!
>> буду теперь решать проблему,
>>     
>
> Главное, напишите, как решилось. Или не решилось, и будем пытацо решить 
> дальше.
>
>   
>> единственно непонял чем мне xinetd может 
>> помочь, извиняюсь за незнание.
>>     
>
> Ой, ну как же. Читаем man xinetd.conf, ищем строчку redirect. Но вообще, 
> simpleproxy может оказаться проще.
>
> <skip />
>
>
>   

Re: [Sysadmins] два шлюза и проброс во внутреннюю сеть

[Peter V. Saveliev]

В сообщении от Friday 02 November 2007 13:43:53 altlinux@aaanet.ru написал(а):
> simpleproxy
> решил проблему за 5 мин
> спасибо большое!!!
<skip />

не за что :)

то есть, схема теперь такая, я правильно понял:


             /-------------------------------------\        /------------\
uplink S --->+ ip rule dev S table S               |        | win mail   |
.            |          service simpleproxy tcp:25 +------->+ server     |
uplink U --->+ ip rule dev U table U               |        |            |
             \-------------------------------------/        \------------/

? или проще ?

ЗЫ: если simpleproxy на 25 порту из-под рута, то тогда имеет смысл также 
подумать, не посадить ли его на 2225 порт + редирект, но при этом не из-под 
рута -- чорт его знает, какие в simpleproxy могут быть переполнения...

-- 
Peter V. Saveliev

Re: [Sysadmins] два шлюза и проброс во внутреннюю сеть

[altlinux]

DNAT для uplink U  а на uplink S повесил simpleproxy
>                                           /----------------------\        /------------\
> uplink S - service simpleproxy ExtIp:port|                       |        | win mail   |
> .                                        |                       +------->+ server     |
> uplink U --->                            + ip rule dev U table U |        |            |
>                                           \----------------------/        \------------/
>   

Re: [Sysadmins] два шлюза и проброс во внутреннюю сеть

[Serge]

> simpleproxy
> решил проблему за 5 мин
> спасибо большое!!!
я так и не понял, почему DNAT не устроил, поясните плиз

Re: [Sysadmins] два шлюза и проброс во внутреннюю сеть

[Peter V. Saveliev]

В сообщении от Friday 02 November 2007 17:18:23 Serge написал(а):
> > simpleproxy
> > решил проблему за 5 мин
> > спасибо большое!!!
>
> я так и не понял, почему DNAT не устроил, поясните плиз
>
При наличии двух аплинков возникает проблема двух умолчательных шлюзов. 
Потенциально, запрос с внешнего адреса Ы может придти через любой из 
аплинков, и ответить надо именно через тот шлюз, через который пришёл запрос, 
ибо асимметричный раутинг иногда работает совсем не так, как ожидалось.

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

-- 
Peter V. Saveliev

Re: [Sysadmins] два шлюза и проброс во внутреннюю сеть

[Alexey I. Froloff]

[-- Attachment #1: Type: text/plain, Size: 469 bytes --]

* Peter V. Saveliev <peet@> [071102 17:49]:
> При использовании DNAT нет бескровного способа выяснить, через
> какой шлюз пришёл запрос, на который сейчас идёт ответ из
> внутренней сети. Приходится думать разные схемы.
Хм.  А у меня работает рецепт из LARTC...  Два аплинка и DNAT.

-- 
Regards, Alexey I. Froloff
AIF5-RIPN, AIF5-RIPE
-------------------------------------------
  Inform-Mobil, Ltd. System Administrator
       http://www.inform-mobil.ru/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Sysadmins] два шлюза и проброс во внутреннюю сеть

[Igor Solovyov]

Hi!
On Wed, 31 Oct 2007 14:25:16 +0300
"Peter V. Saveliev" <peet@altlinux.ru> wrote:

> в идеале -- самое простое -- это иметь по интерфейсу к каждому из
> шлюзов. Тогда:
> 
> ip route add default via S table S
> ip route add default via U table U
> ip route add default via U table main
> ip rule add dev ethS table S
> ip rule add dev ethU table U
> 
> Эта схема опробована и работает на мэйл-сервере, который глядит в две
> разных AS.

Вот у меня встала подобная задача сейчас и что-то никак сообразить не
могу как лучше сделать...
Есть два канала, один с и-нетовским айпишником (дорогой), назовем
его канал 1, другой с приватным, но очень недорогой, назовем его
каналом 2. Ставлю маршрутизатор, он же почтовик, он же прокси.
Интерфейс eth0 смотрит в локалку и на циску в локалке, которая настроена
провайдером так, что выпускает наружу только с адреса интерфейса eth0.
Циска мне для руления недоступна.

Есть eth1 (приватный адрес) смторит в канал 2.
Планирую весь веб-трафик локалки через squid выпустить/впустить в канал
2. Почтовик нужно выпускать в канал 1 на реальный айпишник, он слушает
на интерфейсе eth1.

т.е. выглядит так:

канал 1 <-- циска <-- eth0 postfix  squid eth1 ---> канал 2
локалка <-------------^

Пока default gw сделал на 2-й канал. Вот что-то не могу сообразить как
почтовику работать на канал 1. Если я сделаю второй default gw на адрес
циски, как в приведенном выше примере, то postfix поймет, что для него
выход наружу именно в циске? Что-то запутался я... :-(
А потом мне еще нужно будет выпустить так же в канал 1, ситриксовский
трафик локалки... :-)

-- 
Best Regars!
Igor Solovyov

Re: [Sysadmins] два шлюза и проброс во внутреннюю сеть

[Peter V. Saveliev]

В сообщении от Friday 02 November 2007 15:28:34 Igor Solovyov написал(а):
<skip />
> Пока default gw сделал на 2-й канал. Вот что-то не могу сообразить как
> почтовику работать на канал 1. Если я сделаю второй default gw на адрес
> циски, как в приведенном выше примере, то postfix поймет, что для него
> выход наружу именно в циске? Что-то запутался я... :-(
> А потом мне еще нужно будет выпустить так же в канал 1, ситриксовский
> трафик локалки... :-)

Давайте посмотрим, как вообще можно управлять классами маршрутизации в Linux. 
Их нам доступно 255 - 4 == 251.

Зарезервирвано четыре класса:

$ cat /etc/iproute2/rt_tables
#
# reserved values
#
255     local
254     main
253     default
0       unspec


Остальные доступны. По традиции, классы называют "таблицами маршрутизации".

Выбирать, какая таблица для чего доступна, можно с помощью rpdb (routing 
policy database), она rpdb рулицо через ip rule:

# ip rule add help
Usage: ip rule [ list | add | del | flush ] SELECTOR ACTION
SELECTOR := [ not ] [ from PREFIX ] [ to PREFIX ] [ tos TOS ] [ fwmark 
FWMARK[/MASK] ]
            [ dev STRING ] [ pref NUMBER ]
ACTION := [ table TABLE_ID ]
          [ prohibit | reject | unreachable ]
          [ realms [SRCREALM/]DSTREALM ]
TABLE_ID := [ local | main | default | NUMBER ]

То есть, реально мы можем зарулить пакет по fwmark и dev, т.к. src/dst могут 
быть любые в любом случае. Итого, наиболее корректный пример был бы такой 
(подразумеваются: S,U -- шлюзы провайдеров; нужно также внести записи в 
rt_tables, где S и U < 253, например, 100 и 101 соотв.):

# добавим деволтные шлюзы для каждого из провадеров в свой класс
ip route add default via S table S
ip route add default via U table U

# добавим один из них как "совсем-совсем" дефолтный для всего траффика,
# который мы не учтём
ip route add default via U table main

# дальше: первые два правила -- "откуда пришло -- туда ушло"
# (надо заметить -- работает только для локальных сервисов)
ip rule add pref 100 dev S table S
ip rule add pref 101 dev U table U

# дальше: раскидываем по портам (всё, что на 80 порт -- через провайдера U)
iptables -t mangle -I FORWARD -m tcp -p tcp --dport 80 -j MARK --set-mark 80
ip rule add pref 200 fwmark 80 table U

ну, или OUTPUT или попробовать POSTROUTING -- но я не помню, POSTROUTING в 
mangle отрабатывает до или после rpdb. Легко выясняется эмпирически.

# итеративно, пока сервисы не кончатся :)

...

В этой же схеме можно использовать l7-filter и ставить марки не по портам, а 
по результатам анализа траффика.

-- 
Peter V. Saveliev

Re: [Sysadmins] два шлюза и проброс во внутреннюю сеть

[Igor Solovyov]

Hi!
On Fri, 2 Nov 2007 15:54:18 +0300
"Peter V. Saveliev" <peet@altlinux.ru> wrote:

Спасибо. Все понял.

> # дальше: раскидываем по портам (всё, что на 80 порт -- через
> # провайдера U)
> iptables -t mangle -I FORWARD -m tcp -p tcp --dport 80 -j MARK
> --set-mark 80 ip rule add pref 200 fwmark 80 table U

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

> ну, или OUTPUT или попробовать POSTROUTING -- но я не помню,
> POSTROUTING в mangle отрабатывает до или после rpdb. Легко выясняется
> эмпирически.
> 
> # итеративно, пока сервисы не кончатся :)

Ага. Понял.

> ...
> 
> В этой же схеме можно использовать l7-filter и ставить марки не по
> портам, а по результатам анализа траффика.

Ладно, интересно. Поковыряюсь.

Большое спасибо!

-- 
Best Regars!
Igor Solovyov

Re: [Sysadmins] два шлюза и проброс во внутреннюю сеть

[Igor Solovyov]

Hi!
On Fri, 2 Nov 2007 15:54:18 +0300
"Peter V. Saveliev" <peet@altlinux.ru> wrote:

> Давайте посмотрим, как вообще можно управлять классами маршрутизации
> в Linux....

В общем докладываю. 
На всякий случай напомню, схема такова: маршрутизатор, два канала,
оба с приватными адресами на моей стороне, но один из них nat-ится
циской, которая имеет реальный ip:

канал 2 - сюда нужно выпустить web-трафик
adsl-модем
(192.168.1.1)
|
192.168.1.2
маршрутизатор
(прокси, почта)
192.168.151.22
|
|<- локалка 192.168.151.0/24
|
(192.168.151.254)
cisco
канал 1 - сюда нужно выпустить почту

интрефейсы:
# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:80:48:22:BA:94  
          inet addr:192.168.151.22  Bcast:192.168.151.255
.....
eth1      Link encap:Ethernet  HWaddr 00:80:48:4F:A1:E3  
          inet addr:192.168.1.2  Bcast:192.168.151.255
....
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
....

Слушающие сервисы:

192.168.151.22:25   0.0.0.0:*  LISTEN 4838/master
192.168.151.22:110  0.0.0.0:*  LISTEN 4761/cyrmaster
192.168.151.22:143  0.0.0.0:*  LISTEN 4761/cyrmaster
192.168.151.22:8080 0.0.0.0:*  LISTEN 4987/(squid)
192.168.151.22:53   0.0.0.0:*  LISTEN 4710/named
127.0.0.1:53        0.0.0.0:*  LISTEN 4710/named
127.0.0.1:953       0.0.0.0:*  LISTEN 4710/named

т.е. почта и прокси слушают только на eth0, глядящий в локалку
и на циску с реальным айпишником снаружи (канал 1).

маршрут по умолчанию установлен на канал 2:
# route -n

Kernel IP routing table
Destination     Gateway         Genmask     Flags Metric Ref Use
Iface 
192.168.151.0   0.0.0.0      255.255.255.0   U     0     0   0 eth0
192.168.1.0     0.0.0.0      255.255.255.0   U     0     0   0 eth1
0.0.0.0         192.168.1.1     0.0.0.0      UG    100   0   0 eth1


Теперь iproute:

# cat /etc/iproute2/rt_tables
255     local
254     main
253     default
0       unspec
150     adsltab # таблица для канала 2
151     dtab    # таблица для канала 1

# ip ru l

0:      from all lookup local 
150:    from all iif eth1 lookup adsltab 
151:    from all iif eth0 lookup dtab 
200:    from all fwmark 0x19 lookup dtab 
201:    from all fwmark 0x6e lookup dtab 
202:    from all fwmark 0x8f lookup dtab 
204:    from all fwmark 0xe4 lookup adsltab 
32766:  from all lookup main 
32767:  from all lookup default 

# ip ro l t adsltab
default via 192.168.1.1 dev eth1 

# ip ro l t dtab
default via 192.168.151.254 dev eth0 

так выглядит маркировка пакетов:

# iptables -t mangle -nL

Chain PREROUTING (policy ACCEPT)
target     prot opt source     destination         

Chain INPUT (policy ACCEPT)
target     prot opt source     destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source     destination         
MARK       tcp  --  0.0.0.0/0  0.0.0.0/0  tcp dpt:25   MARK set 0x19
MARK       tcp  --  0.0.0.0/0  0.0.0.0/0  tcp dpt:110  MARK set 0x6e
MARK       tcp  --  0.0.0.0/0  0.0.0.0/0  tcp dpt:143  MARK set 0x8f
MARK       tcp  --  0.0.0.0/0  0.0.0.0/0  tcp dpt:8080 MARK set 0xe4 

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination 


В результате всего этого squid исправно выгоняет трафик в канал 2(eth1)
как и задумывалось, а вот postfix тоже упорно пытается выйти наружу
через этот же канал 2 вместо канала 1, что наблюдается tcpdump-ом. :-(

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

Где же грабли порылись? Уже второй день эротикой занимаюсь...

-- 
Best Regars!
Igor Solovyov