добрый день, имеются в конторе два провайдера Провайдер A в подсети 10.10.10.0\24 и провайдер Б в подсети 192.168.10.0\24
есть в конторе VPN сервер, как грамотно сделать таким образом чтобы по отклику доменного имени vpn.контора.ru клиентская винда стучала по Провайдеру А, и если Провайдер А не работает, то как сделать так чтобы клиентская винда потом обратилась через провайдер Б по одному и тому же имени vpn.контора.ru
тупо создать несколько A-записей в домен? Round Robin ?
каким образом грамотно и правильно распеределить двух провайдеров (основной и резервный канал) на одно доменное имя?
что-то совсем не впечатляют костыли в виде обновления под "Dyn DNS" A-записи у домена из под рабочего провайдера с минимальным значением EXPIRE/RETRY/REFRESH/TTL в SOA
1. Как вы и сказали Round Robin
2. Скрипт запуска ВПН сделать.
3. На шлюзе скрипт, который проверяет доступность шлюза
4. Сделать динамическую ДНС-зону, чтобы записи обновлялись очень быстро. Тогда никакого RR не надо =).
Возможно есть еще способы. Это просто первое что на ум пришло =).
А вообще можно сделать два идентичных шлюза и воспользоваться такой технологией как CARP или VRRP =)
спасибо, жду ещё варианты, хотелось бы узнать каким образом реализовано у подобных им %)
Адреса серверов:
tp.internet.beeline.ru - для подключения по протоколу L2TP.
vpn.internet.beeline.ru - для подключения по протоколу PPTP.
ведь не висят же сервера обслуживающие такое количество абонентов просто на одном аплинке? угу?
я так предполагаю что сервера провайдера спрятаны за локальным DNS, и таким образом у них территориально решается вопрос о load-balancing, но ни разу не fail-over, угу?
1. Как вы и сказали Round Robin
2. Скрипт запуска ВПН сделать.
3. На шлюзе скрипт, который проверяет доступность шлюза
4. Сделать динамическую ДНС-зону, чтобы записи обновлялись очень быстро. Тогда никакого RR не надо =).
Возможно есть еще способы. Это просто первое что на ум пришло =).
А вообще можно сделать два идентичных шлюза и воспользоваться такой технологией как CARP или VRRP =)
да зоны то разлетаются в момент, вот только потенциальный VPN-клиент может использовать днс с кэшем за натом какого нибудь левого провайдера (не факт что рашка)
ну что горячие головы посоветуют? кроме 1 NAS на аплинк в один общий радиус с бэкендом?
Не нужно заморачиваться с round-robin и прочим. Достаточно обычного скрипта, который при запуске проверяет доступность порта PPPP (или обычного пинга, если такое возможно) на хосте A. Если доступен - подключается к нему, если нет - подключается к B (тут тоже можно вставить проверку доступности порта). Для большей уверенности можно добавить скрипт-проверку (вдруг отпадёт хост А) каждые 2/3/... минут для проверки доступности хоста А.
Я уже 2 года пользуюсь такой схемой и всё нормально работает. Только не ставьте проверки меньше 2 минут, иначе openvpn не сможет нормально сделать handshake (обмен сертификатами и прочей инфой) с удалённой стороной.
Не нужно заморачиваться с round-robin и прочим. Достаточно обычного скрипта, который при запуске проверяет доступность порта PPPP (или обычного пинга, если такое возможно) на хосте A. Если доступен - подключается к нему, если нет - подключается к B (тут тоже можно вставить проверку доступности порта). Для большей уверенности можно добавить скрипт-проверку (вдруг отпадёт хост А) каждые 2/3/... минут для проверки доступности хоста А.
Я уже 2 года пользуюсь такой схемой и всё нормально работает. Только не ставьте проверки меньше 2 минут, иначе openvpn не сможет нормально сделать handshake (обмен сертификатами и прочей инфой) с удалённой стороной.
strongswan, openvpn ни в одном глазу, тьфу тьфу
2-3 минуты критично так как на другой стороне предположительно может сидеть оператор-мартышка и вбивать данные проходящие через ipsec-канал, выполняется данная процедура постоянно и любой обрыв увлекательного бизнес-процесса оператора чреват звонком с вопросом 'рыбятаа! а шо происходит o_O'
спасибо, жду ещё варианты, хотелось бы узнать каким образом реализовано у подобных им %)
Адреса серверов:
tp.internet.beeline.ru - для подключения по протоколу L2TP.
vpn.internet.beeline.ru - для подключения по протоколу PPTP.
ведь не висят же сервера обслуживающие такое количество абонентов просто на одном аплинке? угу?
я так предполагаю что сервера провайдера спрятаны за локальным DNS, и таким образом у них территориально решается вопрос о load-balancing, но ни разу не fail-over, угу?
Мир, на самом деле, чуть сложнее: там вполне может быть какой-нибудь OSPF equal cost path, который решает и проблему с балансировкой нагрузки, и с отказоустойчивостью.
А касательно первоначального вопроса: если под vpn подразумевается какой-нибудь openvpn, то его клиент умеет понимать несколько адресов vpn-серверов в конфигах.
спасибо, жду ещё варианты, хотелось бы узнать каким образом реализовано у подобных им %)
Адреса серверов:
tp.internet.beeline.ru - для подключения по протоколу L2TP.
vpn.internet.beeline.ru - для подключения по протоколу PPTP.
ведь не висят же сервера обслуживающие такое количество абонентов просто на одном аплинке? угу?
я так предполагаю что сервера провайдера спрятаны за локальным DNS, и таким образом у них территориально решается вопрос о load-balancing, но ни разу не fail-over, угу?
Мир, на самом деле, чуть сложнее: там вполне может быть какой-нибудь OSPF equal cost path, который решает и проблему с балансировкой нагрузки, и с отказоустойчивостью.
А касательно первоначального вопроса: если под vpn подразумевается какой-нибудь openvpn, то его клиент умеет понимать несколько адресов vpn-серверов в конфигах.
под VPN подразумевается только strongswan и нативный L2TP/IPSec Windows XP/7/8, желание (иногда и возможность) удалённо ковыряться на клиентах с OpenVPN полностью отсутствует.
интересует только этот сценарий
выносить точку входа на доменное имя вне конторы, т.н. на VDS, абсолютно не вариант вообще, так как начальство конторы может просто забыть/забить на VDS, с провайдерами вопрос об оплате услуг решается из под плётки, при отключении абонента (конторы), абонента (контору) подключают звонком в корпоративные отделы провайдеров с дальнейшей плёточной процедурой оплаты услуг.
