Как я ловил Wi-Fi принтер по OSPF, корпоративная сеть на MikroTik часть 2

в 23:06, , рубрики: mikrotik, nat, ospf, динамическая маршрутизация, костыли, Сетевые технологии, системное администрирование

Всем привет! Наконец я решил внести обещанное дополнение к статье: Резервирование внутренних и внешних каналов связи, статическая маршрутизация, корпоративная сеть на MikroTik.
В данной статье хочу поделиться с вами решением некоторых дополнительных задач, которые предстали передо мной во время реализации проекта. Среди таких задач была организация доступна к серверам в офисе для устройств сотрудников отдела ревизии, которые перемещаются из магазина в магазин (Часть 1). А так-же о том, как я ловил гуляющий по магазинам Wi-Fi принтер при помощи протокола динамической маршрутизации OSPF (Часть 2).
Как и прежде, надеюсь что данное решение поможет кому-то либо из новичков решить аналогичные задачи. Буду рад критике со стороны профессионалов.
image
Кого заинтересовал заголовок — прошу под кат!

Часть 0. Что дано

Позвольте немного вкратце напомнить о том, что было сделано в предыдущей статье. Ко мне обратилась организация – сеть торговых магазинов с просьбой организовать им сегментированную сеть с возможностью резервирования и ограниченным бюджетом.
Передо мной поставлена задача сделать из плоской территориально распределённой по городу сети: сегментированную сеть, с иерархической адресацией и главное с возможностью резервирования.
Связь между всеми магазинами по городу организовывает местный ISP, путем предоставления предприятию отдельного VLAN внутри своей сети. Таким образом, вся сеть во всех магазинах и в офисе находилась в одном большом Layer2 Broadcast-домене.

У такой модели есть ряд недостатков:

  1. Все устройства в сети могут видеть друг друга на Layer-2.
  2. Отсутствие каких-либо политик фильтрации трафика.
  3. Единый Broadcast домен, результатом которого является то, что любой широковещательный пакет от каждого из 400 устройств, обязательно будет передан всем этим 400 устройствам, расположенным в разных концах города.

Краткую, упрощенную схему расположения серверов приведу на рисунке 1 ниже:
Как я ловил Wi-Fi принтер по OSPF, корпоративная сеть на MikroTik часть 2 - 2
И краткое описание того, что имеем:

  1. На предприятии имеются разные серверы выполняющие разные роли.
  2. Есть специальные терминалы сбора данных (ТСД), на рисунке я их назвал TABLETS.
    • Есть стационарные ТСД привязанные к конкретному магазину и не покидающее его пределов. Они имеют IP-адреса из пула устройств в магазине.
    • Есть ревизионные ТСД и отдельный сервер ревизии, с которым они взаимодействуют. Эти ТСД постоянно мигрируют из магазина в магазин где выполняют ревизию.

Часть 1. «Упс, а у нас тут ревизия»

После того как началось внедрение в сети маршрутизаторов Mikrotik, в первом из магазинов, в тот же день там проходит ревизия.
Организация работы отдела ревизии очень интересна и своеобразна. Во всех магазинах имеются Wi-Fi точки доступа с одинаковыми SSID и ключами шифрования. Таким образом, ревизионные ТСД имеют статический IP-адрес из своего отдельного пула (192.168.3.0/24).
Так как изначально сеть была плоской, то любой ревизионный ТСД попадая в любой из магазинов оказывался в единой плоской сети и без проблем подключался к серверу ревизии расположенном где угодно.

Сервер-ревизии представлял из себя RDP-сервер с особой базой данных. Которая перед ревизией синхронизировалась с основным сервером БД. Сервер ревизии также подгружал нужные для работы файлы с сервера-хранилища. Терминалы сбора данных (ТСД – Tablets), взаимодействовали в основном только с сервером ревизии. Однако, иногда, в крайних случаях, когда на сервере ревизии что-то шло не так, они взаимодействовали напрямую с RDP-сервером расположенном в офисе. Все остальные ТСД (находящиеся постоянно в магазинах и привязанные к ним) взаимодействовали только с основным RDP-сервером.

