setfib и openvpn (udp)

[Jeque]

Столкнулся с такой проблемой.
Есть сервер с поднятым openvpn, подключенный к интернет через двух провайдеров.

Код: Выделить всё

root@vpnsrv:/etc # uname -a
FreeBSD vpnsrv 9.1-RELEASE-p1 FreeBSD 9.1-RELEASE-p1 #0: Mon Mar 18 12:28:27 MSK 2013

Маршрутизация через двух провайдеров настроена следующим образом:

Код: Выделить всё

root@vpnsrv:/etc # cat /etc/rc.local
# define default routes
setfib 0 route delete default
setfib 0 route add    default 1.1.1.1
setfib 1 route delete default
setfib 1 route add    default 2.2.2.1

# assing route tables to interfaces
ipfw -f flush
ipfw add allow    ip from any to any via lo0
ipfw add setfib 0 ip from any to any via ext0
ipfw add setfib 1 ip from any to any via ext1
ipfw add allow    ip from any to any

В pf.conf есть следующие строки:

Код: Выделить всё

...
pass in on $ext_if_1 inet proto icmp from any to $ext_if_1 icmp-type $icmp_types
pass in on $ext_if_1 inet proto udp from any to $ext_if_1 port 33433><33626

pass in on $ext_if_2 inet proto icmp from any to $ext_if_2 icmp-type $icmp_types
pass in on $ext_if_2 inet proto udp from any to $ext_if_2 port 33433><33626

pass in on $ext_if_1 inet proto tcp from any to $ext_if_1 port ssh
pass in on $ext_if_2 inet proto tcp from any to $ext_if_2 port ssh

pass in on $ext_if_1 proto { tcp, udp } from any to $ext_if_1 port 1194
pass in on $ext_if_2 proto { tcp, udp } from any to $ext_if_2 port 1194
...

В результате имеем:
- сервер пингуется снаружи через оба внешних интерфейса
- traceroute снаружи до сервера работает также через обоих провайдеров
- к серверу можно подключиться снаружи по ssh через оба канала
- клиенты могут подключаться к openvpn по tcp через обоих провайдеров
- клиенты могут подключиться к openvpn по udp только через первого провайдера

С помощью tcpdump было выявлено, что udp-пакеты, приходящие от openvpn-клиента на второй канал, назад через него не возвращаются. Ещё раз обращаю внимание, что если в конфиге openvpn заменить proto udp на proto tcp, всё начинает работать, как надо: сервер даёт подключаться клиентам через оба интернет-канала.

Вопрос: что не так и можно ли заставить работать openvpn-сервер по протоколу udp через два wan-интерфейса.
Похожие темы уже были, но я что-то не нашёл окончательного решения проблемы.

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[skeletor]

Если у вас pf, то лучше сделать это средствами самого pf'a - http://argo-uln.blogspot.com/2008/02/pf ... -62-3.html . Я лично так и делал.
Не зачем мудохаться с fib'ами, если файервол это нормально разруливает. Вот если бы у вас был IPFW, тогда имело бы смысл.

[Jeque]

Я пробовал добавлять в pf.conf следующие строки:

Код: Выделить всё

pass in on $ext_if_1 reply-to ($ext_if_1 $gw_1) inet proto udp from any to $ext_if_1 port 1194 keep state
pass in on $ext_if_2 reply-to ($ext_if_2 $gw_2) inet proto udp from any to $ext_if_2 port 1194 keep state

Не помогло. Почему не знаю.
При этом, обратите внимание, что traceroute, который работает по тому же udp, работает без всяких reply-to.

А с fib'ами я мудохаюсь потому, что на этом сервере висит ещё mpd5, принимающий входящие pptp-соединения. Опытным путём выяснилось, что директива reply-to не умеет форвардить протокол gre, который необходим для работы pptp. Все gre-пакеты уходят в шлюз по умолчанию.

А ещё меня смущают следующие цитаты из мана к pf:

Код: Выделить всё

