OpenVPN с резервированием WAN канала на клиентах

[thunderamur]

Офис и 3 филиала. Везде разные провайдеры. Офис с серым айпи. Для объединения всех сетей решено использовать VPS, на котором будет стоять сервер OpenVPN. В офисе и филиалах будет по 2 WAN, основной и резервный. В качестве роутера сервер с Ubuntu, который будет следить за доступностью основного WAN и, в случае его падения, менять правила iptables, направляя клиентов через резервный канал в инет.

Вопрос, нормально ли будет работать OpenVPN при таком переключении.

Читал также про разруливание по 2-м каналам с помощью настройки метрик, но не понял как это реализуется. И что всё-таки лучше, переключение форвардинга на резервный канал вообще нормальное решение?

[fisher74]

Управление основного траффика с помощью метрики - самое простое, что можно реализовать, но только в том случае, если пропадание связи сопровождается падением интерфейса. Зато работает чётко и моментально. Нет необходимости регулярно что-то проверять, выбирать интервал и т.д. Но не всегда пропадание связи влечёт падение интерфейса...

[thunderamur]

выходит надёжнее перенаправлять пакеты на нужный WAN. openVPN как к этому отнесётся, нормально работать клиенты будут в этом случае?

[fisher74]

Перехд может по разному происходить. Вы же не будете каждую миллисекнду проверять основной канал. Скорее всего период будет не меньше минуты, а за минуту туннель рухнет и нужно будет время на восстановление. Не долго, конечно, но...

[thunderamur]

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

dev tun
tls-server
proto udp
port 1194
comp-lzo
persist-tun
persist-key

server 10.10.10.0 255.255.255.0

route 192.168.0.0 255.255.255.0
route 192.168.1.0 255.255.255.0
route 192.168.2.0 255.255.255.0
route 192.168.5.0 255.255.255.0

dh /etc/openvpn/keys/dh1024.pem
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key

ifconfig-pool-persist ipp.txt

keepalive 10 120

client-to-client

log /var/log/openvpn.log
verb 3

конфиг верный?
Пользователь решил продолжить мысль 15 Декабря 2011, 07:15:12:создал ключи, пробую пустить сервер получаю ошибку

Код: [Выделить]

Thu Dec 15 06:13:11 2011 Note: Cannot open TUN/TAP dev /dev/net/tun: No such file or directory (errno=2)
Thu Dec 15 06:13:11 2011 Note: Attempting fallback to kernel 2.2 TUN/TAP interface
Thu Dec 15 06:13:11 2011 Cannot allocate TUN/TAP dev dynamically
Thu Dec 15 06:13:11 2011 Exiting

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

Thu Dec 15 06:13:11 2011 OpenVPN 2.1.0 x86_64-pc-linux-gnu [SSL] [LZO2] [EPOLL] [PKCS11] [MH] [PF_INET6] [eurephia] built on Jul 12 2010
Thu Dec 15 06:13:11 2011 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Thu Dec 15 06:13:11 2011 Diffie-Hellman initialized with 1024 bit key
Thu Dec 15 06:13:11 2011 /usr/bin/openssl-vulnkey -q -b 1024 -m <modulus omitted>
Thu Dec 15 06:13:11 2011 TLS-Auth MTU parms [ L:1542 D:138 EF:38 EB:0 ET:0 EL:0 ]
Thu Dec 15 06:13:11 2011 ROUTE default_gateway=192.0.2.1
Thu Dec 15 06:13:11 2011 Note: Cannot open TUN/TAP dev /dev/net/tun: No such file or directory (errno=2)
Thu Dec 15 06:13:11 2011 Note: Attempting fallback to kernel 2.2 TUN/TAP interface
Thu Dec 15 06:13:11 2011 Cannot allocate TUN/TAP dev dynamically
Thu Dec 15 06:13:11 2011 Exiting

[fisher74]

Код: [Выделить]

grep CONFIG_TUN /boot/config-`uname -r`
sudo /sbin/modprobe tun
lsmod | grep tun
Чую, что это прикол VPS....

[thunderamur]

я тоже так подумал и уже поднял ВМ, на ней сервер стартовал, но соединение ssh оборвалось, так и должно быть?

а на VPS не спроста Ubuntu весит меньше 200 метров на диске и 19 метров в ОЗУ, когда на ВМ стоковая весит 1.2 гига и 30+ в ОЗУ.

[fisher74]

С кем соединение оборвалось?

Так Вы покажете выхлоп или так и будем бубнеть ни о чём?

[thunderamur]

с ВМ же, я на ВМ через ssh работал, стартовали vpn соединения и ssh оборвалось, наверное так и должно быть, просто я, пока, в vpn нуб.

[fisher74]

На VPS подняли ВМ и подключились к ней по ssh с VPS. В результате запуска сервера OpenVPN на ВМ у Вас пропал ssh-коннект с ней.
Гхм... Не должно было такого случиться.

[thunderamur]

не на VPS))) на своем компе ВМ, чтобы убедится, что дело в VPS, а не в настройках, ну и чтобы таки попробовать работу openvpn
Пользователь решил продолжить мысль 16 Декабря 2011, 04:06:58:

[thunderamur]

В общем, годный VDS найден. Имею соединение локальной ВМ и OpenVPN-сервера на VDS в Инете.
Вопрос как мне превратить локальную ВМ в шлюз для других машин для связи через OpenVPN, т.е.

[fisher74]

Я в своё время использовал tap вместо tun (мне показалось удобным всех держать в одной подсети) и, что более к вопросу относится, параметр client-to-client

[thunderamur]

client-to-client в server.conf, позволит клиентам общаться друг с другом напрямую без сервера, верно?

мне нужно сделать, чтобы были разные подсети, наоборот не хочу мешать разные офисы в кучу.


Итак, чтобы мне сделать шлюзы для связи офисов... допустим из подсети 192.168.1.0 я пробую обратится в подсеть 192.168.0.0, что для этого нужно?
Пользователь решил продолжить мысль 19 Декабря 2011, 05:34:05:вот то, что мне нужно:

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

# Push routes to the client to allow it
# to reach other private subnets behind
# the server.  Remember that these
# private subnets will also need
# to know to route the OpenVPN client
# address pool (10.8.0.0/255.255.255.0)
# back to the OpenVPN server.
;push "route 192.168.10.0 255.255.255.0"
;push "route 192.168.20.0 255.255.255.0"

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

# Uncomment this directive to allow different
# clients to be able to "see" each other.
# By default, clients will only see the server.
# To force clients to only see the server, you
# will also need to appropriately firewall the
# server's TUN/TAP interface.
;client-to-client

вот тут сказано, что будут видеть, НО как будут идти пакеты, через сервер всё равно, или напрямую между клиентами пойдут?

[fisher74]

Конечно через сервер.
Я не совсем понял что Вы хотели спросить.
Создайте транспортный уровень "сервер-офисошлюзы", с привязкой IP всем элементам.
А уже через них маршрутизируйте офисные сети статическими маршрутами. Меньше будет путаницы.
Хотя можно, конечно, и с сервера раздавать нужные простым

push "route 192.168.0.0 255.255.0.0"

P.S. локальные сети офисов верно отмаршрутизируются более короткой метрикой.