URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 92711
[ Назад ]

Исходное сообщение
"Как лучше настроить маршрутизацию ч/з двух провайдеров OpenVPN"

Отправлено wolkwww , 06-Дек-11 18:49 
Есть сервер 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.

Заранее благодарен за совет.


Содержание

Сообщения в этом обсуждении
"Как лучше настроить маршрутизацию ч/з двух провайдеров OpenVPN"
Отправлено PavelR , 06-Дек-11 19:37 
>[оверквотинг удален]
> 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


"Как лучше настроить маршрутизацию ч/з двух провайдеров OpenVPN"
Отправлено wolkwww , 06-Дек-11 19:42 
>[оверквотинг удален]
>> двух путей, при этом часто не по тому с которого пришел
>> запрос. Происходит облом. Пока ручками залезаю в 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.


"Как лучше настроить маршрутизацию ч/з двух провайдеров OpenVPN"
Отправлено PavelR , 06-Дек-11 20:33 
>[оверквотинг удален]
>>> обламывается и прописываю ему фиксированный 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"
Отправлено wolkwww , 06-Дек-11 20:36 
>[оверквотинг удален]
>>>> Дело осложняется, тем, что клиенты 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.
> да что вы говорите.

Ок попробую
Спасибо.



"чего-то  недопонял"
Отправлено wolkwww , 16-Дек-11 10:06 

Текст скрипта:
#!/bin/bash


localnets=localnets
enforta=enforta
smartcom=smartcom

local_if=eth1
local_net=192.168.2.0/24

localhost="127.0.0.1"

localnet_pref=1000
smartcom_pref=3000
enforta_pref=3010

smartcom_mark="0x1"
enforta_mark="0x2"

enforta_net="X.X.X.X/30"
smartcom_net="X.X.X.X/30"

enforta_if=eth2
smartcom_if=eth0

enforta_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 $smartcom

ip 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_pref

ip 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=tcpre

iptables -t mangle -F $localchain
iptables -t mangle -F $tcpre

iptables -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_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

##### конец скрипта

Пакеты  не идут по тем направлениям, которые ожидал. Более того если из 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

Буду благодарен если подскажете, что не так.


"чего-то  недопонял"
Отправлено PavelR , 16-Дек-11 10:59 
>[оверквотинг удален]
> 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



"чего-то  недопонял"
Отправлено wolkwww , 16-Дек-11 12:27 

выдержка из 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
COMMIT

tcpre - это цепочка образованная 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 localnets

192.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

<-- пусто -->

спасибо.



"чего-то  недопонял"
Отправлено PavelR , 16-Дек-11 12:51 
Лениво разбираться в ваших правилах, поэтому приведу свои, практически без изменений.

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


"чего-то  недопонял"
Отправлено wolkwww , 16-Дек-11 13:18 
если моно, приведите route for tables main & default

"чего-то  недопонял"
Отправлено PavelR , 16-Дек-11 14:12 
> если моно, приведите route for tables main & default

default будет содержать мой дефолтный маршрут, удаленный из main.
Кроме этого с main ничего значимого не делается.

Ну и бонусом, я в main, поскольку он высокоприоритетен, прописываю маршруты к DNS-серверам провайдеров. Т.е. к серверу провайдера оно всегда пойдет по сети провайдера. Собственно, в противном случае DNS-провайдера и не ответит.


"чего-то  недопонял"
Отправлено PavelR , 16-Дек-11 14:20 
>> если моно, приведите route for tables main & default
> default будет содержать мой дефолтный маршрут, удаленный из main.
> Кроме этого с main ничего значимого не делается.
> Ну и бонусом, я в main, поскольку он высокоприоритетен, прописываю маршруты к
> DNS-серверам провайдеров. Т.е. к серверу провайдера оно всегда пойдет по сети
> провайдера. Собственно, в противном случае DNS-провайдера и не ответит.

Благодаря высокоприоритетности main трафик к хостам локальной сети / подключенных по впн / по openvpn - и пойдет в нужный интерфейс. Потому что при поднятии интерфейса сетевые маршруты интерфейса будут прописываться в main. Это для pppX важно, к примеру.


Попытка объяснить зачем это надо:

Вариант с localnets в таких случаях становится не вполне пригоден - ответы впн-клиентам на запросы на IP-адреса провайдеров будут принудительно заворачиваться в сеть провайдера и т п эффекты.
И если в случае фиксированных интерфейсов это еще можно побороть прописыванием в localnets или прописыванием в маршруты таблицы "провайдер" дополнительной строки, описывающей маршрут к фиксированным локальным сетям, то в случае постоянно создающихся-отключающихся pppХ это приводит к необходимости загонять эти маршруты во все таблицы скриптом (что геморойно и легко забыть/ошибиться и сложно проверить пока сам не подключишься) или забивать на доступность внешних IP раутера для этих pppX подключений.

но это уже детали  темы "линукс и два провайдера" =))


"чего-то  недопонял"
Отправлено wolkwww , 16-Дек-11 14:47 
благодарю за помощь, завтра попро, с удаленки не решаюсь - "надо по месту".

