Да, спасибо, менял ключи реестра, не помогает, ESP трафик не инкапсулируется в UDP. На линуксе или Cisco всё ок, ESP ложится в UDP и проходит через NAT.
Не, я хочу сделать так, чтобы представление менялось только в случае, когда падает один из линков. Т.е. оба ns в один момент времени будут отдавать одну и ту же зону. Упал линк — оба NS поменяли представление. А про упавший линк им сообщит циска, которая будет менять маршрут и запросы будут приходить с другого интерфейса. Хотя, честно говоря, я не очень понимаю, чем плохо отдавать на разных каналах разные представления, если в зонах будет отличаться только пара А-записей. Насколько я понимаю, внешние ДНС берут данные зоны с первого рабочего NS и даже не заметят, что в представлениях есть какие-то отличия.
Спасибо за многочисленные советы! У меня есть ещё одна идея. Схема очень простая. Есть BIND, настроенный на работу с представлениями — view. Создаём два альтернативных представления. Выбор представления BIND происходит на основе адреса клиента. Значит, нам надо в зависимости от канала менять адрес клиента, который увидит BIND. Для этого, во-первых, BINDу врубаем два интерфейса. Во-вторых, на кошке поднимаем кэширующий DNS. Пускаем все внешние запросы для нашей зоны через cisco Кэширующий сервер нужен, чтобы кошка меняла клиентский адрес DNS-запросов и ставила свои адреса. На cisco есть два статических маршрута /32 до Bind-сервера. К маршрутам привязаны track object, в зависимости от их состояния работает либо один, либо второй статический маршрут. При падении канала отваливается статический маршрут, DNS-запросы начинают идти по другому статическому маршруту, соотвественно меняется клиентский адрес DNS-запроса и Bind подставляет другое представление. Узкое и непонятно место в данной схеме — снаружи NS-сервера не будут доступны напрямую, а только через кэширующий DNS, насколько это корректно — непонятно. Вместо кэширующего DNS можно сделать NAT в обратную сторону, т.е. чтобы менялся source ip-address. Как, пока не знаю. Но это лучше, т.к. NS-сервера будут доступны снаружи напрямую.
Да, Вы правды, установил TTL для отдельной записи и всё заработало, добился 5-минутного обновления. Только теперь с другим проблема — cisco 3750x не поддерживает технологию ddns.
А с почтой никакого веселья и не предвидится, если использовать MX-записи. Мне failover нужно реализовать только для Web. В любом случае по результатам моего эксперимента ДНС пока не получается разогнать быстрее, чем одно обновление в час, а это печально.
BGP только в крайнем случае, если не будет других вариантов. Если BGP, то в лёгком варианте, т.е. маршруты по умолчанию, т.е. мощщей особо и не надо. Из оборудования, сейчас есть одна 3750X IPBase, которая терминирует оптику между с этажами + intervlan routing + фильтры. Ну, наверное было бы очень красиво докупить ещё одну и собрать стек. Не только ради BGP, сейчас если 3750 выйдет из строя, происходит переключение по STP на витую пару + заводится старенький роутер для intervlan-роутинга. Как то так дела обстоят.
Нужно обновлять несколько хостов, как это сделать в Циско мне пока не понятно, если подскажете, буду рад. Т.е. нужно сделать обновление списка хостов, адреса которых подставляются в зависимости от состояния канала.
Наши провайдеры категорически не хотят публиковать чужие подсети в своих AS, уже общался на этот счёт. Дело не только в усложнении топологии, но и в том, что им придётся с вышестоящими дополнительно договариваться. Если говорить о BGP, то нужно покупать оборудование, сейчас есть только одна железка с BGP, естественно такой вариант не подходит, в случае смерти железки контора встанет. А если PBR использовать, то уже ничего покупать сверх того что есть не надо. С VPS это конечно интересный вариант. Т.е. я правильно понимаю, есть VPS для внешних пользователей, а он уже в свою очередь реагирует на изменение IP-адресов наших сервисов, перенаправляя трафик в нужную сторону?
На железе проверить не могу, это лаба для GNS3. Кофигурация оч простая, есть три роутера соединённые по схеме R1-R2-R3, интерфейсы — fa. Конфиг R1, остальные роутеры настроены так же:
ip multicast-routing
int fa 0/0
ip add 192.168.12.1
ip pim sparse-mode
ip pim send-rp-announce fa 0/0 scope 50
ip pim send-rp-discovery fa 0/0 scope 50
ip ospf 1 area 0
Далее на R2 и на R3 вывод команды sh ip pim rp mapping:
Group(s) 224.0.0.0/4
RP 192.168.12.1 (?), v2v1
Info source: 192.168.12.1 (?), elected via Auto-RP
Uptime: 02:13:54, expires: 00:02:14
Вывод sh ip mroute, что интересно, прошу обратить внимание на флаг D и на значение RP:
(*, 224.0.1.39), 02:17:28/00:01:44, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 02:17:28/00:00:00