Метки конектов на удп

Подробности будут?
ip r s
ip ru s
iptables-save

Биндить udp-сервисы на отдельные ip-адреса. Тогда демон будет знать на какой адрес пришёл запрос и (если написан правильно) с этого же адреса отвечать. Bind (named) ведь у вас работает? Он слушает по udp адреса по отдельности, а не 0.0.0.0.

Или патчить демонов, чтобы они получали от ядра информацию об udp-адресе пакета (struct in_pktinfo)...

например l2tp не забиндишь 2 раза…

default via 81.хх.хх.254 dev enp0s10 metric 20 default via 109.уу.уу.1 dev enp0s18 metric 21 onlink 81.хх.хх.0/21 dev enp0s10 proto kernel scope link src 81.хх.хх.12 109.уу.уу.0/24 dev enp0s18 proto kernel scope link src 109.уу.уу.75 192.168.0.0/24 dev enp0s8 proto kernel scope link src 192.168.0.1

0: from all lookup local 32763: from all to 109.60.128.3 lookup ttk 32764: from all fwmark 0x65 lookup 101 32765: from 109.уу.уу.75 lookup 101 32766: from all lookup main 32767: from all lookup default

iptables-save

сейчас убранно, было прероутинг на интерфейсе марк, конмарк сейвмарк и в оутпут рестор марк

Конкретно про l2tp не помню, но так, если демон мог биндиться только на один ip-адрес, а нужно было два, то запускалось два экземпляра, по одному на каждый ip.

Ну, может ещё сработает DNAT пакетов, приходящих на второй внешний ip-адрес, на первый (81.xx.xx.12) и connmark.

попробую на эхо-сервере. но похоже проще будет запустить нат+виртуалку

Для xl2tp это параметр listen-addr

Во первых, разметка.
Во вторых, вы написали что

сейчас убранно

Ну и что хотим? Улетает черезх defgw

В третьих, при multihome использовать defgw в таблице main не самый удобный вариант.

Или патчить демонов, чтобы они получали от ядра информацию об udp-адресе пакета (struct in_pktinfo)...

Просто «или» тут не катит, так как узнать это одно, а отправить без биндинга сокета на конкретный адрес не получится. И это ещё не всё. Надо ещё мониторинг появившихся новых адресов при уже запущенном демоне :(

Вроде, через магию — вызов sendmsg() с указанием struct cmsghdr (через CMSG_FIRSTHDR() и т.д. man cmsg), можно отправлять udp (и raw) с нужными dst и src ip-адресами без биндинга сокета.

Если демон слушает 0.0.0.0 по udp, и запрашивает от ядра на каждый пакет struct in_pktinfo, то он и так узнает адрес, сразу как придёт пакет, ему не нужен мониторинг новых адресов.

ИМХО, здесь не проблема кода, а проблема совместимости/портируемости. Под винду подобный код не возможен, под BSD, наверное, он будет немного другой. Кому нужно плодить код без особого выигрыша в возможностях программы...

Вроде, через магию — вызов sendmsg() с указанием struct cmsghdr (через CMSG_FIRSTHDR() и т.д. man cmsg), можно отправлять udp (и raw) с нужными dst и src ip-адресами без биндинга сокета.

Что-то я не нашёл способа этим установить source IP, вот информацию в опциональный IP-заголовок это может. Может пример покажите? Но даже если б и оно могло, это как-то из пушки по воробьям и не портируемо.

Если демон слушает 0.0.0.0 по udp, и запрашивает от ядра на каждый пакет struct in_pktinfo, то он и так узнает адрес, сразу как придёт пакет, ему не нужен мониторинг новых адресов.

Собственно вы алгоритм этого мониторинга и описали. Получили новый неприбинденный адрес - делаем новый сокет...