Failover GW + OpenVPN



  • Всем доброго дня. Есть конфигурация с двумя wan_gw из них собран failover_gw. OpenVPN server слушает на failover_gw. Есть две проблемы:

    1. При отключении основного gw (tier 1) через пару минут к серверу никто из клиентов не подключился (их более 20, все ставились из client export)
    2. При подключении основного gw обратно, соединения по прежнему идут через второй gw (на который переключились при отключении основного), ровно до тех пор пока не перезапустишь OpenVPN серверы, тогда сразу возвращаемся на первый gw и OPenVPN клиенты тут же появляются

    ps галочка Flush all states when a gateway goes down стоит
    pps можно конечно попробовать повесить openvpn серверы на локалхост разные порты, но почему то кажется что должно работать и через failover_gw



  • но почему то кажется что должно работать и через failover_gw
    Через failover можно, наверное, выпускать клиента OpenVPN. Вешать на failover, предназначенный для исходящих соединений службы, ожидающие, входящих соединений, IMHO, неверно.

    Похожая сегодняшняя тема:
    https://forum.pfsense.org/index.php?topic=128827.0



  • @pigbrother:

    но почему то кажется что должно работать и через failover_gw
    Через failover можно, наверное, выпускать клиента OpenVPN. Вешать на failover, предназначенный для исходящих соединений службы, ожидающие, входящих соединений, IMHO, неверно.

    Похожая сегодняшняя тема:
    https://forum.pfsense.org/index.php?topic=128827.0

    тему конечно читал, хотел даже в ней вопрос задать, но

    1. почему в интерфейсах впн сервера есть возможность выбора интерфейса фейловер ?
    2. я вообще не вижу противоречий, при падении главного гейтвея впн сервер должен перезапуститься на запасном, при восстановлении - перезапуститься на основном (я так вижу этот функционал)

    ps готов почитать все пруф и бест практис линки на английском и русском языках



  • https://forum.pfsense.org/index.php?topic=127210.msg702207#msg702207

    вот товарищ тоже интересуется такой же реализацией



  • Пруфов не будет, будет IMHO

    1) почему в интерфейсах впн сервера есть возможность выбора интерфейса фейловер ?
    Потому, что может. Потому, что в списке интерфейсов есть вообще все интерфейсы, которые pfSense знает.

    2) я вообще не вижу противоречий, при падении главного гейтвея впн сервер должен перезапуститься на запасном, при восстановлении - перезапуститься на основном (я так вижу этот функционал)
    Потому, что и faiolver и load balance задуманы как механизмы работы с multiwan в другом направлении - из LAN в интернет.

    Интерфейс (в реальности - IP) и порт , на котором OVPN-сервер ждет подключения - это директивы
    local (1.2.2.2)
    и
    lport (1194)

    где 1.2.2.2 - IP-адрес, а не "виртуальное" имя мультивана, которым pfSense пользуется для организации исходяших  faiolver и load balance.

    Посмотрите, плз, как будет выглядеть директива local в конфиге сервера (/var/etc/openvpn/serverХ.conf)
    при указании в GUI failover_gw как интерфейса?

    Еще раз IMHO - искомый вами вариант если теоретически и возможен, то во взаимодействии  OVPN с pfSense не реализован.



  • Доброе.
    @winmasta:

    https://forum.pfsense.org/index.php?topic=127210.msg702207#msg702207

    вот товарищ тоже интересуется такой же реализацией

    По ссылке внизу есть решение с приязкой Openvpn к Localhost. Решение рабочее - у меня так и работало. Воспользуйтесь.



  • Всем спасибо, все понял.



  • pfSense при выборе интерфейса OpenVPN-сервера выводит группу с примечанием GW group. По идее группы не должно быть видно вообще, так как это группа шлюзов, а привязывается  OpenVPN-сервер к интерфейсу.



  • @pigbrother:

    pfSense при выборе интерфейса OpenVPN-сервера выводит группу с примечанием GW group. По идее группы не должно быть видно вообще, так как это группа шлюзов, а привязывается  OpenVPN-сервер к интерфейсу.

    Было бы неплохо если бы был механизм который (для фэйловера с двумя интерфейсами):

    1)при запуске впн сервера на группе шлюзов проверяет какой из них сейчас активен и поднимает сервер на соответствующем интерфейсе
    2)при падении главного шлюза впн сервер перезапускается на интерфейсе второго шлюза
    3)при восстановлении главного шлюза впн сервер опять перезапускается на первом интерфейсе



  • В продолжение темы https://forum.pfsense.org/index.php?topic=128936.0



  • вот эта проблема по прежнему актуальна

    1. При подключении основного gw обратно, соединения по прежнему идут через второй gw (на который переключились при отключении основного), ровно до тех пор пока не перезапустишь OpenVPN серверы, тогда сразу возвращаемся на первый gw и OPenVPN клиенты тут же появляются

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

    как же быть ?



  • ДА…............
    Та же проблема...
    Нашел один скрипт который решает этот вопрос.
    Но  не как не могу понять как запустит.

    вот он.

    #!/usr/local/bin/php -f
    require_once('config.inc');
    include('openvpn.inc');

    if ($argc != 2)
    {
      echo "Usage: " . basename($argv[0]) . " <full or="" partial="" vpn="" client="" name="">\n";
      exit;
    }
    $name = $argv[1];

    $msg = "Checking whether the $name VPN client needs a restart.";
    echo $msg."\n";
    exec("logger '$msg'");

    // Read in all of the OpenVPN client configs.
    global $config;
    if (!is_array($config['openvpn']['openvpn-client']))
    {
      return;
    }

    // Find client config for given name
    $found_config = false;
    foreach ($config['openvpn']['openvpn-client'] as & $settings)
    {
      if (stripos($settings['description'], $name) !== false)
      {
        $found_config = true;
        break;
      }
    }

    // If client config not found, exit.
    if (!$found_config)
    {
      echo "Did not find client VPN config for "$name".\n";
      exit;
    }

    // Print the client config.
    echo "\n–--Client configuration----\n";
    echo "vpnid: {$settings['vpnid']}\n";
    echo "description: {$settings['description']}\n";
    echo "server_addr: {$settings['server_addr']}\n"; 
    echo "custom_options: {$settings['custom_options']}\n\n";

    // Resolve the configured host name to an IP address.
    // This is the VPN server's primary IP.
    if (is_ipaddr($settings['server_addr']))
    {
      $ip_primary = $settings['server_addr'];
    }
    else
    {
      $ip_primary = gethostbyname($settings['server_addr']);
      if ($ip_primary == $settings['server_addr'])
      {
        echo "DNS lookup failed for VPN server primary hostname ({$settings['server_addr']}). Exiting.\n";
        exit;
      }
    }
    echo "VPN server primary IP: $ip_primary\n";

    // Tokenize the custom_options to get the VPN
    // server's secondary IP.
    $tok = strtok($settings['custom_options'], " \n\t;");
    while ($tok !== false)
    {
      if (strcasecmp($tok, 'remote') == 0)
      {
        $tok = strtok(" \n\t;");
        if ($tok !== false)
        {
          if (is_ipaddr($tok))
          {
            $ip_secondary = $tok;
          }
          else
          {
            $ip_secondary = gethostbyname($tok);
            if ($ip_secondary == $tok)
            {
              echo "DNS lookup failed for VPN server secondary hostname ($tok). Exiting.\n";
              exit;
            }
          }
          echo "VPN server secondary IP: $ip_secondary\n";   
        }
      }
      $tok = strtok(" \n\t;");
    }

    // Find the status for the VPN client.
    $found_status = false;
    $clients = openvpn_get_active_clients();
    foreach ($clients as $client)
    {
      if (stripos($client['name'], $name) !== false)
      {
        $found_status = true;
        break;
      }
    }

    // If client status not found, exit.
    if (!$found_config)
    {
      echo "Did not find VPN client status for "$name".\n";
      exit;
    }

    // Print the client status
    echo "\n----Client status----\n";
    echo "name: {$client['name']}\n";
    echo "mgmt: {$client['mgmt']}\n";
    echo "status: {$client['status']}\n";
    echo "remote_host: {$client['remote_host']}\n";

    // See if the client is connected to a secondary IP.
    // Note: $client['remote_host'] has trailing white space that
    // we must trim before comparing to $ip_primary
    $remote_host = rtrim($client['remote_host']);
    if ($client['status'] == 'up' && $remote_host == $ip_primary)
    {
      $msg = "The $name VPN client is connected to $remote_host (VPN server primary IP). Not restarting client.";
      echo $msg."\n";
      exec("logger '$msg'");
      exit;
    }
    else if ($client['status'] == 'up')
    {
      $msg = "The $name VPN client is connected to $remote_host (VPN server secondary IP).";
      echo $msg."\n";
      exec("logger '$msg'");
    }
    else
    {
      $msg = "The $name VPN client is not connected. Current status is {$client['status']}.";
      echo $msg."\n";
      exec("logger '$msg'");
      exit;
    }

    // If we got this far, we will want to restart the VPN client
    // so it connects to primary IP instead of secondary IP.

    // Before trying to connect to primary IP, we have to make sure
    // we can ping it. If we can't ping it, there's no sense in
    // trying to connect to it. Furthermore, that is probably
    // the reason why the client is currently connected to the
    // secondary IP.
    exec("ping -t 10 -o $ip_primary", $output, $return_var);
    echo "ping return_var: $return_var\n";

    // A return value of 0 means at least one ping was replied to.
    // In other words, the IP address is up and we should be
    // able to restart to VPN to connect to it.
    if ($return_var == 0)
    {
      $msg = "VPN server primary IP is up. Restarting $name VPN client.";
      echo $msg."\n";
      exec("logger '$msg'");

    // Restart the VPN client by mimicking the technique used in
      // the file /usr/local/www/status_services.php
      //openvpn_restart('client', $settings);
      $configfile = "{$g['varetc_path']}/openvpn/client{$settings['vpnid']}.conf";
      $pidfile =    "{$g['varrun_path']}/openvpn_client{$settings['vpnid']}.pid";
      if (file_exists($configfile))
      {
        $msg = "Terminating openvpn using pidfile: $pidfile";
        echo $msg."\n";
        exec("logger '$msg'");
        killbypid($pidfile);
        // wait for process to terminate
        sleep(1);
        $msg = "Starting new openvpn process using config file: $configfile";
        echo $msg."\n";
        exec("logger '$msg'");
        mwexec_bg("/usr/local/sbin/openvpn --config {$configfile}");
      }

    $msg = "Finished restarting $name VPN client.";
      echo $msg."\n";
      exec("logger '$msg'");
    }
    else
    {
      $msg = "VPN server primary IP is down. Not restarting $name VPN client.";
      echo $msg."\n";
      exec("logger '$msg'");
    }
    ?></full>



  • Это похоже скрипт для перезапуска впн КЛИЕНТА pfsense, а у меня проблема в серверах, впн сервера не дают сенсу переключить дефолтный шлюз обратно при восстановлении основного, пока вручную не перезапустишь впн серверы.



  • Подскажите а как можно удаленно перезапустить впн серверы на сенсе. Может убить процессы и запустить заново ?



  • @winmasta:

    Подскажите а как можно удаленно перезапустить впн серверы на сенсе. Может убить процессы и запустить заново ?

    Вроде было какое-то API - не уверен правда. как вариант смотреть — Status/Services



  • сделал скриптец один, сегодня проверю, если все отработает - опишу решение



  • в общем есть такой скрипт

    #!/bin/sh
    pgrep openvpn | xargs kill -9
    /usr/local/sbin/openvpn –config /var/etc/openvpn/server1.conf
    /usr/local/sbin/openvpn --config /var/etc/openvpn/server2.conf

    который перезапускает openvpn серверы (может кто-то знает лучший вариант - напишите)
    как бы теперь его запускать по событию падения gateway (причем любого)



  • Доброе.
    Вы так и не убрали впн с группы интерфейсов ?



  • @werter:

    Доброе.
    Вы так и не убрали впн с группы интерфейсов ?

    Убрал, теперь серверы локалхост слушают.



  • Тогда зачем отслеживать падение gw для впн серверов ? Failover для опенвпн настраивается на клиентах. В конфиге клиентов, напр. :

    ...
    remote 1.1.1.1 1194 udp
    remote 2.2.2.2 1195 udp
    remote-random
    ...
    

    Всё. Клиент будет перебирать адреса впн-серверов. Недоступен один - подкл. к другому.



  • @winmasta:

    вот эта проблема по прежнему актуальна

    1. При подключении основного gw обратно, соединения по прежнему идут через второй gw (на который переключились при отключении основного), ровно до тех пор пока не перезапустишь OpenVPN серверы, тогда сразу возвращаемся на первый gw и OPenVPN клиенты тут же появляются

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

    как же быть ?

    Вот поэтому.



  • нашел интересную тему https://forum.pfsense.org/index.php?topic=65846.0 там вроде как описано, что можно через файл /etc/devd.conf по событию запускать команды, может кто в курсе как в этот файл добавить инструкцию по перезапуску впн сервера при падении wan ?

    и еще интересная старая тема, https://forum.pfsense.org/index.php?topic=42000.0 там есть строка на php по перезапуску openvpn (я так понял аналог нажатия на кнопку "перезапустьть опенвпн сервер"), но она не работает, может знатоки ее подправят ?



  • Доброе.
    А если понизить tier (вес) до 2 второму WAN ?



  • это было сделано изначально



  • Тоже спрошу в этой теме:

    Имеем 2х провайдеров в режиме "load balance", OpenVPN cервер  слушающий locallhost. У клиентов прописаны оба внешних адреса.
    Проблема появляется когда у клиента  пропадает интернет и подключение проходит через второй адрес, но ответные пакеты при этом приходят с первого адреса. Помогает "сброс" подключения на стороне сервера. Есть ли какое ни будь решение?



  • Доброе.

    Проблема появляется когда у клиента  пропадает интернет и подключение проходит через второй адрес

    С чего бы клиенту точно подкл. на 2-ой впн? Пропал инет у клиента, появился, соединение пошло на тот адрес, к-ый указан первым в конфиге клиента.
    Покажите конфиг клиента.



  • @werter:

    Доброе.

    Проблема появляется когда у клиента  пропадает интернет и подключение проходит через второй адрес

    С чего бы клиенту точно подкл. на 2-ой впн? Пропал инет у клиента, появился, соединение пошло на тот адрес, к-ый указан первым в конфиге клиента.
    Покажите конфиг клиента.

    @werter:

    Тогда зачем отслеживать падение gw для впн серверов ? Failover для опенвпн настраивается на клиентах. В конфиге клиентов, напр. :

    ...
    remote 1.1.1.1 1194 udp
    remote 2.2.2.2 1195 udp
    remote-random
    ...
    

    Всё. Клиент будет перебирать адреса впн-серверов. Недоступен один - подкл. к другому.

    Может быть из-за  remote-random, который для failover, imho, не нужен?



  • Дело не в remote-random. Клиент - чаще всего виндовая машина за роутрером. Теряется инет, но связь то до роутера остаётся. Клиент и реконектится на следующий адрес.
    Ну это я так понимаю… Поправьте если что то не так



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

    0. Устанавливаем и настраиваем пакет zabbix-agent на нашем pfsense, настраиваем узел сети для нашего pfsense, проверяем, что заббикс агент видит заббикс сервер и наоборот. В настройках zabbix-agent нажав Advanced Options в поле User Parameters добавляем

    EnableRemoteCommands=1
    

    1. Создаем на заббикс сервере скрипт в разделе Администрирование-Скрипты следующего содержания

    sudo -S sh /usr/openvpnrestart.sh
    

    2. Создаем на заббикс сервере узел сети в разделе Настройки-Узлы сети с любым названием (например providerNameGw) и ip адресом нужного gateway (в моем случае это основной шлюз, за ним и будем следить). Присоединяем к этому узлу шаблон Template ICMP Ping. Далее заходим в элементы данных этого узла, открываем элемент ICMP Ping и в поле Интервал обновления (в сек) выставляем желаемый интервал "пингования" шлюза (я себе поставил 10 сек). Далее заходим в триггеры и (чтобы не изменять триггер шаблона) создаем новый триггер с именем например {HOST.NAME} is DOWN и с выражением {providerNameGw:icmpping.max(#6)}=0 это значит, что после 6 неудачных пингов каждый через 10 сек (итого 6 раз * 10 сек = 1 мин) сработает триггер.

    3. Создаем на заббикс сервере действие в разделе Настройки-Действия для источника событий Триггеры (выбрать в меню в правом верхнем углу) с именем например openvpn restart, обязательно ставим галку Сообщение о восстановлении. На вкладке Условия удаляем все условия и добавляем единственное Триггер = ИМЯ_ТРИГГЕРА например в нашем случае будет providerNameGw is DOWN. На вкладке операции добавляем операцию Длительность шага операции по умолчанию (я поставил 60 секунд), Шаги 1-1, Длительность шага - 0 (по умолчанию), Тип операции - Удаленная команда, в Список целей добавляем наш pfsense (из шага 0), Тип-Глобальный скрипт (хотя тут можно было и пользовательский прямо в действии прописать, но вдруг у нас будет много pfsens'ов), имя скрипта - из шага 1, нажимаем Обновить

    4. Устанавливаем пакет sudo на pfsense. Заходим в настройку System-sudo, выбираем Custom Configuration - Include at Start.

    5. Заходим по ssh на наш pfsense (если ssh не включен, то включаем в System-Advansed раздел Secure Shell) и создаем там скрипт например в папке /usr с названием openvpnrestart.sh и с содержимым

    #!/bin/sh
    pgrep openvpn | xargs kill -9
    /usr/local/sbin/openvpn --config /var/etc/openvpn/server1.conf
    /usr/local/sbin/openvpn --config /var/etc/openvpn/server2.conf
    
    

    если у вас один сервер, то нижнюю строку убираем, если 3 то добавляем еще одну поменяв номер сервера и т.д. по анологии. Делаем скрипт исполняемым (на всякий случай, хотя у меня он и без этого выполняется)

    sudo chmod a+x /usr/openvpnrestart.sh
    

    6. Создаем файл в папке /usr/local/etc/sudoers.d с именем например zabbix и следующим содержимым

    zabbix ALL=NOPASSWD: /bin/sh /usr/openvpnserver.sh
    

    ВСЁ! Теперь при отсутствии шлюза в течение минуты сработает триггер, который перезапустит пн серверы на нашем pfsense, как только шлюз вновь будет доступен, впн серверы перезапустятся снова.
    В реальных условиях буду тестировать завтра, если где ошибся или не прав, сообщите.



  • С нетерпением жду тестов и бегу разворачивать Zabbix



  • Еще назрел вопрос: а что если вместо внешних ip указать dns имена (А записи)? Есть ли какие то подводные камни? И как лучше сделать: 2 А-записи на разные ip или 1 A-запись с разным приоритетом ip?



  • @PavelSv:

    Еще назрел вопрос: а что если вместо внешних ip указать dns имена (А записи)? Есть ли какие то подводные камни? И как лучше сделать: 2 А-записи на разные ip или 1 A-запись с разным приоритетом ip?

    У нас сделано так: есть ddns имя, в сети (не на pfsense а отдельно) стоит dynamic updater от noip с интервалом обновления 1 минута, при отвале основного шлюза в течение минуты записи обновляются, но вот когда эти обновления дойдут до клиентов - большой вопрос, однако по результатам тестов руководство устраивает такая схема. Возможно лучший вариант все таки 2 remote на клиентах, первый - основной, второй - резервный, при рестарте сервера сначала клиенты всегда будут стучать на первый.

    Не совсем понятно, что значит "А-запись с разным приоритетом ip", возможно имеется ввиду roundrobin ?

    PS теста похоже не будет, обещали с утра свет отключить, но видимо не будут. С другой стороны вчера на "левом" триггере несколько раз оттестировал - работает (серверы рестартуют, что и требуется).



  • winmasta,
    Нарыл в своих запасниках рестартер Open VPN, который пару раз использовал на 2.0.2

    echo "" | php -q
    

    Проверил - вроде работает и сейчас,  из консоли, через SSH, через pitty\plink свежих версий.
    Полная версия, из которой взял нужный кусок выглядит так:

    /usr/bin/time -h sh -c 'RUNNING=`ps ax | grep openvpn | grep -v grep`; while [ -n "$RUNNING" ]; do RUNNING=`ps ax | grep openvpn | grep -v grep`;  done' | & awk '{print $3}' & echo '' | php -q
    

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



  • @pigbrother:

    winmasta,
    Нарыл в своих запасниках рестартер Open VPN, который пару раз использовал на 2.0.2

    echo "" | php -q
    

    Проверил - вроде работает и сейчас,  из консоли, через SSH, через pitty\plink свежих версий.
    Полная версия, из которой взял нужный кусок выглядит так:

    /usr/bin/time -h sh -c 'RUNNING=`ps ax | grep openvpn | grep -v grep`; while [ -n "$RUNNING" ]; do RUNNING=`ps ax | grep openvpn | grep -v grep`;  done' | & awk '{print $3}' & echo '' | php -q
    

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

    попробовал выполнить - ничего не произошло, версия 2.3.3, где то я эту строку уже находил



  • Оба варианта пробовали?



  • Если еще актуально.
    Корректный стоп\старт\рестарт индивидуального экземпляра Open VPN сервера. Возможно - и клиента, это не проверял.

    pfSsh.php playback svc stop openvpn server 2

    Starting the pfSense developer shell….
    Attempting to issue stop to openvpn service...
    openvpn has been stopped.

    pfSsh.php playback svc start openvpn server 2

    Starting the pfSense developer shell….
    Attempting to issue start to openvpn service...
    openvpn has been started.

    pfSsh.php playback svc restart openvpn server 2

    Starting the pfSense developer shell….
    Attempting to issue restart to openvpn service...
    openvpn has been restarted.

    server 2 - то, что в
    /var/etc/openvpn
    соответствует server2.conf

    Используется PHP pfSense Shell. Теретически можно писать подобие макросов.
    https://doc.pfsense.org/index.php/Using_the_PHP_pfSense_Shell

    Создам, пожалуй, отдельный пост.