Как Я Поймал Wi-Fi Принтер Через Ospf, Корпоративную Сеть На Mikrotik Часть 2

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

Среди этих задач была организация доступа к серверам в офисе для устройств сотрудников аудиторского отдела, перемещающихся из магазина в магазин (Часть 1).

А еще о том, как я поймал гуляющий по магазинам Wi-Fi-принтер, использующий протокол динамической маршрутизации OSPF (Часть 2).

Как и раньше, я надеюсь, что это решение поможет кому-то или новичку решить подобные проблемы.

Буду рад критике от профессионалов.

Если кого-то заинтересует название, посмотрите вырезку!

Часть 0. Что дается

Ко мне обратилась организация - сеть розничных магазинов с просьбой организовать для них сегментированную сеть с возможностью бронирования и ограниченным бюджетом.

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

Связь между всеми магазинами города организует местный интернет-провайдер, предоставив предприятию отдельный VLAN внутри своей сети.

Таким образом, вся сеть во всех магазинах и в офисе разместилась в одном большом Широковещательный домен Layer2 .

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

1. Все устройства в сети могут видеть друг друга на уровне 2.
2. Отсутствие каких-либо политик фильтрации трафика.

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

1. На предприятии есть разные серверы, выполняющие разные роли.

2. Существуют специальные терминалы сбора данных ( ТСД ), на рисунке я их назвал ТАБЛЕТКИ.
   • Есть стационарный ТСД привязаны к конкретному магазину и не покидают его границ.

     У них есть IP-адреса из пула устройств в магазине.

   • Есть аудит ТСД и отдельный сервер ревизий, с которым они взаимодействуют. Эти ТСД постоянно мигрирующий из магазина в магазин, где проводится аудит.

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

Организация работы аудиторского отдела очень интересна и уникальна.

Во всех магазинах есть точки доступа Wi-Fi с одинаковым SSID и ключами шифрования.

Таким образом, ревизионные ТСД имеют статический IP-адрес из собственного отдельного пула (192.168.3.0/24).

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

Сервером ревизий был RDP-сервер со специальной базой данных.

Которая перед проверкой была синхронизирована с основным сервером базы данных.

Сервер ревизий также загружал с сервера хранения необходимые для работы файлы.

Терминалы сбора данных (TCD — Планшеты) взаимодействовали в основном только с сервером аудита.

Однако иногда, в крайних случаях, когда на сервере аудита что-то шло не так, они взаимодействовали напрямую с RDP-сервером, находящимся в офисе.

Все остальные ТСД (постоянно находящиеся в магазинах и привязанные к ним) взаимодействовали только с основным RDP-сервером.

Итак, кажется, все ясно и просто.

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

Однако, как мне рассказали местные сисадмины, за многие годы существования компании при проверках происходили различные случаи.

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

Вот почему исторически сервер аудита путешествовал вместе с ТСД из офиса в магазины .

Обычно это происходило вечером накануне дня проверки.

Администратор заносит в магазин сервер, подключает его к любому свободному порту на любом из свитчей магазина (помним, что сеть плоская и все порты соединены одним доменом L2).

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

Важно отметить, что инициатором соединения всегда является сервер ревизии.

Вернемся к реализации распределенной сегментированной сети в первом магазине.

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

Приведу изображение из предыдущей статьи, чтобы было понятно, что изменилось в магазине.

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

Напомню, как выглядит адресация в магазинах после появления роутеров:

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

географически находится с ними в одном магазине , однако они не могут подключиться к основному RDP-серверу в офисе.

А сам сервер аудита, находясь вдали от офиса, не может синхронизировать данные.

Так как это был первый магазин, который перевели, и вся сеть не была полностью переведена на новый режим работы.

