Здравствуйте.
Подскажите, пожалуйста, возникла такая ситуация.
Имеется: 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. Не получилось, так не получилось... Можно пренебречь удаленным администрированием, да и не часто такое бывает нужно.
Возможно ли, такое?
Отказоустойчивость OpenVPN при загрузке
-
- Разработчик
- Сообщения: 11851
- Зарегистрирован: Ср окт 01, 2003 12:06 am
- Откуда: Роcсия, Тольятти
- Контактная информация:
Re: Отказоустойчивость OpenVPN при загрузке
Вариант 2 с месагобоксом "OpenVPN не поехало, попробовать ещё раз или продолжить без неё" спасёт русскую демократию?
Re: Отказоустойчивость OpenVPN при загрузке
Пока пошел по варианту №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
…
Пока сбоев не было. Подключение происходит в случайном порядке на один из хостов, и если хост не отвечает, тогда цепляется на второй. Конечно, не совсем правильное решение отказоустойчивости, но так работает. Просто потупит немного при неудачной попытке подключения и идет коннект на другой хост. Если оба не отвечают хоста, тогда еще больше потупит и в итоге ошибка. Но тогда уже вообще не актуально, так как полный даун по всем хостам и работать нельзя будет всё равно.
Включил в клиенте 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
…
Пока сбоев не было. Подключение происходит в случайном порядке на один из хостов, и если хост не отвечает, тогда цепляется на второй. Конечно, не совсем правильное решение отказоустойчивости, но так работает. Просто потупит немного при неудачной попытке подключения и идет коннект на другой хост. Если оба не отвечают хоста, тогда еще больше потупит и в итоге ошибка. Но тогда уже вообще не актуально, так как полный даун по всем хостам и работать нельзя будет всё равно.