Как правильно настроить VRRP?

Question

[osada]

Коллеги, просьба помочь конкретными советами по следующим моментам.

В работе находится один Mikrotik RB1100AHx4. На нем настроены стандартные вещи:

1) VLAN-ы с несколькими подсетями;
2) L2TP/IPSec Server;
3) Firewall rules с разными запретами и разрешениями по сетям и хостам;
4) метки Mangle;
5) Src NAT и Dst NAT;

На ether1 подключены два белых ip (например, 1.2.3.4 и 5.6.7.8) от одного определённого провайдера одним патч-кордом. На первом IP (например, 1.2.3.4) висят всякие правила Firewall и на нем же настроен L2TP/IPSec Server. На втором IP (например, 5.6.7.8) настроены SRS NAT и DST NAT для публикации определенного WEB-приложения, а также правила Firewall.
Есть также в запасе бездействующий третий белый IP (например, 9.10.11.12). Соот-но, ничего на нем не настроено.

В принципе все работает нормально.
В планах приобрести два Mikrotik RB1100AHx4 Dude Edition и установить там VRRP с целью отказоустойчивости с дальнейшей замены текущего Mikrotik RB1100AHx4.

Отсюда вопросы:

1) Планирую сделать экспорт всех настроек с текущего Mikrotik RB1100AHx4 и сделать импорт в каждый из Dude Edition. Т.к. железо практически одинаковое, то думаю, что импорт настроек пройдет нормально. Или все-таки нужно обратить внимание на какие-то моменты? Если будут какие-то проблемы, то могу настроить оба Dude вручную.

2) Насколько я понял, для нормальной работы VRRP необходимо наличия отдельного Интернет-линка на каждый Dude. В таком случае мне нужно будет договориться с провайдером для организации второго физического линка для второго Dude и назначить ему IP-адрес 9.10.11.12. При этом, как я понял, что на каждом из двух Микротиках Dude нужно настроить VLAN-ы не на физическим LAN Ethernet-порте, а на интерфейсе VRRP? Интерфейс VRRP будет иметь отличную от локальной IP-подсеть для обработки служебного трафика между двумя Dude.

3) Как правильно настроить в таком случае L2TP/IPsec Server на каждом Микротике? В качестве L2TP клиента выступают также Микротики, расположенные в других местах и имеют также свои белые IP-адреса.

Является ли рабочим вариантом настроить на каждом Dude свой отдельный L2TP/IPsec Server? На первом Dude это будет L2TP/IPsec Server с IP 1.2.3.4, на втором Dude это будет 9.10.11.12. Далее, на каждом клиентском Микротике настроить по два L2tp конекта (назовем их L2TP-out1, который будет смотреть на 1.2.3.4 и L2TP-out2, который будет смотреть на 9.10.11.12). В один момент времени на каждом клиентском Микротике будет работать только один коннект, допустим, только L2TP-out1 и при обрыве связи с ним будет задействован L2TP-out2 коннект. Для этого нужно будет написать скрипт, который будет мониторить статус работы коннектов L2TP-out1 и L2TP-out2.
Непонятно как избежать в таких случаях потери данных (различные транзакции при передаче данных от приложения и др.) при обрыве L2TP/IPSec коннекта.

Или в корне этот подход неправильный?

4) Что касается IP 5.6.7.8, на котором висит WEB-приложение, то как его правильно настроить при переходе на VRRP? Чтобы приложение также было доступны внешним клиентам с этим же IP 5.6.7.8, даже при переключении с одного Dude на второй в случае сбоя.

Answer 1

[Дмитрий Александров]

1) не стоит, лучше руками заново все сделайте. Велика вероятность что утащите mac адреса, потеряется пароль чегото. Не стоит в общем
2) Кажется вы немного путаете то для чего предназначен VRRP. Если упростить то им вы можете сделать "шлюз по умолчанию" для клиентов локалки, но не внешки со стороны провайдера. Т.е. к примеру:
Роутер "А" в локалке имеет ip 10.10.10.10
Роутер "Б" в локалке имеет ip 10.10.10.11
VRRP между ними и "шлюз по умолчанию 0.0.0.0" для клиентов локалки будет 10.10.10.1, это адрес будет перетекать между "А" и "Б", та самая отказоустойчивость.
Со стороны провайдера фиолетово что у вас там, назначайте на "А" ip 1.2.3.4 , а на "Б" ip 5.6.7.8
3) Смотри пункт 2. Со стороны wan у тебя будет 2 разных ip без всяких VRRP. Настраивай на каждом тике свой l2tp\ipsec. Дальше можешь пытаться делать разную адресацию и поднимать одновременно оба линка, либо одну адресацию и в DNS делать 2 "А" записи , с клиентов цепляться по домену. Можно и другие варианты пробовать. Я бы сделал 2 линка и протолкал ospf.
4) Смотри пункт 2, у тебя нет vrrp для внешки. В лучшем случае можешь сделать в DNS "А" по записи на адреса 1.2.3.4 и 5.6.7.8. Тогда в случае отказа одной железки клиенты 50\50 будут пролазить через другую.

