OpenVPN переключиться обратно на основной сервер после восстановления соединения на pfSense

У меня есть две идеи

1. Вы могли бы заставить OpenVPN ждать, пока не прекратится активность (если возможно, может быть, ночью?), А затем автоматически разорвать соединение или повторно разрешить IP-адрес сервера (и, возможно, сделать что-то сложное / творческое с DNS). Я ничего из этого не тестировал, я просто просмотрел документацию. Похоже, это может сработать для вас, вам просто нужно поэкспериментировать.

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

Извлечено из справочной страницы OpenVPN: https://openvpn.net/index.php/open-source/documentation/manuals/65-openvpn-20x-manpage.html

- неактивный n (Экспериментально) Заставляет OpenVPN завершать работу через n секунд бездействия на устройстве TUN / TAP. Время бездействия измеряется с момента последнего входящего туннельного пакета.

- пинг n Удаленный эхо-запрос по каналу управления TCP / UDP, если в течение как минимум n секунд не было отправлено ни одного пакета (укажите --ping на обоих одноранговых узлах, чтобы пакеты ping отправлялись в обоих направлениях, поскольку пакеты ping OpenVPN не отражаются, как пакеты ping IP) . При использовании в одном из безопасных режимов OpenVPN (где указаны --secret, --tls-server или --tls-client) пакет ping будет криптографически безопасным. У этой опции есть два предполагаемых использования:

(1) Совместимость с межсетевыми экранами с отслеживанием состояния. Периодический пинг гарантирует, что правило брандмауэра с отслеживанием состояния, которое позволяет проходить UDP-пакетам OpenVPN, не истечет.

(2) Предоставить удаленному устройству основу для проверки существования своего партнера с помощью опции --ping-exit.

--ping-exit n Заставляет OpenVPN завершать работу через n секунд без получения пинга или другого пакета от удаленного компьютера. Эту опцию можно комбинировать с --inactive, --ping и --ping-exit для создания двухуровневого отключения при бездействии. Например,

openvpn [параметры ...] --inactive 3600 --ping 10 --ping-exit 60

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

--ping-restart n Аналогично --ping-exit, но запускает перезапуск SIGUSR1 по прошествии n секунд без приема эхо-запроса или другого пакета от удаленного устройства. Этот параметр полезен в случаях, когда удаленный узел имеет динамический IP-адрес, а DNS-имя с низким TTL используется для отслеживания IP-адреса с помощью такой службы, как http://dyndns.org/ + динамический DNS-клиент, такой как ddclient.

Если одноранговый узел недоступен, запускается перезапуск, в результате чего имя хоста, используемое с --remote, будет повторно разрешено (если также указано --resolv-retry).

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

В клиентском режиме для параметра --ping-restart по умолчанию установлено значение 120 секунд. Это значение по умолчанию будет сохраняться до тех пор, пока клиент не получит заменяющее значение с сервера на основе параметра --keepalive в конфигурации сервера. Чтобы отключить 120 секунд по умолчанию, установите --ping-restart 0 на клиенте.

См. Раздел сигналов ниже для получения дополнительной информации о SIGUSR1.

Обратите внимание, что поведение SIGUSR1 можно изменить с помощью параметров --persist-tun, --persist-key, --persist-local-ip и --persist-remote-ip.

Также обратите внимание, что --ping-exit и --ping-restart являются взаимоисключающими и не могут использоваться вместе.

Предлагаю прочитать мануал. Там еще кое-что.

Смотрите также это - обсуждение этого вопроса в PfSense: https://forum.pfsense.org/index.php?topic=42935.0

2. Другой вариант - запустить скрипт (перезапустить OpenVPN?) При изменении статуса интерфейса. Это также, я не собираюсь проходить тестирование или что-то в этом роде, но я нашел некоторое обсуждение этого.

https://forum.pfsense.org/index.php?topic=65846.0

По-видимому, вы можете хранить команды в /etc/devd.conf

Моя содержит:

# $Id$
# $FreeBSD: src/etc/devd.conf,v 1.26.2.1 2005/09/03 22:49:22 sam Exp $

options {
        directory "/etc/devd";
        directory "/usr/local/etc/devd";
        pid-file "/var/run/devd.pid";
        set scsi-controller-regex
                "(aac|adv|adw|aha|ahb|ahc|ahd|aic|amd|amr|asr|bt|ciss|ct|dpt|\
                esp|ida|iir|ips|isp|mlx|mly|mpt|ncr|ncv|nsp|stg|sym|trm|wds)\
                [0-9]+";
};

# CARP notify hooks. This will call carpup/carpdown with the
# interface (carp0, carp1) as the first parameter.
notify 100 {
    match "system"          "CARP";
    match "type"            "MASTER";
    action "/usr/local/sbin/pfSctl -c 'interface carpmaster $subsystem'";
};

notify 100 {
    match "system"          "CARP";
    match "type"            "BACKUP";
    action "/usr/local/sbin/pfSctl -c 'interface carpbackup $subsystem'";
};

notify 100 {
    match "system"          "CARP";
    match "type"            "INIT";
    action "/usr/local/sbin/pfSctl -c 'interface carpbackup $subsystem'";
};

# When a USB keyboard arrives, attach it as the console keyboard.
attach 100 {
        device-name "ukbd0";
        action "kbdcontrol -k /dev/ukbd0 < /dev/console 2>/dev/null";
};

detach 100 {
        device-name "ukbd0";
        action "kbdcontrol -k /dev/kbd0 < /dev/console 2>/dev/null";
};

#
# Signal upper levels that an event happened on ethernet class interface
#
notify 0 {
        match "system"          "IFNET";
        match "type"            "LINK_UP";
        media-type              "ethernet";
        action "/usr/local/sbin/pfSctl -c 'interface linkup start $subsystem'";
};

notify 0 {
        match "system"          "IFNET";
        match "type"            "LINK_DOWN";
        media-type              "ethernet";
        action "/usr/local/sbin/pfSctl -c 'interface linkup stop $subsystem'";
};

#
# Signal upper levels that an event happened on 802.11 class interface
#
notify 0 {
        match "system"          "IFNET";
        match "type"            "LINK_UP";
        match "subsystem"       "[a-z]+[0-9]+_wlan[0-9]+";
        action "/usr/local/sbin/pfSctl -c 'interface linkup start $subsystem'";
};

# Notify all users before beginning emergency shutdown when we get
# a _CRT or _HOT thermal event and we're going to power down the system
# very soon.
notify 10 {
        match "system"          "ACPI";
        match "subsystem"       "Thermal";
        match "notify"          "0xcc";
        action "logger -p kern.emerg 'WARNING: system temperature too high, shutting down soon!'";
};

Может это сработает для тебя