Отказоустойчивость OpenVPN при загрузке

Методы загрузки терминала WTware - дискеты, старт из ДОС, загрузка по сети.
Ответить
PowerZ
Сообщения: 3
Зарегистрирован: Сб июл 18, 2020 10:18 pm

Отказоустойчивость OpenVPN при загрузке

Сообщение PowerZ »

Здравствуйте.
Подскажите, пожалуйста, возникла такая ситуация.

Имеется: WTware 6.0.6 на Raspberry 3

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

Для этого, для надежности на серверной стороне подключены два независимых интернет-канала, со статическими белыми IP-адресами, и сразу настроен проброс в наружу для подключения по RDP к серверу по двум каналам связи.
На клиентской стороне (WTware) настроено:
1. Подключение к основному серверу (1.1.1.1)
2. Подключение к резервному серверу (2.2.2.2)

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

Возникла потребность в удаленном администрирование клиента, - прямое подключение по VNC, поправить локальные конфиги, перезагрузка клиента и т.д. Как будто клиент сейчас в офисе, в локальной сети.
Для этой цели запустили OpenVPN и подключение идет к основному каналу связи (1.1.1.1),
и если по каким-то причинам 1.1.1.1 недоступен, тогда при загрузке клиента происходит «Ошибка OpenVPN failed» и на этом дальнейшая загрузка клиента останавливается, что недопустимо в моей ситуации, и нет тогда никакой отказоустойчивости.

Собственно, сам вопрос, возможно ли так реализовать:

Вариант 1
OpenVPN производит подключение к 1.1.1.1, и если хост не отвечает или какая-либо возникла ошибка подключения, тогда подключение происходит к 2.2.2.2
И тем самым дальнейшая загрузка происходит штатно и доходит до меню выбора подключения к серверу 1 или 2. В добавок, тогда можно отказаться от прямого проброса сервера в наружу по двум провайдерам, что в итоге решается одним активным всегда рабочим VPN-подключением.

Вариант 2
При загрузке, если OpenVPN не смог произвести подключение к 1.1.1.1, тогда просто игнорируется подключение по VPN, и загрузка клиента происходит дальше штатно, не спотыкаясь на подключение по OVPN. Не получилось, так не получилось... Можно пренебречь удаленным администрированием, да и не часто такое бывает нужно.

Возможно ли, такое?
aka
Разработчик
Разработчик
Сообщения: 11003
Зарегистрирован: Ср окт 01, 2003 12:06 am
Откуда: Роcсия, Тольятти
Контактная информация:

Re: Отказоустойчивость OpenVPN при загрузке

Сообщение aka »

Вариант 2 с месагобоксом "OpenVPN не поехало, попробовать ещё раз или продолжить без неё" спасёт русскую демократию?
PowerZ
Сообщения: 3
Зарегистрирован: Сб июл 18, 2020 10:18 pm

Re: Отказоустойчивость OpenVPN при загрузке

Сообщение PowerZ »

aka писал(а):
Вт июл 21, 2020 12:01 am
Вариант 2 с месагобоксом "OpenVPN не поехало, попробовать ещё раз или продолжить без неё" спасёт русскую демократию?
Такое решение думаю подошло бы. А как можно реализовать?
PowerZ
Сообщения: 3
Зарегистрирован: Сб июл 18, 2020 10:18 pm

Re: Отказоустойчивость OpenVPN при загрузке

Сообщение PowerZ »

Пока пошел по варианту №1, удалось реализовать так:
Включил в клиенте OpenVPN ротацию подключений на два хоста

client
dev tun
proto tcp4
nobind
ns-cert-type server
daemon
port 1194
remote-random
remote 1.1.1.1
remote 2.2.2.2


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