Два сетевых интерфейса с динамическими адресами и маршрутизация

Например, у TOR есть опция OutboundBindAddress, но она не позволяет ведь задать динамический адрес, я даже не могу написать в виде имени хоста.

Первое что приходит в мою сонную голову, маркировать исходящие пакеты по какому то признаку, например dst-port, src-port, UID пользователя из под которого запускается приложения и кидать в соответствующие таблицы. Хотя могу быть не прав, не встречался с таким уже давно.

а как правильно поступить с динамическими, я не знаю.

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

Как правильно привязывать демоны, чтобы они висели только на одном интерфейсе

В некоторых демонах есть возможность привязки к интерфейсу, но это редкость.
Если такого нет, то можно ограничить с помощью iptables доступ к/от порта и с помощью опций -i -o

Какая разница - статика или нет? Логика настройки точно такая-же - поднимаем интерфейс, получаем адрес, скармливаем адрес скрипту который делает настройку таблиц маршрутизации. Дальше сохраняем адрес куда-нибудь в систему, и в случае смены ip - перезапускаем нужные демоны с нужными параметрами.

Начать имеет смысл с man dhclient-script, раздел hooks.

в случае смены ip - перезапускаем нужные демоны с нужными параметрами.

Тоже вариант, но он обычно труднее реализуем.
Проще разрулить через iptables.

Проще разрулить через iptables

В общем случае - да, проще маркировать пакеты. Но например squid с несколькими tcp_outgoing_address таким образом разрулить не получится.

В общем случае - да, проще маркировать пакеты. Но например squid с несколькими tcp_outgoing_address таким образом разрулить не получится.

У меня чисто теоретический вопрос: почему? Вроде как в mangle/output можно маркировать пакет по source IP (т.е. по значению tcp_outgoing_address), а потом с помощью ip rule маршрутизировать, используя альтернативную таблицу.

Routing decision между OUTPUT и POSTROUTING часто почему-то не отображают в различных вариантах iptables flow chart, но оно есть (может называться: «reroute check» или «routing adjustment»), т.е. по идее все должно работать.

Похоже, у меня как-то криво настроилось. Пока не понял, в чём именно проблема. Пакеты dhcporequest, по-видимому, уходят не в ту сеть, то есть, в ту, что уже настроилась, а не в ту, которая настраивается второй.

Не понятно, как этого можно избежать.

Тут тоже не понятно. Ведь решение о маршрутизации для локальных исходящих пакетов принимается до того, как пакет попадает в netfilter? \если верить табличке здесь: http://www.opennet.ru/docs/RUS/iptables/#TRAVERSINGGENERAL) Метку я на исходящие пакеты вроде ставлю, только это, похоже, ни на что не влияет.

решение о маршрутизации для локальных исходящих пакетов принимается до того, как пакет попадает в netfilter

Судя по всему это либо ошибка в диаграмме, либо устаревшие данные.
Даже в man iptables написано:

nat:
    ...OUTPUT (for altering locally-generated packets before routing)...

iptables -t nat -A OUTPUT -p icmp -d 213.180.204.3 -j DNAT --to-destination 127.0.0.1
tcpdump -ni lo &
ping -c1 213.180.204.3

Метку я на исходящие пакеты вроде ставлю, только это, похоже, ни на что не влияет.

А где ты ставишь метку? Надо в mangle OUTPUT.

Да, с правилом в mangle OUTPUT заработало. В том смысле, что пакеты уходят с нужного интерфейса.

Теперь нужно сделать, чтобы правильно подменялся IP адрес. Попробовал в nat POSTROUTING заменять src-адрес на адрес интерфейса (SNAT), уже лучше, только ответные пакеты приходят на адрес интерфейса и не доходят до приложения.

Наверное, нужно помечать соединение с помощью CONNMARK, и ответные пакеты, относящиеся к этому соединению, DNAT-ить?

посмотри rp_filter

Угу, только что посмотрел! Оказалось, я почему-то писал туда 0, а нужно было написать 2.

Заработало.