В данной статье хочу поделиться с вами решением некоторых дополнительных задач, которые предстали передо мной во время реализации проекта. Среди таких задач была организация доступна к серверам в офисе для устройств сотрудников отдела ревизии, которые перемещаются из магазина в магазин (Часть 1). А так-же о том, как я ловил гуляющий по магазинам Wi-Fi принтер при помощи протокола динамической маршрутизации OSPF (Часть 2).
Как и прежде, надеюсь что данное решение поможет кому-то либо из новичков решить аналогичные задачи. Буду рад критике со стороны профессионалов.
Кого заинтересовал заголовок — прошу под кат!
Часть 0. Что дано
Позвольте немного вкратце напомнить о том, что было сделано в предыдущей статье. Ко мне обратилась организация – сеть торговых магазинов с просьбой организовать им сегментированную сеть с возможностью резервирования и ограниченным бюджетом.
Передо мной поставлена задача сделать из плоской территориально распределённой по городу сети: сегментированную сеть, с иерархической адресацией и главное с возможностью резервирования.
Связь между всеми магазинами по городу организовывает местный ISP, путем предоставления предприятию отдельного VLAN внутри своей сети. Таким образом, вся сеть во всех магазинах и в офисе находилась в одном большом Layer2 Broadcast-домене.
У такой модели есть ряд недостатков:
- Все устройства в сети могут видеть друг друга на Layer-2.
- Отсутствие каких-либо политик фильтрации трафика.
- Единый Broadcast домен, результатом которого является то, что любой широковещательный пакет от каждого из 400 устройств, обязательно будет передан всем этим 400 устройствам, расположенным в разных концах города.
Краткую, упрощенную схему расположения серверов приведу на рисунке 1 ниже:
И краткое описание того, что имеем:
- На предприятии имеются разные серверы выполняющие разные роли.
- Есть специальные терминалы сбора данных (ТСД), на рисунке я их назвал TABLETS.
- Есть стационарные ТСД привязанные к конкретному магазину и не покидающее его пределов. Они имеют IP-адреса из пула устройств в магазине.
- Есть ревизионные ТСД и отдельный сервер ревизии, с которым они взаимодействуют. Эти ТСД постоянно мигрируют из магазина в магазин где выполняют ревизию.
Часть 1. «Упс, а у нас тут ревизия»
После того как началось внедрение в сети маршрутизаторов Mikrotik, в первом из магазинов, в тот же день там проходит ревизия.
Организация работы отдела ревизии очень интересна и своеобразна. Во всех магазинах имеются Wi-Fi точки доступа с одинаковыми SSID и ключами шифрования. Таким образом, ревизионные ТСД имеют статический IP-адрес из своего отдельного пула (192.168.3.0/24).
Так как изначально сеть была плоской, то любой ревизионный ТСД попадая в любой из магазинов оказывался в единой плоской сети и без проблем подключался к серверу ревизии расположенном где угодно.
Сервер-ревизии представлял из себя RDP-сервер с особой базой данных. Которая перед ревизией синхронизировалась с основным сервером БД. Сервер ревизии также подгружал нужные для работы файлы с сервера-хранилища. Терминалы сбора данных (ТСД – Tablets), взаимодействовали в основном только с сервером ревизии. Однако, иногда, в крайних случаях, когда на сервере ревизии что-то шло не так, они взаимодействовали напрямую с RDP-сервером расположенном в офисе. Все остальные ТСД (находящиеся постоянно в магазинах и привязанные к ним) взаимодействовали только с основным RDP-сервером.
Итак, вроде-бы понятно и просто. Есть мобильная группа устройств, периодически гуляющая из магазина в магазин и выполняющая страшную для работников магазина вещь – ревизию.
Ей просто необходимо получать динамически IP из пула в магазине и подключаться к серверу ревизии находящемуся в офисе или в крайнем случае к основному RDP-серверу.
Однако, как мне рассказали местные системные администраторы, за долгие годы существования компании, во времена ревизий случались разные случаи. Одним из которых было – умышленное нарушение коммуникаций связи между магазином и главным офисом, для того, чтобы ревизия сорвалась.
Поэтому исторически сложилось так, что сервер ревизии путешествовал вмести с ТСД из офиса по магазинам. Обычно это происходило вечером на кануне дня ревизии. Администратор привозит в магазин сервер, подключает его в любой свободный порт на любом из коммутаторов в магазине (помним, что сеть плоская и все порты соединены единым L2-доменом). Ставит ТСД на зарядку и уезжает.
Далее, ночью по расписанию сервер ревизии подключается к другим серверам находящимся в основном офисе и выполняет разные синхронизации и репликации данных. Важно заметить, что инициатором подключения всегда является сервер ревизии.
Возвращаемся к внедрению распределенной сегментированной сети в первом магазине. Там будет установлен маршрутизатор, который разделит L2-сегмент от общего офиса, а также в случае чего обеспечит резервирование каналов связи провайдера.
Позвольте привести изображение из предыдущей статьи чтобы было понятно, что изменилось в магазине.
Из рисунка понятно, что установленный в магазине маршрутизатор лишает мобильности ревизионную группу устройств.
Позвольте напомнить, как выглядит адресация в магазинах после внедрения маршрутизаторов:
- 192.168.1.0/24 – сеть центрального офиса
- 192.168.2.0/24 – 192.168.13.0/24 локальные сети каждого из 12 магазинов
- 10.10.10.0/24 – сеть, приходящая в главный офис через основной Ethernet канал
- 10.10.20.0/24 – сеть, приходящая в главный офис через резервный канал (PON)
- 10.20.30.0/24 – сеть внутри VPN, для магазинов, цепляющихся через внешнюю сеть на IP от ISP-1
- 10.30.40.0/24 – сеть внутри VPN, для магазинов, цепляющихся через внешнюю сеть на IP от ISP-2
Теперь, по прибытию в конкретный магазин, сервер ревизии, как и прежде подключается к любому свободному порту в коммутаторе, ТСД подключается к Wi-Fi точке доступа. После чего, ТСД могут свободно общаться с сервером ревизии находящимся с ними территориально в одном магазине, однако они не могут подключится к основному RDP-серверу в офисе. А сам сервер ревизии находясь вне офиса, не может выполнить синхронизацию данных.
Так как, это был первый переводимый магазин, и вся сеть полностью не была переведена на новый режим работы. График работы команды ревизии уже расписан: сегодня они здесь, а завтра уже в другом магазине, а потом снова здесь и т.д.
Требуется срочное решение задачи по обеспечению связности ревизионной группы (диапазон IP-адресов которой статичен: 192.168.3.0/24)
Как уже писал выше, в данной схеме инициализатором синхронизации является сам сервер ревизии: он сам подключается к другим серверам и выполняет нужные ему задачи. Ревизионные ТСД, если необходимо, тоже являются инициализаторами RDP-сессии с основным RDP-сервером в офисе.
Моя задача обеспечить IP-связность мобильных устройств, находящихся в любом из магазинов с офисом. При этом адресация устройств остается неизменной. Варианта получения ими адресов по DHCP в конкретном из магазинов нет.
Поэтому, первое решение, которое пришло мне в голову как временное (и, похоже оставшееся там постоянным) это реализация NAT.
Я уточнил у системных администраторов, точно ли, никаким из устройств, кроме ТСД сотрудником отдела ревизии, нет необходимости подключаться к серверу ревизии? Ответом было нет. Правда, иногда необходимо удаленно подключаться программистам по RDP. Однако, они это могут делать, подключившись к какому ни будь из PC в магазине, и с него уже подключиться к серверу. Если, конечно, PC в магазине смогут видеть сервер.
Итак, приступим к выполнению поставленной задачи.
Первым делом, я прошу администраторов установить нас всех ревизионных ТСД и на сервере адрес основного шлюза: 192.168.3.2
На маршрутизаторе, расположенном в магазине, добавляем этот IP-адрес на интерфейсе смотрящем в сторону магазина:
[s@VERTOLET-GW] > ip address export
# jun/03/2016 21:22:19 by RouterOS 6.32.3
#
/ip address
add address=192.168.3.2/24 interface=bridge-VERTOLET network=192.168.3.0
Таким образом, данная сеть ревизии (192.168.3.0/24) будет добавлена абсолютно во все магазины, это позволит мобильной группе устройств при переезде между магазинами, без перенастройки параметров видеть роутер магазина, а значит знать где расположены устройства в офисе.
Но, если мы будем иметь 12 магазинов с одинаковыми адресами, откуда серверам в офисе знать куда отправлять пакеты?
Тут, нам на помощь приходит NAT, целью которого является изменить IP-адреса с которых обращается мобильная группа.
Для этого, я выясняю к каким конкретно серверам необходим доступ устройств мобильной группы и создаю для них отдельный address-list:
[s@VERTOLET-GW] > ip firewall address-list export
# jun/03/2016 21:32:00 by RouterOS 6.32.3
#
/ip firewall address-list
add address=192.168.1.2XX list=REVISION-Servers
add address=192.168.1.2XX list=REVISION-Servers
add address=192.168.1.2XX list=REVISION-Servers
Теперь, делаем правило для трансляции NAT, чтобы скрыть адреса источников обращения мобильной группы:
[s@VERTOLET-GW] > ip firewall nat export
# jun/03/2016 21:42:00 by RouterOS 6.32.3
/ip firewall nat
add action=masquerade chain=srcnat comment=FROM-REVISION dst-address-list=REVISION-Servers src-address=192.168.3.0/24
Данное правило NAT меняет адреса источников (192.168.3.0) на адреса роутера в транзитных сетях (10.0.0.0/8) при обращении к нужным серверам в офисе.
Итак, задача уже частично решена, т.к. мобильная группа может свободно приезжать в любой магазин, подключаться к сети, где ее уже ждет заранее готовый шлюз и инициализировать соединения с центральным офисом.
Напомню с этой задачей я столкнулся в первый день внедрения решения, и сеть в целом была не готова к изменениям, сложилась ситуация: когда сервера ничего еще не знали об адресации между магазинами. И шлюзом для них был Kerio сервер, на котором статически был прописан маршрут в сеть переводимого магазина на отдельный, скромно стоящий маршрутизатор Mikrotik в офисе.
Которому позже предстояло стать главным роутером.
Это означает, что в офисе нам потребовалось сделать еще одну NAT трансляцию чтобы скрыть от серверов ( к которым обращается мобильная группа) транзитные сети (10.0.0.0/8):
Аналогично, как в магазине добавляем адрес-лист
[s@MAIN-BORDER-ROUTER] > ip firewall address-list export
# jun/03/2016 21:52:12 by RouterOS 6.32.2
#
/ip firewall address-list
add address=192.168.1.2XX list=REVISION
add address=192.168.1.2XX list=REVISION
add address=192.168.1.2XX list=REVISION
А также правило трансляции:
[s@MAIN-BORDER-ROUTER] > ip firewall nat export
# jun/03/2016 21:52:12 by RouterOS 6.32.2
#
/ip firewall nat
add action=masquerade chain=srcnat comment=NAT-KOSTUL-REVISION dst-address-list=REVISION src-address=10.0.0.0/8
Как видите, так и пришлось по-честному подписать данное правило – костыль, ибо по-другому у меня назвать данное решение мыслей не пришло.
На данном этапе, задача по обеспечению связности мобильной группы устройств с серверами в офисе из любого магазина выполнена.
Удаленный доступ к серверу ревизии для программистов, при необходимости можно получить, подключившись на любой PC в магазине, который пойдет в сеть 192.168.3.0/24 через роутер магазина, знающий об этой сети, как о своей direct-connected сети.
Часть 2. Мой Wi-Fi принтер отказывается печатать ценники!
С момента внедрения сети в первый магазин и переводом на данную схему последнего магазина прошло около 3х недель. В это время всплывали мелкие недочеты, которые спешно исправлялись. В целом все жило хорошо, как и планировалось. Забавно, что после переключения первого магазина на новый режим работы, у ISP случилась авария оставившая именно этот магазин без связи и система отлично отработала переключение на резерв.
Когда происходило внедрение в последнем магазине, системные администраторы поведали мне с неуверенностью об еще одном нюансе, который руководство выставило как задачу необходимую к решению.
Оказывается, среди мобильной группы есть отдельный сотрудник, который также имеет ТСД из диапазона (192.168.3.0/24), с которым он ходит по разным магазинам, однако его задача заключается в переоценке товаров, срок годности которых подходит к концу.
Со своего ТСД он подключается к основному RDP серверу, расположенному в офисе и работает с базой данных. Сканирует товары и печатает новые ценники.
Все хорошо, сотрудник спокойно приходит в тот или иной магазин, цепляется к сети Wi-Fi как и раньше, без проблем подключается к RDP-серверу в офисе, делает что необходимо, запускает печать на принтер, но… Принтер, на котором выполняется печать ценников мобильный! Ранее имевший IP-адрес из диапазона 192.168.1.0/24 и при плоской сети с единым L2, оставался доступным находясь в любом из магазинов.
Также доставляло некоторые неудобство то, что при подключении из офиса к серверу ревизии, один из компьютеров в магазине где происходила ревизия был занят программистами из-за того, что сервер ревизии находился за NAT, и для доступа к нему требовалось занимать один из компов расположенных в магазине.
В общем, передо мной поставлена новая задача:
- Обеспечить возможность печати из офиса на мобильный принтер
- Обеспечить возможность подключения к серверу ревизии по RDP из офиса напрямую
Что-же, теперь нам от внедрения протокола динамической маршрутизации, от которого я решил уйти в первой части не отвертеться.
Welcome to OSPF!
Тут, правда пришлось опять-же сделать очередной костыль, так как, я писал в первой статье, что через сеть ISP-1 пакеты OSPF не проходили. Ни через multicast, ни через unicast, потому что CPE (xPON-терминалы фирмы Huawei) просто дропали протокол 89.
Поэтому, OSPF я решил внедрить на туннельных интерфейсах, которые предназначались прежде всего для резервирования.
OSPF в данной ситуации необходим для двух вещей:
- Динамически указывать роутеру в офисе где искать Wi-Fi принтер, для того чтобы передать на него небольшой файл для печати
- Динамически указывать роутеру в офисе где искать сервер ревизии, для того, чтобы передавать туда команды управления RDP (обратный трафик от сервера ревизии в офис будет идти как задумывалось в первой статье)
Выходит, нам нет никакой необходимости передавать по OSPF всю сеть мобильной группы (192.168.3.0/24), более того, мы не может этого делать, т.к. человек занимающийся переоценкой и группа ревизии зачастую находится в разных местах, а связность должна быть с севером и с Wi-Fi принтером одновременно.
Поэтому, я решил, что наиболее оптимальным решением данной задачи, будет передача more specific address /32 конкретно этих двух устройств – принтера и сервера.
Для этого нам потребуется следующие инструменты из богатого функционала OSPF:
- Point-to-Point network-type
- Redistribution static routes
- Filtering
В начале определимся с алгоритмом, как мы будем передавать информацию о Wi-Fi принтере и сервера от магазинов в офис.
Для этого необходимо, чтобы протокол OSPF знал о том, что к данному роутеру подключены эти сети и выполнял анонсирование этих маршрутов центральному роутеру.
Протокол OSPF анонсирует сети двумя способами:
- Анонсирование всех сетей, принадлежащих интерфейсу, на котором включен OSPF, если этот интерфейс не Passive
- Анонсирование сетей, через редистрибуцию других протоколов динамической маршрутизации, подключенных напрямую маршрутов, статических маршрутов
Итак, я решил поступить следующим образом:
- Запуск процесса OSPF во всех магазинах и центральном роутере
- Создание статических маршрутов /32, для сервера и принтера во всех магазинах
- Фильтрация ненужных статических маршрутов (а их много) при редистрибуции в OSPF
- Средствами NetWatch отслеживание реального наличия устройств в том или ином магазине и управления статическим маршрутом
Вроде бы все понятно, приступаем к реализации.
Запускаем OSPF процессы на маршрутизаторах в магазинах и в офисе.
Все магазины будут в одной default area 0.
Состояния соседства между роутерами OSPF будет происходить в туннельных интерфейсах, их у нас между каждым магазином и офисом – 2.
На маршрутизаторах Mikrotik стоимость point-to-point интерфейса по умолчанию равна – 10. Так как, между каждым магазином и офисом у нас 2 VPN канала, устанавливаем на 2-м канале стоимость 20.
[s@KREDO-MAIN-BORDER-ROUTER] > routing ospf export
# jun/03/2016 22:42:36 by RouterOS 6.32.2
#
/routing ospf instance
set [ find default=yes ] router-id=255.255.255.255
/routing ospf interface
add cost=20 interface=2.VERTOLET-VPN-RESERVE network-type=point-to-point
/routing ospf network
add area=backbone network=10.20.30.0/24
add area=backbone network=10.30.40.0/24
Аналогичные действия делаем на маршрутизаторах в магазинах плюс, указываем на необходимость редистрибуции статических маршрутов, я решил анонсировать их как Type-1:
[s@KREDO-VERTOLET-GW] > routing ospf export
# jun/03/2016 22:50:17 by RouterOS 6.32.3
#
/routing ospf instance
set [ find default=yes ] redistribute-static=as-type-1 router-id=192.168.15.2 in-filter=ospf-in out-filter=ospf-out
/routing ospf interface
add cost=20 interface=VPN-OFFICE-RESERVE network-type=point-to-point
add interface=VPN-OFFICE network-type=point-to-point
/routing ospf network
add area=backbone network=10.20.30.0/24
add area=backbone network=10.30.40.0/24
В приведенном конфиге приведены команды отвечающие за редистрибуцию статических маршрутов, как type-1, данный тип являеется более приоритетным нежели type-2, а также его метрика изменяется при анонсировании между маршрутизаторами. Также, я указал в настройках OSPF два фильтра: ospf-in и ospf-out, данные фильтры в Mikrotik играют аналогичную с Route-map роль в роутерах Cisco.
Предлагаю рассмотреть данные фильтры:
[s@VERTOLET-GW] routing filter export
# jun/03/2016 23:01:57 by RouterOS 6.32.3
#
/routing filter
add action=discard chain=ospf-in ospf-type=external-type-1
add action=discard chain=ospf-in ospf-type=intra-area
add action=accept chain=ospf-out prefix=192.168.3.3 protocol=static
add action=accept chain=ospf-out prefix=192.168.3.252 protocol=static
add action=discard chain=ospf-out protocol=static
Фильтр ospf-in фильтрует любые маршруты, которые могут прилететь по OSPF на роутер.
Фильтр ospf-out фильтрует все возможные маршруты, которые могут анонсироваться через редистрибуцию, за исключением more-specific /32 маршрутов для сервера и Wi-Fi принтера.
Теперь, остается добавить статические /32 маршруты для мобильных устройств, о расположении которых мы должны знать.
[s@VERTOLET-GW] > ip route export
# jun/03/2016 23:08:46 by RouterOS 6.32.3
#
/ip route
add comment=MOBILE-WiFi-PRINTER disabled=yes distance=1 dst-address=192.168.3.3/32 gateway=bridge-VERTOLET
add comment=Revision-SERVER disabled=yes distance=1 dst-address=192.168.3.252/32 gateway=bridge-VERTOLET
Обратите внимание, что данные статические маршруты я добавляю с параметром disabled=yes, то есть – эти маршруты будут выключенными, недоступными, а значит не попадут в анонсирование через OSPF.
Почему? Потому-что, если я добавлю активные маршруты сразу во всех магазинах, то на главном роутере они будут видны через все магазины, и мы вернемся на исходную. Когда нам не известно, где конкретно ловить Wi-Fi принтер, т.к. данные маршруты существуют во всех магазинах.
Поэтому статические маршруты выключены по умолчанию, и никто о них не говорит до тех пор, пока устройство реально не появится в конкретном магазине.
Понять это мы сможем по доступности устройства через ping, а поэтому создаем два правила NetWatch с простенькими скриптами:
[s@KREDO-VERTOLET-GW] >tool netwatch expoart
# jun/03/2016 23:15:59 by RouterOS 6.32.3
#
/tool netwatch
add down-script="/ip route set [find comment=\"MOBILE-WiFi-PRINTER\"] disable=yes" host=192.168.3.3 interval=10s timeout=2s up-script="/ip route set [find comment=\"MOBILE-WiFi-PRINTER\"] disable=no"
add down-script="/ip route set [find comment=\"Revision-SERVER\"] disable=yes" host=192.168.3.252 interval=10s timeout=2s up-script="/ip route set [find comment=\"Revision-SERVER\"] disable=no"
Данные правила играют очень простую роль, что кстати напоминает ip sla + track из мира Cisco.
Мы пингуем сервер и Wi-Fi принтер каждые 10 секунд с таймаутом в 2 секунды. Если ping успешен, включаем статический маршрут, который моментально благодаря редистрибуции переходит в OSPF и главный роутер в офисе узнает где находятся устройства.
Таким образом, Wi-Fi принтер теперь снова печатает, как и прежде, а программисты могут работать по RDP напрямую с сервером ревизии. Словно у нас сохранилась плоская сеть.
Статью написал спустя полгода, с момента окончательного запуска проекта в работу на полную. За эти полгода, все работает прекрасно и без сбоев. Wi-Fi принтер успешно ловится, аварии у ISP к сожалению случаются, но магазины больше этого не замечают.
Статья снова получилась большой, благодарю за внимание и терпение. Буду рад критике и замечаниям. Если есть вопросы задавайте с удовольствием отвечу.
Комментарии (1)