График работы аудиторской группы уже расписан: сегодня они здесь, завтра в другом магазине, потом снова здесь и т. д. Требуется срочное решение для обеспечения связности группы аудита (диапазон IP-адресов которой статический: 192.168.3.0/24) Как я писал выше, на этой схеме Инициализатор синхронизации — это сам сервер ревизий: он сам подключается к другим серверам и выполняет нужные ему задачи.

Доработка ТСД при необходимости, также являются инициализаторами сеанса RDP с основным RDP-сервером в офисе.

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

При этом адресация устройств остается неизменной.

Возможность для них получать адреса по DHCP в конкретном магазине Нет .

Поэтому первое решение, которое пришло мне в голову как временное (и вроде бы там останется постоянным) — это реализация НАТ Я проверил у сисадминов, ясно ли, что ни одному из устройств, кроме ТСД сотрудника отдела аудита, не нужно подключаться к серверу аудита? Ответ был нет. Правда, иногда программистам необходимо подключиться удаленно по RDP. Однако сделать это они могут, подключившись к любому ПК в магазине и с него подключившись к серверу.

Если, конечно, ПК в магазине видят сервер.

Итак, приступим к решению поставленной задачи.

Первым делом прошу администраторов установить на сервере все ревизии ТСД и адрес основного шлюза: 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
 

   

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

Но, если у нас 12 магазинов с одинаковыми адресами, как серверы в офисе будут знать, куда отправлять посылки? Вот он приходит нам на помощь НАТ , целью которого является изменение IP-адресов, с которых осуществляется доступ мобильной группы.

Для этого я выясняю, к каким конкретно серверам необходим доступ устройствам мобильной группы, и создаю для них отдельный адрес-список:

