Условия
У Заказчика два помещения. Офис и склад. В офисе и на складе есть Microtik-и и по два провайдера. Сотрудники склада пользуются IP-телефонией и ресурсами офиса через защищённый туннель.
Задача
Необходимо организовать связь таким образом, чтобы выход из строя одного провайдера (с любой стороны) не приводило к тому, что пользователи Офиса останутся без выхода в Интернет, а удалённые пользователи Склада без внутренних ресурсов Офиса.
Решение
Для начала нарисуем схему и попробуем определить, что необходимо сделать. Примем, что основные каналы идут через провайдеров OfficeISP1 и SkladISP1, а резервные – через OfficeISP2 и SkladISP2. На картинке они изображены толстой линией.
Составим список параметров, описывающий нашу конфигурацию:
- Адресация сети офиса: 192.168.1.0/24
- Адрес внутреннего интерфейса маршрутизатора сети офиса: 192.168.1.254
- Адрес внешнего интерфейса маршрутизатора сети офиса в сети основного провайдера (OfficeISP1): OFF.XXX.XXX.LOC
- Шлюз основного провайдера в офисе (OfficeISP1): OFF.XXX.XXX.ISP
- Адрес внешнего интерфейса маршрутизатора сети офиса в сети резервного провайдера (OfficeISP2): OFF.YYY.YYY.LOC
- Шлюз резервного провайдера в офисе (OfficeISP1): OFF.YYY.YYY.ISP
- Адресация сети склада: 192.168.2.0/24
- Адрес внутреннего интерфейса маршрутизатора сети склада: 192.168.2.254
- Адрес внешнего интерфейса маршрутизатора сети склада в сети основного провайдера (SkladISP1): SKL.NNN.NNN.LOC
- Шлюз основного провайдера в офисе (SkladISP1): SKL.NNN.NNN.ISP
- Адрес внешнего интерфейса маршрутизатора сети офиса в сети резервного провайдера (SkladISP2): SKL.HHH.HHH.LOC
- Шлюз резервного провайдера в офисе (SkladISP1): SKL.HHH.HHH.ISP
- Наименование бриджей для организации локальных сетей в Офисе и Сладе: bridge-local
- Наименование бриджей для организации сетей основных провайдеров в Офисе и Сладе: bridge-isp1
- Наименование бриджей для организации сетей резервных провайдеров в Офисе и Сладе: bridge-isp2
Впоследствии, Вы можете составить такой список для себя и затем, используя замену получить ту конфигурацию, которая Вам нужна.
Разобьём задачу на две
- Отказоустойчивость выхода в Интернет через двух провайдеров.
- Организация VPN-каналов для связи между Офисом и Складом.
Отказоустойчивость выхода в Интернет
Первую задачу, сначала я попытался решить при помощи скрипта, который запускался каждые 3 минуты и проверяющего при помощи ping какой-либо из хостов в Интернете (живучесть которого не вызывает сомнений). Однако, при тестировании эта технология всё время давала сбой. Почему – непонятно. Тогда я воспользовался простой и, как оказалось, более эффективной техникой: организация резервного канала связи без скриптов. Получилось даже лучше. При недоступном основном канале практически мгновенно происходит переход на резервный канал.
Организация VPN-соединений
Для организации VPN-соединений решено использовать протокол IPSec и IPIP-туннели. Составим таблички для туннелей. С каждой стороны придётся описывать по 4 IPIP-туннеля, для того, чтобы описать все возможные комбинации соединений.
Для Офисного маршрутизатора
- Офис-Склад, связь через основных провайдеров: ipip-office-isp1-sklad-isp1
- Офис (резервный провайдер) – Склад (основной провайдер): ipip-office-isp2-sklad-isp1
- Офис (основной провайдер) – Склад (резервный провайдер): ipip-office-isp1-sklad-isp2
- Офис-Склад, связь через резервных провайдеров: ipip-office-isp2-sklad-isp2
- ipip-office-isp1-sklad-isp1 local address: OFF.XXX.XXX.LOC
- ipip-office-isp1-sklad-isp1 remote address: SKL.NNN.NNN.LOC
- ipip-office-isp2-sklad-isp1 local address: OFF.YYY.YYY.LOC
- ipip-office-isp2-sklad-isp1 remote address: SKL.NNN.NNN.LOC
- ipip-office-isp1-sklad-isp2 local address: OFF.XXX.XXX.LOC
- ipip-office-isp1-sklad-isp2 remote address: SKL.HHH.HHH.LOC
- ipip-office-isp2-sklad-isp2 local address: OFF.YYY.YYY.LOC
- ipip-office-isp2-sklad-isp2 remote address: SKL.HHH.HHH.LOC
Для маршрутизатора Склада
- Склад-Офис, связь через основных провайдеров: ipip-sklad-isp1-office-isp1
- Склад (резервный провайдер) – Офис (основной провайдер): ipip-sklad-isp2-office-isp1
- Склад (основной провайдер) – Офис (резервный провайдер): ipip-sklad-isp1-office-isp2
- Склад-Офис, связь через резервных провайдеров: ipip-sklad-isp2-office-isp2
- ipip-sklad-isp1-office-isp1 local address: SKL.NNN.NNN.LOC
- ipip-sklad-isp1-office-isp1 remote address: OFF.XXX.XXX.LOC
- ipip-sklad-isp2-office-isp1 local address: SKL.HHH.HHH.LOC
- ipip-sklad-isp2-office-isp1 remote address: OFF.XXX.XXX.LOC
- ipip-sklad-isp1-office-isp2 local address: SKL.NNN.NNN.LOC
- ipip-sklad-isp1-office-isp2 remote address: OFF.YYY.YYY.LOC
- ipip-sklad-isp2-office-isp2 local address: SKL.HHH.HHH.LOC
- ipip-sklad-isp2-office-isp2 remote address: OFF.YYY.YYY.LOC
Для обоих маршрутизаторов для всех IPIP-туннелей
- IPSec secret (для всех туннелей одинаковый) – проверьте версию прошивки для Микротика!: bgduikneb789o3krjhgt98728550 (или другой пароль)
- Keepalive – по-умолчанию (для всех туннелей одинаковый): 00:05:10 10
- DSCP: inherit
- Don’t Fragment: inherit
- Clamp TCP MSS: поставьте галочку
Создадим адреса для каждого из туннеля, для того, чтобы организовать маршрутизацию между Офисом и Складом:
- 172.16.1.1/30 — ipip-office-isp1-sklad-isp1
- 172.16.1.2/30 — ipip-sklad-isp1-office-isp1
- 172.16.1.5/30 — ipip-office-isp2-sklad-isp1
- 172.16.1.6/30 — ipip-sklad-isp1-office-isp2
- 172.16.1.9/30 — ipip-office-isp1-sklad-isp2
- 172.16.1.10/30 — ipip-sklad-isp2-office-isp1
- 172.16.1.13/30 — ipip-office-isp2-sklad-isp2
- 172.16.1.14/30 — ipip-sklad-isp2-office-isp2
Создадим маршруты. Заметим, как должны распределяться значения distance по маршрутам:
Для офиса
- add distance=1 dst-address=192.168.2.0/24 gateway=172.16.1.2
- add distance=5 dst-address=192.168.2.0/24 gateway=172.16.1.6
- add distance=10 dst-address=192.168.2.0/24 gateway=172.16.1.10
- add distance=15 dst-address=192.168.2.0/24 gateway=172.16.1.14
Для склада
- add distance=1 dst-address=192.168.1.0/24 gateway=172.16.1.1
- add distance=5 dst-address=192.168.1.0/24 gateway=172.16.1.5
- add distance=10 dst-address=192.168.1.0/24 gateway=172.16.1.9
- add distance=15 dst-address=192.168.1.0/24 gateway=172.16.1.13
Наивысший приоритет мы отдаём маршрутам через основных провайдеров, низший – через резервных. Промежуточные варианты (в принципе) одинаковы, но в данном случае отдаём больший приоритет каналу основного провайдера со стороны Офиса. Я указал последние октеты для IP-адресов туннелей для более лёгкого понимания:
Что получилось
При нормальной работе всех провайдеров используются основные каналы для организации IPSec VPN-соединений. При отказе одного из каналов происходит перестроение маршрутизации для связи пользователи-интернет и автоматически начинает использоваться соответствующий канал IPSec VPN. Таким образом даже при одновременном отключении по одному провайдеру с каждой стороны система будет работать.
Что не получилось
Не перенастраивали телефонное соединение с провайдером IP-телефонии. В результате, при переходе на резервный канал не происходит автоматической перерегистрации внешнего адреса для телефонной станции, но это оставили пока на недалёкое будущее. Ограничения накладываются самой телефонной станцией.
«Типсы и триксы»
Для работы сразу с двумя провайдерами не забудьте сделать для NAT-правила (для Офиса и Склада – одинаковые):
/ip firewall nat
add action=masquerade chain=srcnat out-interface=bridge-isp1
add action=masquerade chain=srcnat out-interface=bridge-isp2
Для того, чтобы пакеты ходили между Офисом и Складом без проблем отмените NAT между ними добавив в начало таблицы правило для Офиса:
/ip firewall nat
add chain=srcnat dst-address=192.168.1.0/24 src-address=192.168.2.0/24
И для Склада:
/ip firewall nat
add chain=srcnat dst-address=192.168.2.0/24 src-address=192.168.1.0/24
А для того, чтобы пользователи удалённого рабочего стола, которые работают в дороге или из дома могли всегда (при любом активном провайдере) использовать ресурсы офиса можно использовать технологию DynDNS. Это позволит при переключении на резервного провайдера не вспоминать внешний IP-адрес резервного канала.
Комментарии (31)
Tanner
09.09.2015 21:11+2bgduikneb789o3krjhgt98728550
Мне показалось, или действительно пахнет дымом?
fleaump
09.09.2015 23:37Чем netwatch не устраивает? им и переключать активный канал и в итоге не надо городить гору тоннелей с интерфейсами.
Плюс команду атске можно через fetch кинуть из netwatch, что активный канал сменился, хотя с тем же астериском правильней вписать домен в externhost и через DNS обновлять запись.
ps Астериск прекрасно живет внутри микротиков с поддержкой metarouter\kvm
Livitin
11.09.2015 08:09netwatch не заработал, вернее не так. Поработал и перестал. Почему — не стал разбираться.
achekalin
10.09.2015 10:26+1Открыл статью как раз чтобы узнать, на какой технологии VPN сделано здесь, и _почему_. Увы. Прочел:
> Организация VPN-соединений
>
> Для организации VPN-соединений решено использовать протокол IPSec и IPIP-туннели. Составим таблички для туннелей
Скажите, а почему IPSec, а не, скажем, ovpn или sstp? «С потолка», или «выстрадано»? В последнем случае расскажите, это, честное слово, будет куда интереснее очередного рассказа про «два впн-а на нос».Livitin
11.09.2015 08:11Потому, что в IPIP есть такая фича — IPSec пароль. Туннель сам генерит политику. Сделано просто для облегчения конфигурации. Напишите статью про ovpn или sstp — если будет проще, с удовольствием буду применять. :)
AcidVenom
11.09.2015 09:25Производительность. На 951 серии SSTP прокачивает только 10% канала, а OVPN не умеет UDP, что тоже не является плюсом.
ikormachev
10.09.2015 10:31+2Вам осталось улучшить ваше решение следующим образом:
1) Установить по два микротика на каждом объекте (ведь отказать может не только провайдер, но и маршрутизатор).
2) Настроить маршрутизацию между сетями через ospf.
3) Настроить шлюз в каждой сети через VRRP и сделать переключение VRRP через watchdog в случае падения канала Интернет на основном маршрутизаторе.ikormachev
10.09.2015 10:35+1И еще сменить адресацию в офисе со 192.168.1.0/24 на неиспользуемую домашними роутерами, а то через VPN домашние пользователи у вас работать могут через раз.
fleaump
10.09.2015 10:54У меня самого огород из кучи офисов с микротиками из младших и старших линеек.
1) Возможно в центральных офисах и имеет смысл vrrp и еще один CCR от микротика, но финансовая составляющая подсказывает что лучше держать просто одну железку в резерве, и в случае чего ее заменять накатив бекап конфига.
2) ospf это интересно конечно, но в двух офисах можно и руками прописать маршруты, плюс ospf при перестройке маршрутов негативно накладываться на проходящий внутри голосовой трафик, в отличии от маршрутов с метрикой.
3) пункт 1
ikormachev
10.09.2015 11:321) Возможно в центральных офисах и имеет смысл vrrp и еще один CCR от микротика, но финансовая составляющая подсказывает что лучше держать просто одну железку в резерве, и в случае чего ее заменять накатив бекап конфига.
Если вы купили второй канал Интернет, то по сравнению с ним стоимость микротика — копейки. Ну и держать роутер в резерве и в случае чего ехать на объект, чтобы его заменить, сводить на нет всю идею обеспечения отказоустойчивости.
2) ospf это интересно конечно, но в двух офисах можно и руками прописать маршруты, плюс ospf при перестройке маршрутов негативно накладываться на проходящий внутри голосовой трафик, в отличии от маршрутов с метрикой.
Как он негативно накладывается на голосовой трафик? Объясните механизм плз.fleaump
10.09.2015 13:321) два гигабитных канала по 15к, CCR микротик от штуки баксов, офисов овер дофига. Выгодней купить один запасной на несколько офисов и пусть валяется на складе. За все время работы только мерли обычные свитчи тупые.
2) При перестроении маршрутов происходит залипание на долю секунды, при разговоре это вываливается в проглатывании слов. UDP такой UDP.ikormachev
10.09.2015 13:55+11) два гигабитных канала по 15к, CCR микротик от штуки баксов, офисов овер дофига. Выгодней купить один запасной на несколько офисов и пусть валяется на складе. За все время работы только мерли обычные свитчи тупые.
Судя по всему, вы покупаете оборудование по принципу «чем дороже — тем лучше». Использовать CCR для подключения пары провайдеров и организации IPSec — огромная глупость. Денег много, а скорость VPN ниже.
Все остальные ваши познания в сетевых технологиях даже комментировать нет желания.fleaump
10.09.2015 14:40У меня не ipsec, и офисы не из разряда три бухгалтера и пять кладовщиков, а так же гигабитные каналы не для того чтобы сайтики быстрее грузились.
И у микротика нет среднего решения, либо слабое железо, либо 36 ядерный монстр. Единственно среднее, это собирать самому на x86 и туда вкатывать лицензию.
Зря вы чтото там про комментировать, в практике случалось что ложились все провайдеры в очень отдаленных офисах, изза того что все «оба» прова имеют общую будку коммутации до которой просто физически рвалась оптика. И тут никакой vrrp бы из двух роутеров бы не помог.
У автора же связка один склад и один офис, зачем там мудрить лишнего.ikormachev
10.09.2015 15:06У меня не ipsec, и офисы не из разряда три бухгалтера и пять кладовщиков, а так же гигабитные каналы не для того чтобы сайтики быстрее грузились.
У вас эксклюзивные гигабитные каналы. За 15 000 р./месяц на складе в среднем можно получить 5-10 Мбит скорости. Гигабит юрлицам в офисах за такие деньги никто не подключает, да и скорости такие не ИТ-компаниям не нужны.
Без шифрования гигабитную нагрузку выдерживает RB2011UiAS-IN (119$), с шифрованием AES он же тянет порядка 20-30 Мбит/с, чего хватает для подключения 4-5 офисов с 40-50 пользователями в них.
Когда штраф за задержку фуры на складе составляет тысячи рублей в час, купить второй маршрутизатор за 119$ не составляет проблем.
fleaump
10.09.2015 15:22Все можно, с руководством провайдеров дружить нужно, не все жадные и занудные.
По ночам сливать базы с бекапами, samba и прочее. 20-30 мегабит тут никак не зайдёт, плюс надо еще приоритеты при этом нормально отрабатывали. Так же по l2tp люди цепляются и комуто и скорости под rdp хватит, а какому нибудь 1cнику надо максимально возможную полосу, чтобы слить\залить конфу или базу.
Изначально делал маршрутизацию на ospf, но он передергивал маршруты постоянно как по таймауту причем на те же самые при нормально рабочих каналах, заметил это только из-за того что народ жаловаться начал что иногда телефоны лагают, т.к. кол-во офисов перестало расти, то через «ssh_all» нарисовал везде маршруты с метриками и убрал в дальний ящик эту проблему.
Livitin
11.09.2015 08:30Поддерживаю идею не ездить. Если критично — можно махонькую железку купить, сливать туда бэкап и ответственному работнику написать инструкцию. ;)
Livitin
11.09.2015 08:13Как вариант, но этот вариант был выбран как бюджетное решение. И к тому же очень простое. И к тому же работающее. Ваши варианты конечно же будут работать. Но в условиях Заказчика проводить доп.работы по ospf и т.д. просто не было денег и времени. ;)
karabanov
14.09.2015 11:35Вы можете пояснить как работает правило:
/ip firewall nat add chain=srcnat dst-address=192.168.1.0/24 src-address=192.168.2.0/24
Ведь нет же действия. Не понятно на что SNAT-ить. Как MikroTik действует в этой ситуации?fleaump
14.09.2015 13:41как и в iptables проходит соединение без маскарадинга и прочих подмен, прямое обращение между сетями
Livitin
15.09.2015 16:26Действия нет. NAT-ить не надо! Для перемещения пакетов в корпоративной среде NAT не нужен. Нужна простая маршрутизация.
karabanov
15.09.2015 22:18Ааааааа! NAT сработает раньше чем пакет завернётся в туннель!
То есть это аналог:
iptables -I POSTROUTING -t nat -d АДРЕС_УДАЛЕННОЙ_ПОДСЕТИ -j RETURNLivitin
16.09.2015 07:48Не знаю. iptables не использую. Пользовался ipfw. А при чём здесь аналог?
fleaump
16.09.2015 10:49Может потому что микротиковский фаервол на netfilter как и iptables
karabanov
16.09.2015 15:49Да. Только в MikroTik-е похоже не используется iptables, а используется какой-то свой способ взаимодействовать с netfilter.
Любопытно, что в MikroTik-е есть действие RETURN, но вы этот момент обходите с помощью вышеупомянутого:
/ip firewall nat add chain=srcnat dst-address=192.168.1.0/24 src-address=192.168.2.0/24
Это получается фича MikroTik-а.
maovrn
Один заказчик, два помещения, четыре провайдера и восемь связей
… и три копии статьи на хабре
Dm4k
Повторение — мать учения!
Livitin
не посмотрел. Наверное очень популярная тема. Только эту статью писал не по чужим. Вряд ли это копии…
maovrn
Первый комментарий запечатлел краткий миг истории, когда в результате технического сбоя статья была опубликована трижды. Конечно, сейчас дубли удалены. Никаких намеков на плагиат.
Livitin
Если не трудно — киньте ссылки. Сразу так и не нашёл.
Dm4k
maovrn, имел виду то что вы опубликовали эту статью три раза подряд. (судя по тому что счетчик публикаций в вашем профиле равен единице — дубли удалил модератор — а вы и не заметили как это произошло ;))