Можно сделать огород для WAN, некое подобие vrrp. Грубо говоря на роутере "А" висят оба внешних ip, в роутере "Б" скрипт который через локалку пингует роутер "А", если пинги прекратились то скриптом дернуть интерфейс провайдера и назначить себе адреса, если пинг вернулся(роутер А ожил) то отключить интерфейс.

В общем VRRP это для внутренности твоей локалки но не внешки.

Comments

[Strabbo]

Кажется вы немного путаете то для чего предназначен VRRP. Если упростить то им вы можете сделать "шлюз по умолчанию" для клиентов локалки, но не внешки со стороны провайдера

Это устаревшее понимание. протокол используется для увеличения доступности роутеров/ресурсов за роутерами. Никто не машает настроить его внутри сети и снаружи. Для второго варианта нужно 2 линка от одного провайдера и соответствующая IP сеть.

[osada]

Strabbo, да, так и есть, согласен полностью. VRRP можно использовать не только для отказоустойчивости на уровне LAN, но и на уровне WAN.

[Дмитрий Александров]

Strabbo, а потом прилетают неизбежные проблемы, что то не работает, почему то оба захотели быть master, что то провайдер забанил\зарезал трафик. Не для этой задачи vrrp сделан, а то что можно так сделать не говорит о том что так надо делать.
Тут автору достаточно будет банально DNS записями раскидывать трафик для входящих веб приложений.

[Strabbo]

Дмитрий Александров, Провайдер может забанить/зарезать любой трафик. VRRP тут не причем :) проблемы бывают с любыми протоколами, они диагностируются и потом решаются. По вашей же логике DNS сделан только для одной цели- это пребразовывать адреса, а не раскидывать трафик для входящих приложений.
Я бы вообще сделал всё про другому, это всё есть в интернете. Ну захотел автор делать вррп, пусть делает от этого никто и ничто не пострадает :) даже не надо будет играть с днс записями. Если он хочет нормальной топологии, то пусть наймет кого-то или сам учит сети и сетевые технологии, но тогда он потратит не пару дней, а от пару месяцев до пару лет.

[Дмитрий Александров]

Strabbo, не могу ручаться за всех провайдеров но с какими сталкивался всегда одно, ой как они не любят любой трафик когда что то захотело мультикаст или похимичть с mac адресами. Плюс надо чтобы вообще впринципе трафик l2 был разрешен. Опять же, на моей практике на любой лишний чих в сети прова следует бан порта откуда лезло. Причем зачастую все это по дефолту сделано и они врядли будут что то менять в конфигах ради клиента небольшого.
В случае с крупными клиентами, тут да, могут уже изворачиваться и делать любые прихоти.

[osada]

Strabbo, я возможно не полностью расписал, что мне нужно в конечном итоге. Хотя кажется расписал все по пунктам. В конечном итоге хочу настроить VRRP, но в текущем конфиге на единственном Микротике есть нюансы касательно l2TP сервера и Web-приложения. Ранее VRRP я настраивал, но там была проще конфигурация ))).

Нанимать никого не буду, сам разберусь. Вообще-то на этом ресурсе поэтому я и спрашиваю, чтобы получить ответы на вопросы, т.е. получить рекомендации от других.

Answer 2

[osada]

Дмитрий Александров
1) Понятно, спасибо.

2) " Кажется вы немного путаете то для чего предназначен VRRP." - ключевой момент тут то, что у меня в наличии только один WAN-коннект на сегодня. Соо-но, при настройке двух Микротиков, на каждый из них должен подаваться отдельный WAN-коннект. Про схему работы VRRP в локалке я знаю.

3) Как я понял, мой предложенный выше вариант имеет смысл? Т.е., я поднимаю на каждом Микротике отдельный L2TP/IPSec сервер, на каждом клиентском Микротике поднимаю два L2TP/IPSec и через скрипт мониторю их состояние.

4) "Чтобы приложение также было доступны внешним клиентам с этим же IP 5.6.7.8, даже при переключении с одного Dude на второй в случае сбоя." - если не придерживаться жестко этого ограничения, то можно сделать следующее.
WEB-приложение опубликовано по DNS-имени, конечно, и резолвится на 5.6.7.8 Как еще один вариант, можно в записи А в DNS указать дополнительно на IP второго Микротика, т.е. 9.10.11.12. Соот-но, на втором Микротике тоже сделать правила NAT для этого приложения.

Этот вариант тоже рабочий?