значит конфигурация такая. есть Openvpn сервер, с двумя провайдерами, соотв две статики,
eth1 - 1.1.1.1 gw 1.1.1.2
eth2 - 2.2.2.1 gw 2.2.2.2
ip r:
1.1.1.0/24 dev eth1 proto kernel scope link src 1.1.1.1
2.2.2.0/24 dev eth2 proto kernel scope link src 2.2.2.1
default via 2.2.2.2 dev eth2
ip r s t 1:
default via 1.1.1.2 dev eth1
ip r s t 2:
default via 2.2.2.2 dev eth2
ip ru:
0: from all lookup local
32760: from all fwmark 0x2 lookup 1
32764: from 1.1.1.1 lookup 1
32765: from 2.2.2.1 lookup 2
32766: from all lookup main
32767: from all lookup default
iptables:
iptables -t mangle -A INPUT -i eth1 -p udp --dport 1194 -j MARK --set-mark 2
iptables -t mangle -A INPUT -j CONNMARK --save-mark
iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark
это базовые правила по которым дол;но все работать как надо, но...
маршрутами стоят соот шлюзы провайдеров, соотв добавлены правила ip rule для хождения трафика через те интерфейсы с которых они пришли, таким образом работает автоматическое переключение дефолтного маршрута, в случае падения одного из провайдеров. у впн клиентов в конфигах прописаны обе статики сервера, чтобы в случае отказа какой либо, клиент подключался через другую. все работает хорошо, только есть один момент, не возможно подключится к впн серверу по той статике которая в данный момент не является маршрутом по умолчанию в мейне, смотрю в iptraf , клиент пытается подключиться , а ответ от сервера идет через дефолтный маршрут , а не через тот шлюз с которого пришел.
сейчас начнете тыкать носом в эту тему
iproute2+connmark, уже как только не извращался с коннмарком, видимо коннмарк не может тут корректно работать, тк соединение фактически не установлено те первый пакет имеет статус UNREPLIED, а просто марк сюда не подходит тк надо следить фактически за ответами сервера
после долгих ковыряний прихожу к выводу, что пока это особенность работы опенвпн сервера, тк на этом же сервере вэбсервер работает как надо по обоим интерфейсам и без использования коннмарка, достаточно только правил маршрутизации.
и напоследок лог того как маркируются пакеты в Iptables
sudo iptables -L -n -v -t mangle
Chain PREROUTING (policy ACCEPT 13180 packets, 7377K bytes)
pkts bytes target prot opt in out source destination
9 682 CONNMARK all -- eth1 * 0.0.0.0/0 0.0.0.0/0 CONNMARK restore
2 84 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 mark match !0x0 LOG flags 0 level 4
2 84 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 connmark match !0x0 LOG flags 0 level 4
Chain INPUT (policy ACCEPT 1892 packets, 238K bytes)
pkts bytes target prot opt in out source destination
3 126 MARK udp -- eth1 * 0.0.0.0/0 0.0.0.0/0 udp dpt:1194 MARK xset 0x2/0xffffffff
6 508 CONNMARK all -- eth1 * 0.0.0.0/0 0.0.0.0/0 CONNMARK save
3 126 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 connmark match !0x0 LOG flags 0 level 4
3 126 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 mark match !0x0 LOG flags 0 level 4
Chain FORWARD (policy ACCEPT 11288 packets, 7139K bytes)
pkts bytes target prot opt in out source destination
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 connmark match !0x0 LOG flags 0 level 4
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 mark match !0x0 LOG flags 0 level 4
Chain OUTPUT (policy ACCEPT 1606 packets, 289K bytes)
pkts bytes target prot opt in out source destination
1606 289K CONNMARK all -- * * 0.0.0.0/0 0.0.0.0/0 CONNMARK restore
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 mark match !0x0 LOG flags 0 level 4
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 connmark match !0x0 LOG flags 0 level 4
Chain POSTROUTING (policy ACCEPT 12894 packets, 7428K bytes)
pkts bytes target prot opt in out source destination
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 mark match !0x0 LOG flags 0 level 4
0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 connmark match !0x0 LOG flags 0 level 4
отсюда видно, что входящие соединения маркируются, марки сохраняются в соединениях, но не восстанавливаются, думаю как раз потому, что ответ опенвпн сервера начинает исходить с другим адресом источника( с другого интерфейса), из-за этого модуль коннтрак не считает его родственным соединению и не восстанавливает марку.