[ip route]mail sending

вывод ip a и ip r было бы желательно. А вообще читать lartc на предмет Rules - routing policy

Вот вывод.
# ip a
2: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
4: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
link/ether 00:14:5e:7f:8a:36 brd ff:ff:ff:ff:ff:ff
6: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:14:5e:7f:8a:37 brd ff:ff:ff:ff:ff:ff
inet *.*.*.237/23 brd *.*.*.255 scope global eth1
inet *.*.*.238/23 brd *.*.*.255 scope global secondary eth1:1
inet *.*.*.247/23 brd *.*.*.255 scope global secondary eth1:10
inet *.*.*.248/23 brd *.*.*.255 scope global secondary eth1:11
inet *.*.*.249/23 brd *.*.*.255 scope global secondary eth1:12
inet *.*.*.239/23 brd *.*.*.255 scope global secondary eth1:2
inet *.*.*.240/23 brd *.*.*.255 scope global secondary eth1:3
inet *.*.*.241/23 brd *.*.*.255 scope global secondary eth1:4
inet *.*.*.242/23 brd *.*.*.255 scope global secondary eth1:5
inet *.*.*.243/23 brd *.*.*.255 scope global secondary eth1:6
inet *.*.*.244/23 brd *.*.*.255 scope global secondary eth1:7
inet *.*.*.245/23 brd *.*.*.255 scope global secondary eth1:8
inet *.*.*.246/23 brd *.*.*.255 scope global secondary eth1:9
inet6 fe80::214:5eff:fe7f:8a37/64 scope link
valid_lft forever preferred_lft forever
1: sit0: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
3: venet0: <BROADCAST,POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue
link/void
5: as0t0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 100
link/[65534]
inet 10.8.0.1/24 brd 10.8.0.255 scope global as0t0

# ip r

10.8.0.0/24 dev as0t0 proto kernel scope link src 10.8.0.1
64.46.38.0/23 dev eth1 proto kernel scope link src *.*.*.237
169.254.0.0/16 dev eth1 scope link
default via 64.46.38.1 dev eth1


Я пробовал
iptables -A PREROUTING -i eth1 -t mangle -p tcp --dport 25 \
-j MARK --set-mark 1
#тут правда я не знаю eth1 на eth1:11 поменять или как ?

# echo 201 mail.out >> /etc/iproute2/rt_tables
# ip rule add fwmark 1 table mail.out
# ip rule ls

ip route add default via *.*.*.248 dev eth1:11 table mail.out

Что неправильно то?

>iptables -t mangle -I INPUT -d адрес -j CONNMARK --set-mark 11

iptables -t mangle -I OUTPUT -j CONNMARK --restore-mark

ip ro add default via шлюз table 11

ip ru add fwmark 11 table 11

ip ro fl ca

то есть применительно к моему случаю это будет такая последовательность комманд ?
1. echo 11 mail.out >> /etc/iproute2/rt_tables
2. Очистка iptables
3. iptables -t mangle -I INPUT -d *.*.39.248 -j CONNMARK --set-mark 11
# *.*.39.248 - eth1:11 или указывать,что нить другое (хотя это было бы очень странно)

4. iptables -t mangle -I OUTPUT -j CONNMARK --restore-mark

5. ip ro add default via *.*.38.1 table 11
# шлюз брать как я понимаю из этого default via *.*.38.1 dev eth1 или же все таки из eth1 *.*.39.237 ?

6. ip ru add fwmark 11 table 11
7. ip ro fl ca

># *.*.39.248 - eth1:11 или указывать,что нить другое (хотя это было бы очень странно)

Сорри, невнимательно читал вводные. Правильнее так:
iptables -t mangle -I INPUT --m conntrack --ctstate NEW -p tcp --dport нужный_порт -j CONNMARK --set-mark 11

# шлюз брать как я понимаю из этого default via *.*.38.1 dev eth1 или же все таки из eth1 *.*.39.237 ?

Ну ты там хотел какой-то нестандартный роутинг...

Если нужно всего лишь поменять исходящий адрес, то это делается как-то так:
iptables -t nat -A POSTROUTING -m connmark --mark 11 -j SNAT --to-source *.*.*.247

Правда, сомневаюсь, что получится что-то хорошее — запрос приходит на один адрес, а отвечает другой. Вряд ли клиент это схавает.

Не пашет опять.
Сделал
1. echo 11 mail.out >> /etc/iproute2/rt_tables
2. Очистил iptables
3. iptables -t mangle -I INPUT -m conntrack --ctstate NEW -p tcp --dport 25 -j CONNMARK --set-mark 11
4. iptables -t mangle -I OUTPUT -j CONNMARK --restore-mark
5. ip ro add default via *.*.38.1 table 11
6. ip ru add fwmark 11 table 11
7. ip ro fl ca

