Два Pfsense, на каждом 2 WAN, OpenVPN PSK



  • Есть 2 удаленных PfSense, в каждый заведено по 2 провайдера, соответственно, настроено 4 туннеля перекрестно.
    1. 1 интерфейс сервер - 1 интерфейс клиент
    2. 1 интерфейс сервер - 2 интерфейс клиент
    3. 2 интерфейс сервер - 1 интерфейс клиент
    4. 2 интерфейс сервер - 2 интерфейс клиент

    На всех 4 статус "up". Виртуальные адреса по всем 4м туннелям (разные) пингуются в обе стороны. Пинги между локалками тоже есть, но это все пока все интерфейсы активны.
    Если остановить сервис 1го или 2го тунеля, то связь пропадает, остановка 3го и 4го ни на что не влияет.
    Если стопнуть 1 интерфейс сервера - связь пропадает.
    Если стопнуть 1 интерфейс клиента - связь пропадает.
    Остановка 2х интерфейсов на свзяь не влияет.
    Пропадает только связь по VPN, интернет остается.
    На сервере между 2мя WAN - файловер, причем интерфейс 2 приоритетный.
    На клиенте - балансировка нагрузки между шлюзами.

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



  • Я рекомендую вам в начале проверить по каким маршрутам происходят все эти соединения.
    И обратить внимание на таблицу маршрутизации после установки VPN соединений.



  • Полез смотреть routes, выяснил что сервер в локалку клиента ходит по ovpns1, а клиент в локалку сервера по ovpns2 - отсюда то, что писал выше, остановка любого из сервисов приводила к потере пинга. При этом переключение на другой канал не происходило. Начал дальше изучать тему, установил везде Quagga OSPFd, настроил, согласно инструкции https://forum.pfsense.org/index.php/topic,58846.0.html (в сети можно найти эту же инструкцию с работающими картинками). Вроде бы сначала показалось, что все заработало. Но, во-первых, при перезапуске одного из сервисов на Status/OpenVPN периодически происходит сбой, по которому System Logs говорит:

    Jun 19 12:19:29 openvpn 91044 OpenVPN 2.3.14 i386-portbld-freebsd10.3 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on May 3 2017
    Jun 19 12:19:29 openvpn 91044 library versions: OpenSSL 1.0.1s-freebsd 1 Mar 2016, LZO 2.10
    Jun 19 12:19:30 openvpn 91128 NOTE: the current –script-security setting may allow this configuration to call user-defined scripts
    Jun 19 12:19:30 openvpn 91128 TUN/TAP device ovpns2 exists previously, keep at program end
    Jun 19 12:19:30 openvpn 91128 TUN/TAP device /dev/tun2 opened
    Jun 19 12:19:30 openvpn 91128 do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0
    Jun 19 12:19:30 openvpn 91128 /sbin/ifconfig ovpns2 10.10.11.1 10.10.11.2 mtu 1500 netmask 255.255.255.255 up
    Jun 19 12:19:30 openvpn 91128 FreeBSD ifconfig failed: external program exited with error status: 1
    Jun 19 12:19:30 openvpn 91128 Exiting due to fatal error

    Перезагрузка помогает, все стартует.
    Во-вторых, метрика выставлена, как на сервере, так и на клиенте ovpns1 30, ovpns2 40, ovpns3 10, ovpns4 20, т.е. по умолчанию должен подключаться по ovpns3, но после перезагрузки в routes между локалками ovpns1.
    Снимаю галочку Enable Interface на первом интерфейсе сервера, отключая тем самым ovpns1 и ovpns2, сервер переходит на ovpns3 автоматически, а клиент остается висеть на ovpns1, т.е. VPN опять не работает.

    Что я не так делаю?



  • Добавлю. Удаление Quagga OSPFd, рестарт и OpenVPN без проблем перезапускается, но нет файловера. Кроме того, понял, что количество wan на клиенте не имеет значения, ибо можно клиента пустить через loadbalance шлюз. В таком случае туннелей будет только 2, а не 4.



  • По поводу отключения одного из интерфейсов OpenVPN и зависанием сессии с другой стороны — у OpenVPN есть таймауты, как и у соединений. Может из-за этого и не происходит востановление.
    Как вариант можно попробовать использовать одну VPN сессию используя на клиенте параметр backup-server (я точно не уверен как этот параметр называется), на форуме есть примеры и решения, но там тоже что-то есть с проблемами обратного переключения и подобного.



  • @PbIXTOP:

    По поводу отключения одного из интерфейсов OpenVPN и зависанием сессии с другой стороны — у OpenVPN есть таймауты, как и у соединений. Может из-за этого и не происходит востановление.
    Как вариант можно попробовать использовать одну VPN сессию используя на клиенте параметр backup-server (я точно не уверен как этот параметр называется), на форуме есть примеры и решения, но там тоже что-то есть с проблемами обратного переключения и подобного.

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

    "10.10.12.2        link#9            UH      ovpns3"

    Далее на route delete 10.10.12.2 выдает:

    route: writing to routing socket: Address already in use
    delete host 10.10.12.2 fib 0: gateway uses the same route

    Погуглил, пишут что с FreeBSD 9.2 есть такая проблема, решения никто придумать не может.



  • Доброе.
    А если впн-интерфейсы объявить явно и создать из них failover group на клиенте ?



  • @werter:

    Доброе.
    А если впн-интерфейсы объявить явно и создать из них failover group на клиенте ?

    А для чего? На сервере тоже 2 интерфейса и от зебры все равно никуда не уйти.



  • Вообщем, штудирование англоязычной ветки, помогло. Теперь все работает. Виртуальные интерфейсы перезапускаются по требованию, переключение на другой туннель согласно метрике OSPF происходит также при отключении виртуального, либо реального WAN интерфейса.
    Решение такое. В zebra.conf через Raw Config написать вручную конфигурацию.

    This file was created by the pfSense package manager.  Do not edit!

    password ******
    log syslog
    ip prefix-list ACCEPTFILTER deny 10.10.12.1/32
    ip prefix-list ACCEPTFILTER deny 10.10.10.1/32
    ip prefix-list ACCEPTFILTER deny 10.10.13.1/32
    ip prefix-list ACCEPTFILTER deny 10.10.11.1/32
    ip prefix-list ACCEPTFILTER permit any
    route-map ACCEPTFILTER permit 10
    match ip address prefix-list ACCEPTFILTER
    ip protocol ospf route-map ACCEPTFILTER

    На клиенте, соответственно, вместо единицы двойка в последнем числе ип-адреса. Что дают эти строки, слабо представляю, ибо знание английского не на высоте, но все работает. Осталось цепануть еще виндовый комп ко всему этому, чтобы видно было обе подсети, а, также, роутер зухел, но это уже другая история.