Один из заказчиков попросил сделать так, чтобы связь между его офисом и складом была постоянной и безопасной. Как мы это делали и что получилось, а что нет.

Условия

У Заказчика два помещения. Офис и склад. В офисе и на складе есть 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

Впоследствии, Вы можете составить такой список для себя и затем, используя замену получить ту конфигурацию, которая Вам нужна.

Разобьём задачу на две

1. Отказоустойчивость выхода в Интернет через двух провайдеров.
2. Организация 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-адрес резервного канала.