Ничего не пашет (;
Уже неделю бьюсь над этой проблемой (:

Стоп. Что-то я туплю. Давай сначала.

Тебе нужен специальный роутинг для _исходящих_ соединений?

У вас там в OUTPUT других правил по маркировке пакетов нету? Ну и кеш маршрутов чистить надо после добавления новых правил, хотя за неделю он и так очиститс.

И как вы определяте, что соединение не работает? Может проблема в *.*.38.1?

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

для отладки маршрутов полезен режим ip route get 11.22.33.44

>видимо, человеку нужно почту через определенный маршрут заруливать

Т.е. исходящие? Если так, то какого хрена я советую ему делать маркировку в INPUT, а никто даже не поправляет?

Пусть уж ответит топикстартер, так как он привёл правило:

iptables -A PREROUTING -i eth1 -t mangle -p tcp --dport 25 -j MARK --set-mark 1

А оно имеет смысл только для входящих на 25 порт соединений. И более того, у него вроде отдельный адрес и подинтерфейс eth1:1 для этого выделен. Может ему вобще хватит «ip rule» по этому ip-адресу.

Да.проблема, нестандартная.
У меня есть несколько интерфейсов eth1, eth1:1 и eth1:11 (ip aliasing).
Нужно чтобы проги посылающие по определенному порту данные шли не через default eth1 *.*.39.237 а через *.*.38.1 .

Тогда так:

iptables -t mangle -F OUTPUT
iptables -t mangle -A OUTPUT -m conntrack --ctstate NEW -p tcp --dport 25 -j CONNMARK --set-mark 11
iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark

*.*.38.1 находится на расстоянии одного хопа?

То есть программа запускается на вашем сервере и должна с него отправить письмо (установить соединение с порта 25) и её пакеты должны идти через *.*.38.1 ? Так или нет?

Да один хоп.

Ну да.А так любое письмо идет через *.*.39.237 .

Судя по тому, что топикстартер всё время говорит про eth1:1, ему ещё нужен будет SNAT, чтобы эти пакеты уходили с нужным src-ip адресом.

>А так любое письмо идет через *.*.39.237.

*.*.39.237 это же ваш ip-адрес, на интерфейсе eth1. Вы хотели сказать, идёт с адреса *.*.39.237? Это правится через SNAT, а куда оно идёт смотрите с помощью tcpdump -e, там видно MAC-адреса и понятно, какому шлюзу отправляется пакет.

>Судя по тому, что топикстартер всё время говорит про eth1:1, ему ещё нужен будет SNAT, чтобы эти пакеты уходили с нужным src-ip адресом.

Да, пожалуй.

После применения.

iptables -t mangle -F OUTPUT

iptables -t mangle -A OUTPUT -m conntrack --ctstate NEW -p tcp --dport 25 -j CONNMARK --set-mark 11

iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark

# ip route get 213.180.204.89
213.180.204.89 via *.*.38.1 dev eth1 src *.*.39.237
cache mtu 1500 advmss 1460 hoplimit 64

P.S Раньше был немного похожий на этот другой случай.Там я просто понасоздовал VE (технология openvz) и просто убрал соотвествующие конф.файлы из /etc/sysconfig/network-script и убранных ипшников давал VE.
P.P.S в данном случае это сделать очень тяжело из-за независимых от меня обстоятельств (:

В вашем случае «ip route get» не поможет, так как у вас заворачиваются в другую таблицу только пакеты с dst-port 25. Добавьте правило:

iptables -t nat -I POSTROUTING -m mark --mark 11 -o eth1 -j SNAT --to-source *.*.*.238

Применил SNAT правило
iptables -t nat -A POSTROUTING -m connmark --mark 11 -j SNAT --to-source *.*.39.247
и о чудо оно запахало ;)

P.S Еще есть еще пару доменов с которых тоже надо отправлять имейл и в каждом тоже должен ип быть свой.
Вот как это сделать (вроде есть owner и его --uid-owner
[ NOTE: pid, sid and command matching are broken on SMP - из за этого эти вещи в этом модуле отбрасываются] )?

>и о чудо оно запахало ;)

Чудо будет, когда вы поймёте почему раньше не работало :)

ИМХО, лучше не связываться с pid/uid, а для каждого почтового домена сделать свой MTA, чтобы он отправлял почту с определённого ip-адреса, заданного в конфиге (каждый со своего). А дефолтный MTA пусть просто раскидывает почту по ним в зависимости от поля «MAIL FROM». В загловке будет лишний «Recived: » но обычно это не страшно.

Понятно, что для каждого своя таблица маршрутизации, и своё правило (ip rule), причём, ИМХО, лучше сделать «ip rule src ...» (и, если надо, перекрывать весь не SMTP трафик с этого ip-адреса), чем делать «ip rule fwmark ...» и маркировать только SMTP трафик.

>Чудо будет, когда вы поймёте почему раньше не работало :)
Я то понял :).Snat просто не стал сразу врубать(пытался досканально вьехать)

ИМХО, лучше не связываться с pid/uid, а для каждого почтового домена сделать свой MTA, чтобы он отправлял почту с определённого ip-адреса, заданного в конфиге (каждый со своего). А дефолтный MTA пусть просто раскидывает почту по ним в зависимости от поля «MAIL FROM». В загловке будет лишний «Recived: » но обычно это не страшно.

