Резервный канал через PBR. Как быть с публикуемыми сервисами?
Есть задача подключить в конторе резервный ISP, внутри компании есть несколько сервисов, которыми пользуются удалённые сотрудники — Web, VPN, SMTP. Основная проблема — как быть с публикуемыми сервисами, чтобы при отвале одного из провайдера наши сервисы продолжали быть доступными для удалённых сотрудников. Самый очевидный способ — это развернуть BGP, купить номер AS и провайдеро-независимые адреса. Тогда на публикуемых сервисах адреса не будут меняться, если какой-то канал падает. Второй способ, который в наших условиях проще развернуть, соответственно он и более предпочтителен — организация переключения на резервный канал с помощью политик PBR и IPSLA. Но в этом случае при отказе основного канала на публикуемых серверах будет меняться IP-адрес. Как сделать так, чтобы при смене IP-адреса сервис оставался доступным, пусть даже с разрывом сессии? Ну с почтой понятно, создаём несколько MX записей. Cisco Easy VPN тоже вроде не сложно в этом плане настроить — указываем backup-серверы. А вот как быть с Web? поможет ли тут DNS round robin? Или проще всё таки развернуть BGP?
Ну, если вас не пугает стоимость решения с BGP, то в любом случае это из пушки по воробьям (хотя, возможно, я недооцениваю размеры вашей организации). В общем же случае для веба, с которым работают сотрудники, разве недостаточно будет простого DDNS?
Если с BGP проблемы, то одно из решений, которое я использую и сейчас — это проксирование траффика.
1 — Покупаем VPS, поднимаем на нем nginx/vpn (в зависимости от того, что хотим резервировать), правим DNS — проффит.
2 — Есть вариант воспользоваться уже готовыми облачными решениями, типа CloudFlare.
3 — Договариваемся с провайдерами о том, чтобы они разрешил пересылку и маршрутизацию пакетов не из своего пула. Включаем на DNS RR — готово. Два раза проделывал такой трюк — до сих пор работает. Предварительно договариваемся с провами о том, какие префиксы кому разрешить, настраиваем оборудование — и вуаля! Не красиво конечно, но основам построения сетей не противоречит, при должном подходе к реализации. Другое дело, что провайдеры могут не согласиться из за усложнения топологии.
Наши провайдеры категорически не хотят публиковать чужие подсети в своих AS, уже общался на этот счёт. Дело не только в усложнении топологии, но и в том, что им придётся с вышестоящими дополнительно договариваться. Если говорить о BGP, то нужно покупать оборудование, сейчас есть только одна железка с BGP, естественно такой вариант не подходит, в случае смерти железки контора встанет. А если PBR использовать, то уже ничего покупать сверх того что есть не надо. С VPS это конечно интересный вариант. Т.е. я правильно понимаю, есть VPS для внешних пользователей, а он уже в свою очередь реагирует на изменение IP-адресов наших сервисов, перенаправляя трафик в нужную сторону?
Да, rapidspacerocket, Вы все правильно понимаете.
По поводу BGP и железок… Ну, BGP не обязательно держать на кошках. Можно использовать Quagga например.
Если говорить о BGP, то нужно покупать оборудование, сейчас есть только одна железка с BGP, естественно такой вариант не подходит
Простите, если нарушаю Ваш «фэн-шуй», но я хочу понять — что за оборудование Вы хотите для BGP? Два сервера c Quagga — довольно бюджетно. А если на *BSD — то еще и CARP (аналог HSRP) бесплатно получите.
BGP только в крайнем случае, если не будет других вариантов. Если BGP, то в лёгком варианте, т.е. маршруты по умолчанию, т.е. мощщей особо и не надо. Из оборудования, сейчас есть одна 3750X IPBase, которая терминирует оптику между с этажами + intervlan routing + фильтры. Ну, наверное было бы очень красиво докупить ещё одну и собрать стек. Не только ради BGP, сейчас если 3750 выйдет из строя, происходит переключение по STP на витую пару + заводится старенький роутер для intervlan-роутинга. Как то так дела обстоят.
Вешаете DNS на хостинге, который выживает всегда. Ну или покупаете slave-сервис, а мастера держите у себя и направляете slave на обновления с него.
Делаете для этих сервисов динамически обновляемую зону, и соответствующие A-записи с таймаутом — 5 минут. В выключенном состоянии записей не будет. При поднятии канала в зону добавляется A-запись с его адресом, при падении — запись удаляется. При работе обоих провайдеров у вас будет даже некоторое распределние нагрузки по каналам, т.к. активных записей будет две.
DDNS и подобные решения мне не нравятся тем, что нужен клиент, который будет выполнять обновление записей. Ну и множество прочих недостатков.
Есть более интересное решение на основе ДНС. Разворачиваем внутри организации два NS-сервера для нашей зоны, каждый NS доступен только через свой канал и не доступен через другой. NS имеют разные А-записи для одной зоны, которые для одних и тех же хостов выдают разные ip-адреса в зависимости от канала, на котором висит конкретный NS. TTL для зоны 5 минут. При вырубке одного из каналов через 5 минут происходит очистка кэша и зона скачивается с выжившего NS, который сообщает актуальные IP на работающем канале.
Теперь вопрос — какое минимальное значение у TTL для зоны? Выставить можно любое, но провайдеры скорее всего будут игнорировать слишком низкое значение. Могут быть какие-то ещё проблемы у данной схемы?
Вообще-то, все NS должны отдавать одно и то же. Это нарушение правил побольше недостаток, чем требование наличия клиента обновления (кстати, что, в циске нет nsupdate? фу). А по поводу «множества других недостатков DDNS» — поделитесь ими, пожалуйста.
Кстати, есть промышленные системы распределения нагрузки на базе DDNS, которые не то, что выставляют маленький TTL — они выставляют 0, и вроде бы как работает.
Нужно обновлять несколько хостов, как это сделать в Циско мне пока не понятно, если подскажете, буду рад. Т.е. нужно сделать обновление списка хостов, адреса которых подставляются в зависимости от состояния канала.
Так напишите простейший скрипт для мониторинга состояния канала, повесьте его на один из ваших серверов и обновляйте с его помощью. Это гораздо проще, быстрее и значительно дешевле, чем BGP поднимать. Причем под стоимостью BGP я подразумеваю совсем не покупку дополнительного оборудования.
Я к сожалению не в курсе, а как в циске обновить ОДИН хост?
И второй вопрос, поддерживает ли ваша циска команду tclsh в командном режиме (TCL shell)? А то я такой скрипт на тикле писал, правда, как обёртку для isc nsupdate, ну да адаптировать для циски можно.
У решения с DDNS есть один большой недостаток — многие провайдеры, как это не прискорбно, особенно в частном секторе, зачастую принудительно кэшируют DNS ответы на время, значительно превышающее TTL, нагло нарушая стандарты. А на претензии отвечают нечно в духе — «Обеспечивайте отказоустойчивость сервиса, а коли такой нищеброд — то и не суйся со своими сайтами».
Лично сталкивался с этим. И что самое отвратительное — большая часть трафика теряется именно по этой причине. тут уже невольно задумываешься о решениях более фундаментальных, чем DNS.
Есть более интересное решение на основе ДНС. Разворачиваем внутри организации два NS-сервера для нашей зоны, каждый NS доступен только через свой канал и не доступен через другой. NS имеют разные А-записи для одной зоны, которые для одних и тех же хостов выдают разные ip-адреса в зависимости от канала, на котором висит конкретный NS.
Это делается через view и одним сервером. А вот с делегированием намаетесь, так как файлы зон должны быть всегда одинаковыми (версии, хост, TTL-ы и т.д.). Болшее веселье Вас ждет с почтой. При RR у вас всегда будет меняться ответ и вы будете попадать сначала в GL а потом в BL, а некоторые, типа Google или Mail.ru могут и забанить напроч… так что я бы подумал хорошенько.
В любом случае, если Вы хотите управлять входящим траффиком — либо делать балансер на резервированном оборудовании, либо БГП — иначе никак.
А с почтой никакого веселья и не предвидится, если использовать MX-записи. Мне failover нужно реализовать только для Web. В любом случае по результатам моего эксперимента ДНС пока не получается разогнать быстрее, чем одно обновление в час, а это печально.
У решения с DDNS есть один большой недостаток — многие провайдеры, как это не прискорбно, особенно в частном секторе, зачастую принудительно кэшируют DNS ответы на время, значительно превышающее TTL, нагло нарушая стандарты. А на претензии отвечают нечно в духе — «Обеспечивайте отказоустойчивость сервиса, а коли такой нищеброд — то и не суйся со своими сайтами».
Покажите хоть одного такого провайдера. Года четыре уже крутится самодельный динамический DNS — ни разу не было таких проблем.
Попробуйте ради интереса специальные сервисы типа DynDNS — с ними дела могут обстоять по другому.
А вообще, еще раз повторюсь, всё-таки это очень дорого, мне кажется, поднимать BGP, причем основные материальные и административные затраты могут оказаться даже не в оборудовании, а в поиске и покупке провайдеронезависимых адресов и номера AS.
В случае, если всё плохо с DDNS и нет других задач, которые требуют автономной маршрутизации, присоединюсь к совету с внешним VPS + прокси.
Какие-то вы страшилки рассказываете, а сервис, бэк-энд которого писал я, о таких проблемах ни разу не слышал. Никаких проблем с неправильным слишком долгим кэшированием не наблюдали ни разу.
Там собственно класс на php, который дёргает nsupdate, и ещё один, который уже взаимодействует с БД и для обновления DNS дёргает первый класс.
Ещё пару раз использовал решение без этого веб-апдейтера, просто тупо ключи от зоны на клиенте и сам клиент уже nsupdate. Для таких случаев заводятся отдельные зоны. Опять же, оно прямо сейчас работает и проблем ни разу не наблюдал, вплоть до того, что после падения интернета там мы ждём десять минут (TTL), можно по часам засекать, а через десять минут кэши все истекли и мы подключаемся туда. (Сделано для обслуживания клиента, который не хочет приобретать статические IP-адреса.)
Вы не ставьте маленький TTL зоны! Вы меняйте только TTL отдельных записей, относящихся к проблеме.
Да, Вы правды, установил TTL для отдельной записи и всё заработало, добился 5-минутного обновления. Только теперь с другим проблема — cisco 3750x не поддерживает технологию ddns.
в принципе, всё равно реально, tcl там есть, но написать на нём nsupdate будет тяжеловато (придётся потрудиться и реализовать всё, в т. ч. TSIG-криптографию, причём DNS через tcp-сокеты, поскольку tcl в этом коммутаторе не имеет пакета udp)
а на unix-машине делается с помощью элементарного bash-скрипта.
кстати, в принципе вы можете реализовать хостинг, на котором будет веб-скрипт. А на циске tcl-скрипт будет только по HTTP (реализовать легко) просить хостинг обновить зону.
ну или ещё проще, повесить на хостинге пингер, который удалит ненужную запись, если пинг через этот канал лёг :) вот оно, простейшее решение
если что, подскажу, как
Спасибо за многочисленные советы! У меня есть ещё одна идея. Схема очень простая. Есть BIND, настроенный на работу с представлениями — view. Создаём два альтернативных представления. Выбор представления BIND происходит на основе адреса клиента. Значит, нам надо в зависимости от канала менять адрес клиента, который увидит BIND. Для этого, во-первых, BINDу врубаем два интерфейса. Во-вторых, на кошке поднимаем кэширующий DNS. Пускаем все внешние запросы для нашей зоны через cisco Кэширующий сервер нужен, чтобы кошка меняла клиентский адрес DNS-запросов и ставила свои адреса. На cisco есть два статических маршрута /32 до Bind-сервера. К маршрутам привязаны track object, в зависимости от их состояния работает либо один, либо второй статический маршрут. При падении канала отваливается статический маршрут, DNS-запросы начинают идти по другому статическому маршруту, соотвественно меняется клиентский адрес DNS-запроса и Bind подставляет другое представление. Узкое и непонятно место в данной схеме — снаружи NS-сервера не будут доступны напрямую, а только через кэширующий DNS, насколько это корректно — непонятно. Вместо кэширующего DNS можно сделать NAT в обратную сторону, т.е. чтобы менялся source ip-address. Как, пока не знаю. Но это лучше, т.к. NS-сервера будут доступны снаружи напрямую.
Два представления через разные каналы — с точки зрения внешних наблюдателей, это два разных DNS-сервера, которые отдают две разных версии зоны. Со всеми вытекающими проблемами вида «версии зоны, которые отдают разные DNS-серверы, различаются». Не стоит так делать.
Да и вообще это очень наворочено. Кроме того, если уж у вас есть где бинд поставить, значит есть и откуда запускать nsupdate. А решение вида «повесить на хостинге пингер, который удалит ненужную запись, если пинг через этот канал лёг» — заметно проще. Кроме того, оно внешнее, т.е. моделирует настоящего внешнего клиента, поскольку находится снаружи, пропадание доступа через тот или иной канал у него будет настоящее, а не «по мнению циски».
Не, я хочу сделать так, чтобы представление менялось только в случае, когда падает один из линков. Т.е. оба ns в один момент времени будут отдавать одну и ту же зону. Упал линк — оба NS поменяли представление. А про упавший линк им сообщит циска, которая будет менять маршрут и запросы будут приходить с другого интерфейса. Хотя, честно говоря, я не очень понимаю, чем плохо отдавать на разных каналах разные представления, если в зонах будет отличаться только пара А-записей. Насколько я понимаю, внешние ДНС берут данные зоны с первого рабочего NS и даже не заметят, что в представлениях есть какие-то отличия.
Простой
Простой
