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

Всім привіт! Нарешті я вирішив внести обіцяне додаток до статті: Резервування внутрішніх і зовнішніх каналів зв'язку, статична маршрутизація, корпоративна мережа на MikroTik.

В цій статті хочу поділитися з вами рішенням деяких додаткових завдань, які постали переді мною під час реалізації проекту. Серед таких завдань була організація доступна до серверів в офісі для пристроїв співробітників відділу ревізії, які переміщуються з магазину в магазин (Частина 1). А так само про те, як я ловив гуляє по магазинах Wi-Fi принтер за допомогою протоколу динамічної маршрутизації OSPF (Частина 2).

Як і колись, сподіваюся що дане рішення допоможе кому-небудь з новачків вирішити аналогічні завдання. Буду радий критиці з боку професіоналів.

image

Кого зацікавив заголовок — прошу під кат!

Частина 0. Що дано

Дозвольте трохи коротенько нагадати про те, що було зроблено в попередній статті. До мене звернулася організація – мережа торгових магазинів з проханням організувати їм сегментовану мережу з можливістю резервування та обмеженим бюджетом.

Переді мною поставлено завдання зробити з плоскою територіально розподіленої по місту мережі: сегментовану мережа, з ієрархічної адресацією і головне з можливістю резервування.
Зв'язок між усіма магазинами по місту організовує місцевого ISP, шляхом надання підприємству окремого VLAN всередині своєї мережі. Таким чином, вся мережа у всіх магазинах і в офісі знаходилася в одному великому Layer2 Broadcast-домені.

У такої моделі є ряд недоліків:
  1. Всі пристрої в мережі можуть бачити один одного на Layer-2.
  2. Відсутність яких-небудь політик фільтрації трафіку.
  3. Єдиний Broadcast домен, результатом якого є те, що будь-широкомовний пакет від кожного з 400 пристроїв, обов'язково буде передано всім цим 400 пристроїв, розташованих в різних кінцях міста.
Коротку, спрощену схему розташування серверів наведу на малюнку 1 нижче:



І короткий опис того, що маємо:
  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.2 XX list=REVISION-Servers
add address=192.168.1.2 XX list=REVISION-Servers
add address=192.168.1.2 XX list=REVISION-Servers


Тепер, робимо правило для трансляції NAT, щоб приховати адреси джерел звернення мобільної групи:

[s@VERTOLET-GW] > ip nat firewall export
# jun/03/2016 21:42:00 by RouterOS 6.32.3
/ip nat firewall
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.2 XX list=REVISION
add address=192.168.1.2 XX list=REVISION
add address=192.168.1.2 XX list=REVISION

А також правило трансляції:
[s@MAIN-BORDER-ROUTER] > ip nat firewall export
# jun/03/2016 21:52:12 by RouterOS 6.32.2
#
/ip nat firewall
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, і для доступу до нього потрібно займати один з компів розташованих в магазині.

Загалом, переді мною поставлено нове завдання:
  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 на жаль трапляються, але магазини більше цього не помічають.

Стаття знову вийшла великий, дякую за увагу і терпіння. Буду радий критики і зауважень. Якщо є питання задавайте з задоволенням відповім.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.