reply-to
           The reply-to option is similar to route-to, but routes packets that
           pass in the opposite direction (replies) to the specified inter-
           face.  Opposite direction is only defined in the context of a state
           entry, and [u]reply-to is useful only in rules that create state[/u].  It
           can be used on systems with multiple external connections to route
           all outgoing packets of a connection through the interface the
           incoming connection arrived through (symmetric routing enforce-
           ment).

Код: Выделить всё

keep state - works with TCP, UDP, and ICMP.

Код: Выделить всё

One will sometimes hear it said that, "One can not create state with UDP as UDP is a stateless protocol!" While it 
is true that a UDP communication session does not have any concept of state (an explicit start and stop of 
communications), this does not have any impact on PF's ability to create state for a UDP session. In the case of 
protocols without "start" and "end" packets, PF simply keeps track of how long it has been since a matching packet 
has gone through. If the timeout is reached, the state is cleared. The timeout values can be set in the optionssection 
of the pf.conffile. 

Из всего этого выходит, что если pf не удалось выставит на udp-пакет state, то и reply-to работать не будет. Может быть openvpn генерирует какие-то специфические udp-пакеты с большими таймаутами, на которые стэйты не создаются?

[skeletor]

А вы попробуйте reply-to + tag

[Jeque]

Запустил ради теста одновременно два демон openvpn, "слушающих" по udp на разных интерфейсах. С двумя демонами всё работает - подключается и к тому и к другому.
Даже и не знаю. Может это какой-то глюк openvpn?

[Alteron]

Не знаю, как там с OPENVPN, но у меня с mpd есть такая фича:
- два провайдера
- делаем две таблицы маршрутизации setfib 0 и setfib 1 дефолт-гетевеями на соответствующих провайдеров
- при помощи ipfw трафик с интерфейсов раскидываем по разным setfib

Имеем: все тоннели, поднятые через второго провайдера (setfib 1) внутри маршрутизируются тоже по setfib 1 (т.е. маршрутизация внутри тоннелей на серых адресах тоже идёт почему-то через setfib 1)

Победил пока прописыванием

${ipfw} add 3 setfib 0 ip from any to any via ng0
......................
${ipfw} add 3 setfib 0 ip from any to any via ng30

[Evgen85]

Запустил ради теста одновременно два демон openvpn, "слушающих" по udp на разных интерфейсах. С двумя демонами всё работает - подключается и к тому и к другому.
Даже и не знаю. Может это какой-то глюк openvpn?

Добрый день! Заранее прошу прощения за некро-постинг. Возникла такая же проблема но при этом еще и по TCP пинг возрастает до 3000 ms ( наверное из за слабых машин клиентов ).
Подскажите как получилось решить эту проблему ?
Для меня в принципе вполне подходит вариант поднять еще одни сервер OpenVPNа . Но я не понимаю как это корректно сделать:
Для второго сервера обязательно нужен второй тунель так ?
Может ли быть одна подсеть на обоих тоннелях ?
Как корректно настроить rc.conf и исполняемый файл для второго демона ?
Спасибо заранее!

[Jeque]

Проблему решил запуском двух демонов OpenVPN, слушающих разные интерфейсы.

[Jeque]

В rc.conf пишите следующее:

Код: Выделить всё

openvpn_udp_bee_enable="YES"
openvpn_udp_bee_if="tun"
openvpn_udp_bee_configfile="/usr/local/etc/openvpn/server_udp_bee.conf"
openvpn_udp_bee_dir="/usr/local/etc/openvpn"

openvpn_udp_mts_enable="YES"
openvpn_udp_mts_if="tun"
openvpn_udp_mts_configfile="/usr/local/etc/openvpn/server_udp_mts.conf"
openvpn_udp_mts_dir="/usr/local/etc/openvpn"

далее в /usr/local/etc/rc.d делаете симлинки с файла openvpn на openvpn_udp_bee и openvpn_udp_mts и их запускаете.