Маршрутизация, NAT, 2 провайдера, 1 идиот

Непонятно, в чём проблема (задача). Что может измениться в этом
>$IPT -t nat -A POSTROUTING -s $NET_SUB1 -o NET_INET1 -j SNAT 1.1.1.0/24
правиле? --src $NET_SUB1/2? Или у вас всё-таки 1 внутренняя подсеть?

s/непонятно/не понятно/;

У меня:
Интерфейс\шлюз\мой ip
1. ce0 194.85.39.41-194.85.39.42 ( на моей стороне) - Провайдер РАЗ
2. eth0 82.179.92.2 (смотрит внутрь), внутри сеть 192.168.0.0/16
3. eth2 83.234.46.49 - 83.234.46.50 ( на моей стороне) - Провайдер ДВА

Мне нужно все пакеты, которые пронатившись, уходят с адреса 83.234.46.50 отправлять через 83.234.46.49 И все с натовым адресом 82.179.92.2 отправлять через 194.85.39.41

Я нифига не понимаю, зачем у вас интерфейс 82.179.92.2 висит на карточке, которая смотрит внутрь локалки и как он (интерфейс/компутер/гейт) с ней (192.168.0.0/16) общается (alias?).
Почему не поднять на этой самой (внутренней) карточке интерфейс с адресом из сети 192.168.0.0/16 ?

>Мне нужно все пакеты, которые пронатившись, уходят с адреса 83.234.46.50 отправлять через 83.234.46.49
Они и так будут отправляться через 83.234.46.49 (потому что они уже пронатились с 83.234.46.50, потому что они отправляются через 83.234.46.49........)

offtop
Зачем заменил, правильно было

интерфейс 82.179.92.2, потому что пров выделил сеть /27. А 194,85,39,41 работает только как шлюз наверное. Вот такая вот немного нетривиальная ситуация. Но отличия от банальной конфигурации минимальные. Вопрос остается открытым - можно ли сделать на сервере и нат, и двух провайдеров, и чтобы после ната распихивать пакеты по таблицам? Если я пишу ip rule add from 192.168.22.51 table T1 (или T2) то все делается правильно. А вот после ната так не получается.

>$IPT -t nat -A POSTROUTING -s $NET_SUB1 -o NET_INET1 -j SNAT 1.1.1.0/24 То будет нормально. Но построутинг - это же уже после принятия решения о маршрутизации, там уже выбралась таблица, куда все дальше пойдет. Как быть? У меня в голове коллизия. Как можно распихивать пакеты по таблицам после ната?

Абсолютно правильная коллизия. Раз вы в правиле пишете -o NET_INET1, то значит решение о маршрутизации уже принято (определено через какой интерфейс пойдет пакет). Решение о маршрутизации принимается на основании таблицы маршрутизации, а таблица маршрутизации выбирается на основании правил (src-ip адрес, входящий интерфейс, метка (MARK) iptables). А SNAT нужен, чтобы в сеть провайдера пакеты уходили с нужным ip-адресом.

>Буду метить для шейпера.

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

Поставьте адрес 82.179.92.2 на ce0. У вашего провайдера должен быть шлюз из 82.179.... в той же самой физической сети. Выясните его адрес.
Всё= не понимаю, зачем вы прописали 82.179 на внутреннюю карточку.
http://club.shelek.ru/download.php?id=243

> не хочу метить пакеты, по крайней мере для маршрутизации. Буду метить для шейпера.

Одно другому не мешает, при анализе маркировок можно использовать маску, а при задании маркировок ещё и and/or операции:
ip rule help
... [ fwmark FWMARK[/MASK] ] ...

iptables -j MARK --help
...
MARK target options:
--set-xmark value[/mask] Clear bits in mask and XOR value into nfmark
--set-mark value[/mask] Clear bits in mask and OR value into nfmark
--and-mark bits Binary AND the nfmark with bits
--or-mark bits Binary OR the nfmark with bits
--xor-mask bits Binary XOR the nfmark with bits

iptables -m mark --help
...
mark match options:
[!] --mark value[/mask] Match nfmark value with optional mask

К тому же полезно взглянуть на Kernel Packet Travelling Diagram - сразу будет видно где происходит маршрутизация, и в каких правилах маркировка для неё уже не нужна и может быть перезаписана маркировками для shaper-а.

http://www.ssi.bg/~ja/nano.txt

Почитай сдесь.