@rapidspacerocket

Резервный канал через PBR. Как быть с публикуемыми сервисами?

Есть задача подключить в конторе резервный ISP, внутри компании есть несколько сервисов, которыми пользуются удалённые сотрудники — Web, VPN, SMTP. Основная проблема — как быть с публикуемыми сервисами, чтобы при отвале одного из провайдера наши сервисы продолжали быть доступными для удалённых сотрудников. Самый очевидный способ — это развернуть BGP, купить номер AS и провайдеро-независимые адреса. Тогда на публикуемых сервисах адреса не будут меняться, если какой-то канал падает. Второй способ, который в наших условиях проще развернуть, соответственно он и более предпочтителен — организация переключения на резервный канал с помощью политик PBR и IPSLA. Но в этом случае при отказе основного канала на публикуемых серверах будет меняться IP-адрес. Как сделать так, чтобы при смене IP-адреса сервис оставался доступным, пусть даже с разрывом сессии? Ну с почтой понятно, создаём несколько MX записей. Cisco Easy VPN тоже вроде не сложно в этом плане настроить — указываем backup-серверы. А вот как быть с Web? поможет ли тут DNS round robin? Или проще всё таки развернуть BGP?
  • Вопрос задан
  • 4028 просмотров
Пригласить эксперта
Ответы на вопрос 6
heathen
@heathen
Ну, если вас не пугает стоимость решения с BGP, то в любом случае это из пушки по воробьям (хотя, возможно, я недооцениваю размеры вашей организации). В общем же случае для веба, с которым работают сотрудники, разве недостаточно будет простого DDNS?
Ответ написан
Комментировать
SLIDERWEB
@SLIDERWEB
ИТ-Куроводитель
Если с BGP проблемы, то одно из решений, которое я использую и сейчас — это проксирование траффика.
1 — Покупаем VPS, поднимаем на нем nginx/vpn (в зависимости от того, что хотим резервировать), правим DNS — проффит.
2 — Есть вариант воспользоваться уже готовыми облачными решениями, типа CloudFlare.
3 — Договариваемся с провайдерами о том, чтобы они разрешил пересылку и маршрутизацию пакетов не из своего пула. Включаем на DNS RR — готово. Два раза проделывал такой трюк — до сих пор работает. Предварительно договариваемся с провами о том, какие префиксы кому разрешить, настраиваем оборудование — и вуаля! Не красиво конечно, но основам построения сетей не противоречит, при должном подходе к реализации. Другое дело, что провайдеры могут не согласиться из за усложнения топологии.
Ответ написан
merlin-vrn
@merlin-vrn
Вешаете DNS на хостинге, который выживает всегда. Ну или покупаете slave-сервис, а мастера держите у себя и направляете slave на обновления с него.

Делаете для этих сервисов динамически обновляемую зону, и соответствующие A-записи с таймаутом — 5 минут. В выключенном состоянии записей не будет. При поднятии канала в зону добавляется A-запись с его адресом, при падении — запись удаляется. При работе обоих провайдеров у вас будет даже некоторое распределние нагрузки по каналам, т.к. активных записей будет две.
Ответ написан
Комментировать
@rapidspacerocket Автор вопроса
DDNS и подобные решения мне не нравятся тем, что нужен клиент, который будет выполнять обновление записей. Ну и множество прочих недостатков.

Есть более интересное решение на основе ДНС. Разворачиваем внутри организации два NS-сервера для нашей зоны, каждый NS доступен только через свой канал и не доступен через другой. NS имеют разные А-записи для одной зоны, которые для одних и тех же хостов выдают разные ip-адреса в зависимости от канала, на котором висит конкретный NS. TTL для зоны 5 минут. При вырубке одного из каналов через 5 минут происходит очистка кэша и зона скачивается с выжившего NS, который сообщает актуальные IP на работающем канале.

Теперь вопрос — какое минимальное значение у TTL для зоны? Выставить можно любое, но провайдеры скорее всего будут игнорировать слишком низкое значение. Могут быть какие-то ещё проблемы у данной схемы?
Ответ написан
@rapidspacerocket Автор вопроса
Вчера выставил для зоны TTL равным 5 минут, ДНС google обновляет IP-адреса примерно через час.
Ответ написан
merlin-vrn
@merlin-vrn
Два представления через разные каналы — с точки зрения внешних наблюдателей, это два разных DNS-сервера, которые отдают две разных версии зоны. Со всеми вытекающими проблемами вида «версии зоны, которые отдают разные DNS-серверы, различаются». Не стоит так делать.

Да и вообще это очень наворочено. Кроме того, если уж у вас есть где бинд поставить, значит есть и откуда запускать nsupdate. А решение вида «повесить на хостинге пингер, который удалит ненужную запись, если пинг через этот канал лёг» — заметно проще. Кроме того, оно внешнее, т.е. моделирует настоящего внешнего клиента, поскольку находится снаружи, пропадание доступа через тот или иной канал у него будет настоящее, а не «по мнению циски».
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы