Есть сервер OpenVPN.
Настроил маршрутизацию "Round Robin":
ip route add default scope global nexthop via $P1 dev $IF1 weight 2 \
nexthop via $P2 dev $IF2 weight 1Но когда сервер принимает сетевое подключение, он не зная с какого интерфейса пришел входящий запрос на соединение отправляет ответные пакеты по одному из двух путей, при этом часто не по тому с которого пришел запрос. Происходит облом. Пока ручками залезаю в log, смотрю какой клиент(адрес) обламывается и прописываю ему фиксированный route - достает.
Дело осложняется, тем, что клиенты OpenVPN не имеют статического IP.Заранее благодарен за совет.
>[оверквотинг удален]
> ip route add default scope global nexthop via $P1 dev $IF1 weight
> 2 \
> nexthop via $P2 dev $IF2 weight 1
> Но когда сервер принимает сетевое подключение, он не зная с какого интерфейса
> пришел входящий запрос на соединение отправляет ответные пакеты по одному из
> двух путей, при этом часто не по тому с которого пришел
> запрос. Происходит облом. Пока ручками залезаю в log, смотрю какой клиент(адрес)
> обламывается и прописываю ему фиксированный route - достает.
> Дело осложняется, тем, что клиенты OpenVPN не имеют статического IP.
> Заранее благодарен за совет.http://opennet.ru/tips/1651_route_iptables_linux_nat.shtml
Только флажков должно быть два, и для второго не нужно делать DNAT.
Соответственно, должно быть и два ip ru (ip ru add pref 3010 from all fwmark 0x2 lookup <second> ).
Для начала также нужно прочитать и вкурить http://opennet.ru/tips/2009_policy_route_linux.shtml
>[оверквотинг удален]
>> двух путей, при этом часто не по тому с которого пришел
>> запрос. Происходит облом. Пока ручками залезаю в log, смотрю какой клиент(адрес)
>> обламывается и прописываю ему фиксированный route - достает.
>> Дело осложняется, тем, что клиенты OpenVPN не имеют статического IP.
>> Заранее благодарен за совет.
> http://opennet.ru/tips/1651_route_iptables_linux_nat.shtml
> Только флажков должно быть два, и для второго не нужно делать DNAT.
> Соответственно, должно быть и два ip ru (ip ru add pref 3010
> from all fwmark 0x2 lookup <second> ).
> Для начала также нужно прочитать и вкурить http://opennet.ru/tips/2009_policy_route_linux.shtmlЗабыл указать, OpenVPN работает на udp протоколе.
CONNMARK - только для tcp.
>[оверквотинг удален]
>>> обламывается и прописываю ему фиксированный route - достает.
>>> Дело осложняется, тем, что клиенты OpenVPN не имеют статического IP.
>>> Заранее благодарен за совет.
>> http://opennet.ru/tips/1651_route_iptables_linux_nat.shtml
>> Только флажков должно быть два, и для второго не нужно делать DNAT.
>> Соответственно, должно быть и два ip ru (ip ru add pref 3010
>> from all fwmark 0x2 lookup <second> ).
>> Для начала также нужно прочитать и вкурить http://opennet.ru/tips/2009_policy_route_linux.shtml
> Забыл указать, OpenVPN работает на udp протоколе.
> CONNMARK - только для tcp.да что вы говорите.
>[оверквотинг удален]
>>>> Дело осложняется, тем, что клиенты OpenVPN не имеют статического IP.
>>>> Заранее благодарен за совет.
>>> http://opennet.ru/tips/1651_route_iptables_linux_nat.shtml
>>> Только флажков должно быть два, и для второго не нужно делать DNAT.
>>> Соответственно, должно быть и два ip ru (ip ru add pref 3010
>>> from all fwmark 0x2 lookup <second> ).
>>> Для начала также нужно прочитать и вкурить http://opennet.ru/tips/2009_policy_route_linux.shtml
>> Забыл указать, OpenVPN работает на udp протоколе.
>> CONNMARK - только для tcp.
> да что вы говорите.Ок попробую
Спасибо.
Текст скрипта:
#!/bin/bash
localnets=localnets
enforta=enforta
smartcom=smartcomlocal_if=eth1
local_net=192.168.2.0/24localhost="127.0.0.1"
localnet_pref=1000
smartcom_pref=3000
enforta_pref=3010smartcom_mark="0x1"
enforta_mark="0x2"enforta_net="X.X.X.X/30"
smartcom_net="X.X.X.X/30"enforta_if=eth2
smartcom_if=eth0enforta_gw="X.X.X.X"
smartcom_gw="X.X.X.X"ip route add $local_net dev $local_if table $localnets
#ip route del default via $smartcom_gw table main
ip route add $smartcom_net dev $smartcom_if table $smartcom
ip route add default via $smartcom_gw table $smartcomip route add $enforta_net dev $enforta_if table $enforta
ip route add default via $enforta_gw table $enforta
ip rule add lookup $localnets pref $localnet_prefip ru add pref $smartcom_pref from all fwmark $smartcom_mark lookup $smartcom
ip ru add pref $enforta_pref from all fwmark $enforta_mark lookup $enforta
######### tunes for iptables #########
localchain=localchain
tcpre=tcpreiptables -t mangle -F $localchain
iptables -t mangle -F $tcpreiptables -t mangle -X $localchain
iptables -t mangle -N $localchain
##### это добавлено в процессе поиска ответа ######
iptables -t mangle -A $tcpre -p udp --dport 12094 -j CONNMARK --set-mark $smartcom_mark
iptables -t mangle -A $tcpre -p udp --sport 12094 -j CONNMARK --set-mark $smartcom_mark
iptables -t mangle -A $tcpre -p udp --sport 12094 -j RETURN
iptables -t mangle -A $tcpre -p udp --dport 12094 -j RETURN
##### end of это добавлено в процессе поиска ответа ######iptables -t mangle -A $tcpre -i $smartcom_if -m state --state NEW -j CONNMARK --set-mark $smartcom_mark
iptables -t mangle -A $tcpre -i $enforta_if -m state --state NEW -j CONNMARK --set-mark $enforta_markiptables -t mangle -A $tcpre -i $local_if -j $localchain
iptables -t mangle -A $localchain -d $local_net -j RETURN
iptables -t mangle -A $localchain -d $localhost -j RETURN
iptables -t mangle -A $localchain -d 10.125.0.0/16 -j RETURN ### внутренняя сеть OpenVPN
iptables -t mangle -A $localchain -j CONNMARK --restore-mark
iptables -t mangle -A $localchain -j RETURN##### конец скрипта
Пакеты не идут по тем направлениям, которые ожидал. Более того если из table main убрать default route, вообще никуда не идут
Хотя счетчики на цепочках iptables работают.># ip ro sh table smartcom
$smartcom_net dev eth0 scope link
default via $smartcom_gw dev eth0
># ip ro sh table enforta$enforta_net dev eth2 scope link
default via $enforta_gw dev eth2># ip ru sh
0: from all lookup local
1000: from all lookup localnets
3000: from all fwmark 0x1 lookup smartcom
3010: from all fwmark 0x2 lookup enforta
32766: from all lookup main
32767: from all lookup defaultБуду благодарен если подскажете, что не так.
>[оверквотинг удален]
> iptables -t mangle -A $tcpre -i $enforta_if -m state --state NEW -j
> CONNMARK --set-mark $enforta_mark
> iptables -t mangle -A $tcpre -i $local_if -j $localchain
> iptables -t mangle -A $localchain -d $local_net -j RETURN
> iptables -t mangle -A $localchain -d $localhost -j RETURN
> iptables -t mangle -A $localchain -d 10.125.0.0/16 -j RETURN ### внутренняя сеть
> OpenVPN
> iptables -t mangle -A $localchain -j CONNMARK --restore-mark
> iptables -t mangle -A $localchain -j RETURN
> ##### конец скриптазамуты с localchain / tcpre - мозговыносящи. Я так например и не смог найти, где они стыкуются с основными цепочками.
Вы лучше не скрипт показывайте, а вывод iptables-save или iptables -t (filter|mangle|nat|raw) -nvL --line по всем таблицам, так будет правильнее (мало ли какие изменения какими частями системы были сделаны - т.е. смотреть надо реально работающие правила.
> Пакеты не идут по тем направлениям, которые ожидал.непонятно, какие пакеты не идут по каким направлениям, и какие направления ожидались.
> Более того если из table main убрать default route, вообще никуда не идут
ну где-то то default route должен остаться, либо в main либо в default
> Буду благодарен если подскажете, что не так.
не видно ip ro sh table default / localnets / main
выдержка из iptables-save
*nat
:PREROUTING ACCEPT [46567:3435435]
:POSTROUTING ACCEPT [3319:324083]
:OUTPUT ACCEPT [39332:2494710]
************** это призрачный прокси *********
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.2.1:3128
************** это внутренние правила маршрутизации VPN соединений *********
-A PREROUTING -s 10.125.135.37/32 -d 192.168.11.41/32 -i tun+ -j DNAT --to-destination 192.168.2.41
-A PREROUTING -s 10.125.135.49/32 -d 192.168.11.41/32 -i tun+ -j DNAT --to-destination 192.168.2.41
-A PREROUTING -s 10.125.135.41/32 -d 192.168.11.27/32 -i tun+ -j DNAT --to-destination 192.168.2.27
-A PREROUTING -s 10.125.135.77/32 -d 192.168.11.30/32 -i tun+ -j DNAT --to-destination 192.168.2.30
-A PREROUTING -s 10.125.135.89/32 -d 192.168.11.41/32 -i tun+ -j DNAT --to-destination 192.168.2.41
***** eth0 и eth2 - внешние интерфейсы для провайдеров
***** eth0 - smartcom
***** eth2 - enforta
***** eth1 - внутренний для локалки
-A POSTROUTING -o tun+ -m policy --dir out --pol none -j MASQUERADE
-A POSTROUTING -o eth2 -m policy --dir out --pol none -j MASQUERADE
-A POSTROUTING -o eth0 -m policy --dir out --pol none -j MASQUERADE
COMMIT
# Completed on Fri Dec 16 14:03:14 2011
# Generated by iptables-save v1.4.0 on Fri Dec 16 14:03:14 2011
*mangle
:PREROUTING ACCEPT [2643897:1173604842]
:INPUT ACCEPT [1550768:784180495]
:FORWARD ACCEPT [1092746:389381372]
:OUTPUT ACCEPT [1672049:829191756]
:POSTROUTING ACCEPT [2764795:1218573128]
:localchain - [0:0]
:tcfor - [0:0]
:tcout - [0:0]
:tcpost - [0:0]
:tcpre - [0:0]
-A PREROUTING -j tcpre
-A FORWARD -j tcfor
-A OUTPUT -j tcout
-A POSTROUTING -j tcpost
-A localchain -d 192.168.2.0/24 -j RETURN
-A localchain -d 127.0.0.1/32 -j RETURN
-A localchain -j CONNMARK --restore-mark
-A localchain -j RETURN
-A tcpre -p udp -m udp --sport 12094 -j CONNMARK --set-mark 0x1
-A tcpre -p udp -m udp --dport 12094 -j CONNMARK --set-mark 0x1
-A tcpre -p udp -m udp --dport 12094 -j RETURN
-A tcpre -p udp -m udp --sport 12094 -j RETURN
-A tcpre -i eth0 -m state --state NEW -j CONNMARK --set-mark 0x1
-A tcpre -i eth2 -m state --state NEW -j CONNMARK --set-mark 0x2
-A tcpre -i eth1 -j localchain
COMMITtcpre - это цепочка образованная shorewall-ом
> непонятно, какие пакеты не идут по каким направлениям, и какие направления ожидались.
OpenVPN-server, установленный на этом боксе, принимает входящие соединения с клиентов по протоколу UDP(провайдер smartcom), ответные пакеты от сервера клиенту идут ч/з другого (enforta) провайдера. Естественно, получается, что клиент принимает ответные пакеты с другим src-адресом, нежели, с которым пытается соединиться. Хочу заставить, пакеты от сервера ходить ч/з того прова ч/з которого они приходят к этому серверу.
>> Более того если из table main убрать default route, вообще никуда не идут
> ну где-то то default route должен остаться, либо в main либо
> в default
> не видно ip ro sh table default / localnets / main
># ip ro sh table localnets192.168.2.0/24 dev eth1 scope link
># ip ro sh table main
10.125.131.1 via 10.125.131.30 dev tun1
192.168.0.41 via 10.125.131.30 dev tun1
192.168.0.27 via 10.125.131.30 dev tun1
10.125.135.2 dev tun0 proto kernel scope link src 10.125.135.1
192.168.0.30 via 10.125.131.30 dev tun1
192.168.0.1 via 10.125.131.30 dev tun1
192.168.0.35 via 10.125.131.30 dev tun1
192.168.0.52 via 10.125.131.30 dev tun1
192.168.0.21 via 10.125.131.30 dev tun1
192.168.0.102 via 10.125.131.30 dev tun1
192.168.0.23 via 10.125.131.30 dev tun1
192.168.0.100 via 10.125.131.30 dev tun1
10.125.131.30 dev tun1 proto kernel scope link src 10.125.131.29
$enforta_net dev eth2 proto kernel scope link src $enforta_ip metric 5
$smartcom_net dev eth0 proto kernel scope link src $smartcom_ip metric 5
10.125.135.0/24 via 10.125.135.2 dev tun0
192.168.2.0/24 dev eth1 proto kernel scope link src 192.168.2.1 metric 10
default via $enforta_gw dev eth2
$enforta_ip - адрес интерфейса eth2
$smartcom_ip - адрес интерфейса eth0># ip ro sh table default
<-- пусто -->
спасибо.
Лениво разбираться в ваших правилах, поэтому приведу свои, практически без изменений.root@router:~# iptables-save
# Generated by iptables-save v1.4.8 on Fri Dec 16 15:36:38 2011
*nat
:PREROUTING ACCEPT [2172829:200458232]
:POSTROUTING ACCEPT [243360:17289701]
:OUTPUT ACCEPT [236247:16843289]
#ДНАТ для траффика пришедшего на опенвпн на IP второго провайдера. dest IP первого (3.134) заменяется destIP второго (4.66)
# --->>> LOOK HERE <<---
-A PREROUTING -d 1.2.3.134/32 -p udp -m udp --dport 1194 -j CONNMARK --set-xmark 0x2/0xffffffff
-A PREROUTING -d 1.2.3.134/32 -p udp -m udp --dport 1194 -j DNAT --to-destination 2.3.4.66
#Нат клиентов
-A POSTROUTING -s 10.60.0.0/16 -o eth3 -j SNAT --to-source 4.5.6.34
-A POSTROUTING -s 10.60.0.0/16 -o eth1 -j SNAT --to-source 2.3.4.66
-A POSTROUTING -s 10.60.0.0/16 -o eth2 -j SNAT --to-source 1.2.3.134
COMMIT
# Completed on Fri Dec 16 15:36:38 2011
# Generated by iptables-save v1.4.8 on Fri Dec 16 15:36:38 2011
*mangle
:PREROUTING ACCEPT [90932658:68433482080]
:INPUT ACCEPT [46304244:40618371413]
:FORWARD ACCEPT [43858633:27744191733]
:OUTPUT ACCEPT [32070898:4058428984]
:POSTROUTING ACCEPT [75928755:31802563588]
#Зафильтруем от проникновений во внутреннюю сеть
-A PREROUTING -d 10.60.0.0/16 -i eth3 -j DROP
-A PREROUTING -d 10.60.0.0/16 -i eth2 -j DROP
-A PREROUTING -d 10.60.0.0/16 -i eth1 -j DROP
#Айпишник, в который делался днат. Все пакеты будут идти с него - либо они пришли на него напрямую через пров1, либо днатнуто через пров2
#После восстановления маркера будет замаршрутизирован куда надо.
# --->>> LOOK HERE <<---
-A OUTPUT -s 2.3.4.66/32 -p udp -m udp --sport 1194 -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff
COMMIT# Completed on Fri Dec 16 15:36:38 2011
# Generated by iptables-save v1.4.8 on Fri Dec 16 15:36:38 2011
*filter
:INPUT DROP [25186:3826744]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [2857362:613019690]
:IN_IPH_NET - [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i ppp+ -j ACCEPT
-A INPUT -i eth0 -j ACCEPT
-A INPUT -i tap0 -j ACCEPT
-A INPUT -i eth1 -p icmp -j ACCEPT
-A INPUT -i eth1 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i eth1 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -i eth1 -p tcp -m tcp --dport 1723 -j ACCEPT
# --->>> LOOK HERE <<---
-A INPUT -d 2.3.4.66/32 -i eth1 -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -i eth2 -p icmp -j ACCEPT
-A INPUT -i eth2 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i eth2 -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -i eth2 -p tcp -m tcp --dport 1723 -j ACCEPT
#Вошло с eth2 (3.134), но так как уже DNAT-нуто то в INPUT будет уже новый IP 4.66
# --->>> LOOK HERE <<---
-A INPUT -d 2.3.4.66/32 -i eth2 -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -i eth3 -p icmp -j ACCEPT
-A INPUT -i eth3 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i eth3 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i eth3 -p tcp -m tcp --dport 80 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i ppp+ -j ACCEPT
-A FORWARD -o ppp+ -j ACCEPT
-A FORWARD -i eth0 -j ACCEPT
-A FORWARD -i tap0 -j ACCEPT
COMMIT
# Completed on Fri Dec 16 15:36:38 2011
root@router:~#
root@router:~# ip ru
0: from all lookup local
1000: from all lookup main
1500: from all fwmark 0x1 lookup eth1
1510: from all fwmark 0x2 lookup eth2
1520: from all fwmark 0x3 lookup eth3
3000: from 2.3.4.66 lookup eth1
4000: from 1.2.3.134 lookup eth2
5000: from 4.5.6.34 lookup eth3
32766: from all lookup main
32767: from all lookup default
если моно, приведите route for tables main & default
> если моно, приведите route for tables main & defaultdefault будет содержать мой дефолтный маршрут, удаленный из main.
Кроме этого с main ничего значимого не делается.Ну и бонусом, я в main, поскольку он высокоприоритетен, прописываю маршруты к DNS-серверам провайдеров. Т.е. к серверу провайдера оно всегда пойдет по сети провайдера. Собственно, в противном случае DNS-провайдера и не ответит.
>> если моно, приведите route for tables main & default
> default будет содержать мой дефолтный маршрут, удаленный из main.
> Кроме этого с main ничего значимого не делается.
> Ну и бонусом, я в main, поскольку он высокоприоритетен, прописываю маршруты к
> DNS-серверам провайдеров. Т.е. к серверу провайдера оно всегда пойдет по сети
> провайдера. Собственно, в противном случае DNS-провайдера и не ответит.Благодаря высокоприоритетности main трафик к хостам локальной сети / подключенных по впн / по openvpn - и пойдет в нужный интерфейс. Потому что при поднятии интерфейса сетевые маршруты интерфейса будут прописываться в main. Это для pppX важно, к примеру.
Попытка объяснить зачем это надо:Вариант с localnets в таких случаях становится не вполне пригоден - ответы впн-клиентам на запросы на IP-адреса провайдеров будут принудительно заворачиваться в сеть провайдера и т п эффекты.
И если в случае фиксированных интерфейсов это еще можно побороть прописыванием в localnets или прописыванием в маршруты таблицы "провайдер" дополнительной строки, описывающей маршрут к фиксированным локальным сетям, то в случае постоянно создающихся-отключающихся pppХ это приводит к необходимости загонять эти маршруты во все таблицы скриптом (что геморойно и легко забыть/ошибиться и сложно проверить пока сам не подключишься) или забивать на доступность внешних IP раутера для этих pppX подключений.но это уже детали темы "линукс и два провайдера" =))
благодарю за помощь, завтра попро, с удаленки не решаюсь - "надо по месту".
> благодарю за помощь, завтра попро, с удаленки не решаюсь - "надо по
> месту".при наличии навыков и четкого понимания, "как оно работает" - все делается и по удаленке =)
>> благодарю за помощь, завтра попро, с удаленки не решаюсь - "надо по
>> месту".
> при наличии навыков и четкого понимания, "как оно работает" - все делается
> и по удаленке =)ха. А пока навыков нет - в крон загоняется задача "перезагрузить сервер через 15 минут".
Пока всё идет нормально - время исполнения задачи корректируется =)))
Перестает идти нормально - ждем 15 минут, сервер перезагружается с дефолтным конфигом (главное дефолт не запороть во время экспериментов, ога).
Там рабо круглосу, и оччень матерятся ....
> Ну и бонусом, я в main, поскольку он высокоприоритетен, прописываю маршруты к
> DNS-серверам провайдеров. Т.е. к серверу провайдера оно всегда пойдет по сети
> провайдера. Собственно, в противном случае DNS-провайдера и не ответит.а не проще поднять свой DNS?
С к-н дефолтными настройками?
>> Ну и бонусом, я в main, поскольку он высокоприоритетен, прописываю маршруты к
>> DNS-серверам провайдеров. Т.е. к серверу провайдера оно всегда пойдет по сети
>> провайдера. Собственно, в противном случае DNS-провайдера и не ответит.
> а не проще поднять свой DNS?
> С к-н дефолтными настройками?а он и есть, свой DNS.
ну тут как... Либо делать его самостоятельным, т.е. чтобы он сам разрешал(резолвил) все запросы - но тогда он зависит от работоспособности дефолтного канала. В частном случае да, можно использовать переключатель дефолтного канала при падении каналов, тогда будет работать.
Или опять же, как у меня днс форвардит запросы на вышестоящие днс-сервера провайдеров.
При этом все сервера провайдеров доступны (у меня используется 6 IP по два от каждого провайдера) и используются. В случае падения одного из провайдеров/днс-серверов остаются доступными другие 4(5) серверов, и сервис DNS как таковой не зависит от наличия или отсутствия работоспособности дефолтного канала.
не начинать сразу с корневых?
зачем обяз на DNS провайдера?
если он чисто форвард?
разницы практич. никакой, я думаю.
> не начинать сразу с корневых?а с каких начинать ?
> зачем обяз на DNS провайдера?
а на куда еще ?
> если он чисто форвард?ну если он форвард - то куда-то. И это "куда-то" должно быть постоянно доступно.
поскольку у меня много "куда-то" и оно всегда работает по разным каналам, то получаем выскокую надежность.> разницы практич. никакой, я думаю.
Вот и вся разница.
Хотя я не совсем понял всего полета мысли данного сообщения.
В списке хинтов DNS-сервера есть список корневых доменов.Если Вы просто запустите свой DNS, даже без доп настроек, Вы получите полноценный, но свой собственный DNS, и не надо гадать с какого прова резолвить очер имя.
Ваш собственный сервер прекрасно справится с задачей.
> В списке хинтов DNS-сервера есть список корневых доменов.
> Если Вы просто запустите свой DNS, даже без доп настроек, Вы получите
> полноценный, но свой собственный DNS, и не надо гадать с какого
> прова резолвить очер имя.
> Ваш собственный сервер прекрасно справится с задачей.Цитирую написанное мной выше, 16.12.2011:
=== цитата ===
а он и есть, свой DNS.
ну тут как... Либо делать его самостоятельным, т.е. чтобы он сам разрешал(резолвил) все запросы - но тогда он зависит от работоспособности дефолтного канала. В частном случае да, можно использовать переключатель дефолтного канала при падении каналов, тогда будет работать.
=== /цитата ===
Может подскажете, что не правильно?# iptables -t mangle -vL PREROUTING
Chain PREROUTING (policy ACCEPT 40626 packets, 8285K bytes)
pkts bytes target prot opt in out source destination
763 201K mrk udp -- any any anywhere anywhere udp spt:12094
0 0 mrk udp -- eth2 any anywhere anywhere udp dpt:12094
3261 1422K mrk udp -- eth0 any anywhere anywhere udp dpt:12094
40626 8285K CONNMARK all -- any any anywhere anywhere CONNMARK restore
4658 1218K mrk1 all -- any any anywhere anywhere MARK match 0x1
0 0 mrk2 all -- any any anywhere anywhere MARK match 0x2# iptables -t mangle -vL mrk
Chain mrk (3 references)
pkts bytes target prot opt in out source destination
5154 1797K CONNMARK udp -- any any anywhere anywhere udp CONNMARK set 0x1
5154 1797K ACCEPT all -- any any anywhere anywhere# ip ru
0: from all lookup local
3000: from all fwmark 0x1 lookup smartcom
3010: from all fwmark 0x2 lookup enforta
32766: from all lookup main
32767: from all lookup default# ip ro sh table smartcom
$smartcom_net dev eth0 scope link
default via $smartcom_gw dev eth0# ip ro sh table enforta
$enforta_net dev eth2 scope link
default via $enforta_gw dev eth2# ip ro sh table default
default via $enforta_gw dev eth2А надо чтобы пакеты udp от сервера на порту 12094 (они маркированы 0x1) направлялись согласно таблице smartcom. Доп цепочки я добавил для контроля.
А они - один черт идут согласно таблице default.
Отвлекся написанием письма Вам и в скукоженный мозк пришла хорошая мысля.Добавил:
ip rule add from $smartcom_addr lookup $smartcom pref 3005И все встало с головы на ноги.
Спасибо за внимание.
> Есть сервер OpenVPN.
> Настроил маршрутизацию "Round Robin":
> ip route add default scope global nexthop via $P1 dev $IF1 weight
> 2 \
> nexthop via $P2 dev $IF2 weight 1
> Но когда сервер принимает сетевое подключение, он не зная с какого интерфейса
> пришел входящий запрос на соединение отправляет ответные пакеты по одному из
> двух путей, при этом часто не по тому с которого пришел
> запрос.а почему бы не использовать параметр multihome в openvpn?