"чего-то  недопонял"
Отправлено PavelR , 16-Дек-11 16:52 
> благодарю за помощь, завтра попро, с удаленки не решаюсь - "надо по
> месту".

при наличии навыков и четкого понимания, "как оно работает" - все делается и  по удаленке =)


"чего-то  недопонял"
Отправлено PavelR , 16-Дек-11 17:00 
>> благодарю за помощь, завтра попро, с удаленки не решаюсь - "надо по
>> месту".
> при наличии навыков и четкого понимания, "как оно работает" - все делается
> и  по удаленке =)

ха. А пока навыков нет - в крон загоняется задача "перезагрузить сервер через 15 минут".
Пока всё идет нормально - время исполнения задачи корректируется =)))
Перестает идти нормально - ждем 15 минут, сервер перезагружается с дефолтным конфигом (главное дефолт не запороть во время экспериментов, ога).


"Тут такое дело..."
Отправлено wolkwww , 16-Дек-11 19:19 
Там рабо круглосу, и оччень матерятся ....

"чего-то  недопонял"
Отправлено wolkwww , 16-Дек-11 14:45 

> Ну и бонусом, я в main, поскольку он высокоприоритетен, прописываю маршруты к
> DNS-серверам провайдеров. Т.е. к серверу провайдера оно всегда пойдет по сети
> провайдера. Собственно, в противном случае DNS-провайдера и не ответит.

а не проще поднять свой DNS?
С к-н дефолтными настройками?



"чего-то  недопонял"
Отправлено PavelR , 16-Дек-11 16:56 
>> Ну и бонусом, я в main, поскольку он высокоприоритетен, прописываю маршруты к
>> DNS-серверам провайдеров. Т.е. к серверу провайдера оно всегда пойдет по сети
>> провайдера. Собственно, в противном случае DNS-провайдера и не ответит.
> а не проще поднять свой DNS?
> С к-н дефолтными настройками?

а он и есть, свой DNS.

ну тут как... Либо делать его самостоятельным, т.е. чтобы он сам разрешал(резолвил) все запросы - но тогда он зависит от работоспособности дефолтного канала. В частном случае да, можно использовать переключатель дефолтного канала при падении каналов, тогда будет работать.

Или опять же, как у меня  днс форвардит запросы на вышестоящие днс-сервера провайдеров.
При этом все сервера провайдеров доступны (у меня используется 6 IP по два от каждого провайдера) и используются. В случае падения одного из провайдеров/днс-серверов остаются доступными другие 4(5) серверов, и сервис DNS как таковой не зависит от наличия или отсутствия работоспособности дефолтного канала.


"ну а почему Вашему DNS"
Отправлено wolkwww , 16-Дек-11 19:14 
не начинать сразу с корневых?
зачем обяз на DNS провайдера?
если он чисто форвард?
разницы практич. никакой, я думаю.

"ну а почему Вашему DNS"
Отправлено PavelR , 16-Дек-11 20:53 
> не начинать сразу с корневых?

а с каких начинать ?

> зачем обяз на DNS провайдера?

а на куда еще ?
> если он чисто форвард?

ну если он форвард - то куда-то. И это "куда-то" должно быть постоянно доступно.
поскольку у меня много "куда-то" и оно всегда работает по разным каналам, то получаем    выскокую надежность.

> разницы практич. никакой, я думаю.

Вот и вся разница.


Хотя я не совсем понял всего полета мысли данного сообщения.


"ну а почему Вашему DNS"
Отправлено wolkwww , 30-Дек-11 17:58 
В списке хинтов DNS-сервера есть список корневых доменов.

Если Вы просто запустите свой DNS, даже без доп настроек, Вы получите полноценный, но свой собственный DNS, и не надо гадать с какого прова резолвить очер имя.
Ваш собственный сервер прекрасно справится с задачей.


"ну а почему Вашему DNS"
Отправлено PavelR , 15-Янв-12 19:26 
> В списке хинтов DNS-сервера есть список корневых доменов.
> Если Вы просто запустите свой DNS, даже без доп настроек, Вы получите
> полноценный, но свой собственный DNS, и не надо гадать с какого
> прова резолвить очер имя.
> Ваш собственный сервер прекрасно справится с задачей.

Цитирую написанное мной выше, 16.12.2011:

=== цитата ===

а он и есть, свой DNS.

ну тут как... Либо делать его самостоятельным, т.е. чтобы он сам разрешал(резолвил) все запросы - но тогда он зависит от работоспособности дефолтного канала. В частном случае да, можно использовать переключатель дефолтного канала при падении каналов, тогда будет работать.

=== /цитата ===


"Ниче не вышло"
Отправлено wolkwww , 30-Дек-11 17:24 
Может подскажете, что не правильно?

# 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.



"Как хорошо бывает отвелчься..."
Отправлено wolkwww , 30-Дек-11 18:17 
Отвлекся написанием письма Вам и в скукоженный мозк пришла хорошая мысля.

Добавил:
ip rule add from $smartcom_addr lookup $smartcom pref 3005

И все встало с головы на ноги.

Спасибо за внимание.


"Как лучше настроить маршрутизацию ч/з двух провайдеров OpenVPN"
Отправлено ALex_hha , 31-Дек-11 01:24 
> Есть сервер 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?