Выбор маршрута для трафика от локального процесса

Изучить конфиг MTA на предмет биндинга на нужный ип/интерфейс. У postfix это smtp_bind_address = x.x.x.x

Присоединяюсь к предыдущему автору. Добавлю, что в случае sendmail это строчка

O ClientPortOptions=Addr=your IP

в sendmail.cf.

Ну или

CLIENT_OPTIONS('Addr=yourIP')dnl

в sendmail.mc.

Что-то типа ip rule add from iif lo Не помню точно, но была похожая проблема и таким способом решилась.

> Что-то типа ip rule add from iif lo

Таким образом Вы отправите все пакеты по новому маршруту. Автору топика это не нужно - по определнному маршруту должны идти только пакеты MTA.

smtp_bind_address=1.2.3.4
inet_interfaces=all

После этого отказывается принимать почту от localhost. Т.е. у меня не получается использовать mail на самом почтовом сервере.

lost connection with 127.0.0.1[127.0.0.1] while receiving the initial server greeting

Note 1: when inet_interfaces specifies no more than one IPv4 address, and that address is a non-loopback address, it is automatically used as the smtp_bind_address.

>Что-то типа
Это правило устанавливается (как правило), чтобы ответы на пакеты, которые пришли на «второй» внешний интерфейс уходили с него же. Вернее, через другой, не default, gateway.

>Если бы пакет от локального процесса проходил mangle PREROUTING, то я бы его роутил по метке.

Пакеты от локальных процессов проходят mangle OUTPUT. В чем проблема?

плюсую. я так астериск нагибаю:

iptables -t mangle -A OUTPUT -d ! 192.168.0.0/24 -m owner --uid-owner asterisk -j MARK --set-mark 255

Пакеты от локальных процессов проходят mangle OUTPUT. В чем проблема?

Вероятно в том, что пакет проходит через OUTPUT когда уже принято решение о маршрутизации?

smtp_bind_address=1.2.3.4 inet_interfaces=all

После этого отказывается принимать почту от localhost. Т.е. у меня не получается использовать mail на самом почтовом сервере.

принимает почту smtpd, а биндиться на адрес smtp так-что отказ принимать почту связан с чем то другим.

inet_interfaces = all smtp_bind_address = x.x.x.x

вот рабочий пример. может стоит поменять их местами?

В общем случае можно использовать возможности iproute 2
Альтернативная таблица маршрутизация.
На неё заворачивать трафик по меткам, либо соурс-роутинг.

>Альтернативная таблица маршрутизация.

На неё заворачивать трафик по меткам, либо соурс-роутинг.

В каком месте я буду ставить метки для такого трафика?
Сорс-роутинг применим, когда известен source ip.

Не работает. Почтовик достался в наследство. Пока разбираюсь с ним. Может, что-то из ограничений не пускает в моём случае. Повторюсь: если добавляю smtp_bind_address=<внешний ip>, то не принимает почту с localhost (по крайней мере).

Вот конфиг.

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no
append_dot_mydomain = no
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${queue_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${queue_directory}/smtp_scache
myhostname = mail.example.ru
mydomain = example.ru
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = $mydomain
mydestination = gateway.example.ru, localhost.example.ru, localhost, $myhostname, localhost.$mydomain, example.ru
relayhost = 
mynetworks = 127.0.0.0/8 192.168.0.0/21
mailbox_size_limit = 0
message_size_limit = 10485760
recipient_delimiter =
inet_interfaces = all
inet_protocols = ipv4
notify_classes = bounce,delay,protocol,resource,software
smtpd_etrn_restrictions = permit_mynetworks, reject
smtpd_delay_reject = yes
disable_vrfy_command = yes
strict_rfc821_envelopes = yes
smtpd_helo_required = yes
smtpd_helo_restrictions = 
smtpd_sender_restrictions = 
smtpd_client_restrictions =
smtpd_recipient_restrictions = 
        permit_mynetworks, 
        permit_sasl_authenticated, 
        reject_unauth_pipelining, 
        reject_invalid_hostname,
        reject_non_fqdn_sender,
        reject_non_fqdn_recipient, 
        reject_unknown_sender_domain,
        reject_unknown_recipient_domain, 
        reject_unauth_destination, 
        check_client_access hash:/etc/postfix/maps/access_client,
        check_helo_access hash:/etc/postfix/maps/access_helo,
        check_sender_access hash:/etc/postfix/maps/access_sender,
        check_recipient_access hash:/etc/postfix/maps/access_recipient, 
        reject_rbl_client blackholes.easynet.nl,
        reject_rbl_client cbl.abuseat.org,
        reject_rbl_client bl.spamcop.net,
        reject_rbl_client sbl.spamhaus.org,
        reject_rbl_client dnsbl.njabl.org,
        reject_rbl_client list.dsbl.org,
        reject_rbl_client multihop.dsbl.org,
        permit
content_filter = smtp-amavis:[127.0.0.1]:10024

После того, как закоментировал
content_filter = smtp-amavis:[127.0.0.1]:10024
всё заработало. Надо ковырять amavis. Никогда с ним дело не имел.

>Вероятно в том, что пакет проходит через OUTPUT когда уже принято решение о маршрутизации?

Неа. Специально после mangle OUTPUT и nat OUTPUT пакет проходит процедуру «check for re-route». Кстати, именно поэтому в данных цепочках не имеют смысла -o и --physdev-out.

Не знал, приму к сведению.

а src при этом «check for re-route» поменять можно?

на хост в локалке проброшен внешний адрес через proxy-arp на роутере
хочу, чтобы при обращении «наружу» хост использовал этот реальный IP
пакеты маркируются, но правило
default via 192.168.128.1 dev eth0.700 src ххх.205.242.35
в соотв таблице не работает, конкретно src пакетов серый, не ххх.205.242.35

А почему не SNAT в POSTROUTING?

И, кстати насчет правильности маршрутизации у меня есть сомнения. Это же мост? Тогда нужно в качестве дефолтного шлюза писать провайдерский (ориентировочно ххх.205.242.1).

>а src при этом «check for re-route» поменять можно?

Насколько я знаю, нет. В nat OUTPUT выполняются только оперцаии проброса и редиректа исходящего трафика, т.е., грубо говоря, смена dst. После этого, разумеется, может потребоваться «переосмысление» маршрута.

нет не мост, а именно роутер с proxy-arp наружу
сейчас так и сделано, SIP бегает через SNAT
но терзают смутные сомнения, почему бы не обойтись без трансляции

Отвечу сам себе.... для гуглящих.

amavis традиционно принимал сообщения только от 127.0.0.0/8.

Нужно в master.cf подсунуть транспорту postfix, отвечающему за релей на amavis соответствующий smtp_bind_address:

smtp-amavis unix -      -       -       -       5       smtp
 -o smtp_data_done_timeout=1200s
 -o smtp_bind_address=127.0.0.1
 .....

или перезаписать его пустым значением.