[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

Теперь давайте составим правило для трансляции НАТ чтобы скрыть адреса источников контактов мобильных групп:

[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 в офисе.

Который впоследствии стал основным роутером.

Это значит, что нам нужно было сделать еще один в офисе.

НАТ широковещательная рассылка для скрытия транзитных сетей (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

Как видите, мне пришлось честно подписать это правило-костыль, потому что я не мог придумать, как иначе назвать это решение.

На данном этапе задача по обеспечению связи мобильной группы устройств с серверами в офисе из любого магазина выполнена.

Удаленный доступ к серверу ревизий для программистов при необходимости можно получить, подключившись к любому ПК в магазине, который будет выходить в сеть 192.168.3.0/24 через роутер магазина, который знает об этой сети как о своей.

с прямым подключением сети.

Часть 2. Мой Wi-Fi-принтер отказывается печатать ценники!

В это время всплыли мелкие дефекты, которые были спешно исправлены.

В целом все прошло хорошо, как и планировалось.

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

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

Оказывается, среди мобильной группы есть отдельный сотрудник, который также есть ТСД из диапазона (192.168.3.0/24), с которым он ходит в разные магазины, но его задача — переоценить товары, срок годности которых приближается.

Из своего ТСД он подключается к основному RDP-серверу, расположенному в офисе, и работает с базой данных.

Сканирует товары и печатает новые ценники.

Все нормально, сотрудник спокойно приходит в тот или иной магазин, как и раньше подключается к сети Wi-Fi, без проблем подключается к RDP-серверу в офисе, делает то, что нужно, начинает печатать на принтере, но.

.

Принтер, на котором печатаются ценники, мобилен! Ранее имея IP-адрес из диапазона 192.168.1.0/24 и плоскую сеть с одним L2, он оставался доступным находясь в любом из магазинов.

Также некоторое неудобство доставляло то, что при подключении из офиса к серверу аудита один из компьютеров в магазине, где проходил аудит, был занят программистами из-за того, что сервер аудита находился за NAT, и для доступа к нему необходимо было занять один из компьютеров, расположенных в магазине.

В общем, мне дали новую задачу:

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

Добро пожаловать в ОСПФ! Тут, правда, пришлось снова сделать еще один костыль, так как я в первой статье писал, что Пакеты OSPF не прошли через сеть ISP-1 .

Ни через multicast, ни через unicast, потому что CPE (терминалы xPON от Huawei) только что сбросил протокол 89 .

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

OSPF в данной ситуации нужен для двух вещей:

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

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

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

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

1. Тип сети «точка-точка»
2. Перераспределение статических маршрутов
3. Фильтрация

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

Протокол OSPF объявляет сети двумя способами:

1. Объявление всех сетей, принадлежащих интерфейсу, на котором включен OSPF, если этот интерфейс не является пассивным.

2. Анонсирование сетей посредством перераспределения других протоколов динамической маршрутизации, маршрутов с прямым подключением, статических маршрутов.

1. Запуск процесса ОСПФ во всех магазинах и центральном роутере
2. Создание статических маршрутов /32 , для сервера и принтера во всех магазинах
3. Фильтрация ненужного x статические маршруты (а их много) во время перераспределения и в OSPF
4. Посредством NetWatch отслеживание реальной доступности устройств в конкретном магазине и управление статическим маршрутом

Давайте запустим ОСПФ процессы на роутерах в магазинах и в офисе.

Все магазины будут в одном область по умолчанию 0 .

Состояния соседства между маршрутизаторами ОСПФ будет происходить в туннельных интерфейсах, у нас их 2 между каждым магазином и офисом.

На маршрутизаторах Микротик цена точка-точка интерфейс по умолчанию - 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

Аналогичные действия проделываем на роутерах в магазинах плюс, указав на необходимость перераспределения статических маршрутов, я решил их объявить как Тип 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

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

Также я указал в настройках ОСПФ два фильтра: ospf-вход и ospf-выход , эти фильтры в Микротик играть похоже на Карта маршрута роль в маршрутизаторах Циско.

Предлагаю рассмотреть эти фильтры:

[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-вход фильтрует любые маршруты, которые могут прибыть на ОСПФ к маршрутизатору.

Фильтр ospf-выход фильтрует все возможные маршруты, которые можно рекламировать посредством перераспределения, за исключением более конкретный /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

Обратите внимание, что я добавляю эти статические маршруты с параметром отключен = да , то есть эти маршруты будут отключены, недоступны и, следовательно, не будут включены в объявление через ОСПФ .

Почему? Потому что если я добавлю активные маршруты во все магазины сразу, то на основном роутере они будут видны через все магазины, и мы вернемся к исходному.

Когда не знаем, где именно ловить рыбу Wi-Fi-принтер , т.к.

эти маршруты есть во всех магазинах.

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

Понять это мы можем по доступности устройства через пинг, поэтому создаём два правила 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 + трек из мира Циско .

Пингуем сервер и Wi-Fi-принтер каждые 10 секунд с таймаутом 2 секунды.

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

Таким образом, Wi-Fi-принтер Теперь он снова печатает, как и раньше, и программисты могут работать по RDP напрямую с сервером ревизий.

Как будто у нас все еще есть плоская сеть.

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

За эти полгода все работает идеально и без сбоев.

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

Буду рад критике и комментариям.

Если есть вопросы, задавайте, с радостью отвечу.

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

• Выбор Темы Для Создания Своего Блога

  19 Oct, 24

• Толкать

  19 Oct, 24

• Starcraft 2 Запущен В Автономном Режиме. Но Пока Не С Кем Играть

  19 Oct, 24

• Сколько Разработчиков И Сколько Программистов...

  19 Oct, 24

• Небольшая Задача Для Веб-Мастеров

  19 Oct, 24

• Есть Ли Жизнь На Марсе И Если Да, То Как С Ней Бороться

  19 Oct, 24

• Создание Блога – Творческое Исследование

  19 Oct, 24

• Что Такое «Эффективность Проектирования» Для Ит-Специалиста?

  19 Oct, 24

• Инди-Способ. Как Я Начал Делать Игры

  19 Oct, 24

• Как Сделать Вашу Электронную Рассылку Более Эффективной

  19 Oct, 24