Итак, вроде-бы понятно и просто. Есть мобильная группа устройств, периодически гуляющая из магазина в магазин и выполняющая страшную для работников магазина вещь – ревизию.
Ей просто необходимо получать динамически IP из пула в магазине и подключаться к серверу ревизии находящемуся в офисе или в крайнем случае к основному RDP-серверу.

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

Поэтому исторически сложилось так, что сервер ревизии путешествовал вмести с ТСД из офиса по магазинам. Обычно это происходило вечером на кануне дня ревизии. Администратор привозит в магазин сервер, подключает его в любой свободный порт на любом из коммутаторов в магазине (помним, что сеть плоская и все порты соединены единым L2-доменом). Ставит ТСД на зарядку и уезжает.

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

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

image

Из рисунка понятно, что установленный в магазине маршрутизатор лишает мобильности ревизионную группу устройств.
Позвольте напомнить, как выглядит адресация в магазинах после внедрения маршрутизаторов:

  1. 192.168.1.0/24 – сеть центрального офиса
  2. 192.168.2.0/24 – 192.168.13.0/24 локальные сети каждого из 12 магазинов
  3. 10.10.10.0/24 – сеть, приходящая в главный офис через основной Ethernet канал
  4. 10.10.20.0/24 – сеть, приходящая в главный офис через резервный канал (PON)
  5. 10.20.30.0/24 – сеть внутри VPN, для магазинов, цепляющихся через внешнюю сеть на IP от ISP-1
  6. 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-Server 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=for-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, и для доступа к нему требовалось занимать один из компов расположенных в магазине.

В общем, передо мной поставлена новая задача:

  1. Обеспечить возможность печати из офиса на мобильный принтер
  2. Обеспечить возможность подключения к серверу ревизии по RDP из офиса напрямую

Что-же, теперь нам от внедрения протокола динамической маршрутизации, от которого я решил уйти в первой части не отвертеться.

Welcome to OSPF!

Тут, правда пришлось опять-же сделать очередной костыль, так как, я писал в первой статье, что через сеть ISP-1 пакеты OSPF не проходили. Ни через multicast, ни через unicast, потому что CPE (xPON-терминалы фирмы Huawei) просто дропали протокол 89.

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

  1. Динамически указывать роутеру в офисе где искать Wi-Fi принтер, для того чтобы передать на него небольшой файл для печати
  2. Динамически указывать роутеру в офисе где искать сервер ревизии, для того, чтобы передавать туда команды управления RDP (обратный трафик от сервера ревизии в офис будет идти как задумывалось в первой статье)

Выходит, нам нет никакой необходимости передавать по OSPF всю сеть мобильной группы (192.168.3.0/24), более того, мы не может этого делать, т.к. человек занимающийся переоценкой и группа ревизии зачастую находится в разных местах, а связность должна быть с севером и с Wi-Fi принтером одновременно.

Поэтому, я решил, что наиболее оптимальным решением данной задачи, будет передача more specific address /32 конкретно этих двух устройств – принтера и сервера.

Для этого нам потребуется следующие инструменты из богатого функционала OSPF:

  1. Point-to-Point network-type
  2. Redistribution static routes
  3. Filtering

В начале определимся с алгоритмом, как мы будем передавать информацию о Wi-Fi принтере и сервера от магазинов в офис.
Для этого необходимо, чтобы протокол OSPF знал о том, что к данному роутеру подключены эти сети и выполнял анонсирование этих маршрутов центральному роутеру.
Протокол OSPF анонсирует сети двумя способами:

  1. Анонсирование всех сетей, принадлежащих интерфейсу, на котором включен OSPF, если этот интерфейс не Passive
  2. Анонсирование сетей, через редистрибуцию других протоколов динамической маршрутизации, подключенных напрямую маршрутов, статических маршрутов

Итак, я решил поступить следующим образом:

  1. Запуск процесса OSPF во всех магазинах и центральном роутере
  2. Создание статических маршрутов /32, для сервера и принтера во всех магазинах
  3. Фильтрация ненужных статических маршрутов (а их много) при редистрибуции в OSPF
  4. Средствами 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 к сожалению случаются, но магазины больше этого не замечают.

Статья снова получилась большой, благодарю за внимание и терпение. Буду рад критике и замечаниям. Если есть вопросы задавайте с удовольствием отвечу.

Автор: feo_sobolev

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js