Почему не стоит связываться с pid/uid (года четыре назад я слышал что были нереальные траблы с этим) ?
C MTA не получиться ибо нужно будет другие mta в сhroot пихать,а тогда будут опять траблы с pleskовским qmailом (; [хотя я на днях попробую собраться сил и терпения и все таки так и сделать,ибо уже намучался]

Понятно, что для каждого своя таблица маршрутизации, и своё правило (ip rule), причём, ИМХО, лучше сделать «ip rule src ...» (и, если надо, перекрывать весь не SMTP трафик с этого ip-адреса), чем делать «ip rule fwmark ...» и маркировать только SMTP трафик.

Да это получше

У меня сложилось ощущение, что pid/uid похоронены. Вроде утверждается, что аналогичный функционал можно достигнуть через SeLinux. ИМХО, их никто не пилит и главное не тестит.

Ещё я не совсем понял, чем вам поможет pid/uid, если вам нужен MTA. Если же речь идёт об отправке почты различными скриптами, может проще поковырять их на предмет «биндига» к заданным ip-адресам.

Относительно chroot и qmail вобще не понял. Хотя qmail не знаю.

>У меня сложилось ощущение, что pid/uid похоронены. Вроде утверждается, что аналогичный функционал можно достигнуть через SeLinux. ИМХО, их никто не пилит и главное не тестит.
Ну Selinux с openvz не дружит(но на другое ядро я смогу пересесть (часть контента можно бесболезнено вытащить наружу) ). + я не знаю как достигнуть аналогичный функционал,не юзаю pid/uid .

Ещё я не совсем понял, чем вам поможет pid/uid, если вам нужен MTA. Если же речь идёт об отправке почты различными скриптами, может проще поковырять их на предмет «биндига» к заданным ip-адресам.

не mta не так нужен. Забиндить не получиться как я понимаю ибо нету там bind().
Из за этого придеться мне осиливать uid c owner.

Относительно chroot и qmail вобще не понял. Хотя qmail не знаю.

qmail у меня завязан на pleskовский qmail (; так что его лучше не трогать иначе он будет не пахать.Я с ним уже успел задолбаться

>У меня сложилось ощущение, что pid/uid похоронены.

Похоронены только pid, sid и cmd (из-за проблем с SMP).
uid и gid нормально работают, и их будущему пока вроде ничего не угрожает.

Вроде утверждается, что аналогичный функционал можно достигнуть через SeLinux.

По сути, yet another реализация классических uid/gid, более гибкая, но и более сложная в настройке.

Правда, с точки зрения фаервола она достаточно топорна — сам фаервол может устанавливать/менять метки SELinux для пакетов и соединений, однако не может отлавливать трафик на основании его меток. Так что, скажем, поменять ToS исходящего трафика для заданного домена или контекста не получится, в то время как для пользователя или группы это прокатит на ура.

Не думал что Selinux так топорен в данном случае. А другие решения типа Apparmor и Tomoyo также или лучше?
P.S уже доделываю uid доступ.

>Не думал что Selinux так топорен в данном случае.

Нет, в плане фильтрации (а не модификации) трафика все не так уж плохо. Разрешать/запрещать, скажем, определенным приложениям определенные порты SELinux и сам умеет. netfilter с его SECMARK'ами и CONNSECMARK'ами позволяет увеличить гибкость фильтров SELinux'а, добавив к ним мощный аппарат критериев netfilter'а. Однако в обратную сторону это не работает, т.е. спроецировать фильтры SELinux на netfilter нельзя, о чем я и говорил.

С apparmor я знаком похуже. Насколько я знаю, там все еще примитивнее. Там можно только накладывать дополнительные ограничения на доступ к файлам (дублируя функции прав файловой системы и POSIX ACL's), а также кастовать POSIX capabilities (дублируются функции libcap-bin).

С tomoyo я пока не знаком вообще, но судя по тому, что его тоже позиционируют как ламер-френдли и активно продвигают в мандриве, чего-то хорошего от него тоже ждать не стоит.

Есть еще RSBAC, и он даже интегрирован в полудохлую hardened gentoo, но поковырять его возможности все руки не доходят.

>Там можно только накладывать дополнительные ограничения на доступ к файлам (дублируя функции прав файловой системы и POSIX ACL's), а также кастовать POSIX capabilities (дублируются функции libcap-bin).

Ах да, можно еще разрешать/запрещать сетевые протоколы в целом (TCP, UDP, raw IP).

C маршрутизация я разобрался однако теперь надо чтобы скрипты под apache pleskовым под правильным юзером пахали.(там настроен mod_suexec однако plesk он как типичное проприетарное - УГ)

P.S тема помечаю закрытой и решенной .Спасибо всем за помощь
P.P.S suexec трабл http://www.linux.org.ru/forum/admin/4784444?lastmod=1271421338029