В данной статье хочу поделиться с вами решением некоторых дополнительных задач, которые предстали передо мной во время реализации проекта. Среди таких задач была организация доступа к серверам в офисе для устройств сотрудников отдела ревизии, которые перемещаются из магазина в магазин (Часть 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 к сожалению случаются, но магазины больше этого не замечают.
Статья снова получилась большой, благодарю за внимание и терпение. Буду рад критике и замечаниям. Если есть вопросы задавайте с удовольствием отвечу.
Комментарии (38)
vasilevkirill
04.06.2016 22:28фильтр
add action=discard chain=ospf-in ospf-type=intra-area
не работает
Note that internal RIP filtering is done using prefix lists [and internal (intra-area) OSPF filtering is not supported yet]
vasilevkirill
04.06.2016 22:39Я конечно не знаю насколько у вас всё в схвачено, но best practice в фильтрах ospf всё таки с начало "что то разрешать", а потом всё запрещать, иначе от одного неверного действия можете получить неработающую сеть, вспомните яндекс…
я бы сделал как нибудь так.
/routing filter add action chain=ospf-out prefix=192.168.3.0/24 prefix-length=32 action=accept add action chain=ospf-out action=discard add action chain=ospf-in prefix=192.168.3.0/24 prefix-length=32 action=accept add action chain=ospf-in action=discard
feo_sobolev
04.06.2016 22:58Возможно, но я предпочел фильтровать все, для запрета. Т.к. не вижу никакого смысла разрешать хоть какую-нибудь сеть, т.к. все равно в данном дизайне мне ненужно чтобы маршрутизаторы в магазинах получали по OSPF хоть какой-то маршрут.
Вернее, получать они его в OSPF-database все равно будут, т.к. это Link-state-protocol, но мне не нужно чтобы маршруты из OSPF Database устанавливались в Routing-table.
feo_sobolev
04.06.2016 23:03Кстати, данное правило:
add action chain=ospf-in prefix=192.168.3.0/24 prefix-length=32 action=accept
add action chain=ospf-in action=discard
Как раз позволит другим магазинам видеть сервер ревизии и Wi-Fi Printer, т.к. оно разрешает установку маршрута в Routing-Table из OSPF-Database любого адреса из пула 192.168.3.0/24 с префиксом /32.vasilevkirill
04.06.2016 23:18+1Я просто привел пример, с /32 понятно, вы не боитесь, что когда нибудь, кем нибудь может распространится дефолтный маршрут ext-2, особенно если всё же избавитесь в перспективе от huawei и проблем с мультикастом в L2 сегменте не будет
feo_sobolev
04.06.2016 23:25Согласен, есть такая вероятность, однако, даже если прилетит ext-2 по OSPF, то у меня в routing tables административное расстояние для OSPF остается по умолчанию — 110 и данный машрут проиграет статическим default-route.
Но, в целом с замечанием согласен.
feo_sobolev
04.06.2016 22:55Хмм, у меня прекрасно работает и добавляется.
Интересную заметку Вам выдает роутер:Note that internal RIP filtering is done using prefix lists [and internal (intra-area) OSPF filtering is not supported yet]
У Вас, случаем ospf-in не используется в роли prefix-lists для фильтрации маршрутов в роутере RIP?
Дело в том, что протокол RIP действительно не поддерживает типы ospf-маршрутов. Т.к. он не имеет никакого понятия о логике работы OSPF, при этом прекрасно умеет работать с Prefix-listsvasilevkirill
04.06.2016 23:11это не заметка, а официальная документация, микротик не умеет фильтровать маршруты intra-area
feo_sobolev
04.06.2016 23:20Хмм, там справа по ссылке заметка:
Applies to RouterOS: v3, v4 +
У меня в 6-й ветке, все прекрасно фильтруется.
Собственно в решении оно именно так и используется.
Нет, правда, если интересно, попробуйте собрать стенд и проверить.vasilevkirill
04.06.2016 23:25Дело в том, что я непросто это их головы взял, это действительно для меня на данный момент проблема.
сравните LSA таблицу маршруты intra-area и маршруты какие пападают в таблицу маршрутизацииfeo_sobolev
04.06.2016 23:30Я об этом и говорил, что OSPF LSA Database они и будут — это норма.
Сравнил в LSA множество маршрутов intra-area, которые имеются на Point-to-Point интерфейсах, примерно так:
28 10.30.40.18/32 intra-area 20 10.20.30.1 VPN-OFFICE
29 10.30.40.46/32 intra-area 30 10.20.30.1 VPN-OFFICE
30 10.30.40.254/32 intra-area 40 10.20.30.1 VPN-OFFICE
32 192.168.3.252/32 ext-1 40 10.20.30.1 VPN--OFFICE
Однако в таблице маршрутизации этих маршрутов нет. А вот, если я выключу правило, то они появляются!
Pave1
05.06.2016 15:05А не проще было сделать L2 тунелирование поверх L3 для заданных сервисов? И проще главное намного. У микротика есть простые средства для этого. ИМХО это сильно правильнее чем плодить адовые костыли с маршрутизацией. Которые грозят потенциальными проблемами и дальнейшему нагромождению костылей.
feo_sobolev
05.06.2016 15:13Была такая мысль. Однако, повторюсь, в каждом магазине, есть своя локальная сеть. В которой существует несколько точек доступа с идентичными SSID и паролями. Ранее, когда сеть была плоской на L2 проблем не было.
Теперь, каждый магазин это — отдельный, изолированный от общей сети broadcast-домен,
Так-же, между каждым из магазинов, и офисом существует по 2 канала связи, через разных провайдеров.
Для того, чтобы решить данную задачу с туннелированием L2 поверх L3, необходимо в каждом магазине по крайней-мере установить еще по одной беспроводной точки доступа, или настроить Virtual-AP, куда бы цеплялись устройства клиентов мобильной группы.
Имеющиеся точки доступа в магазинах не поддерживают VLAN и Virtual-AP, там вообще нет управляемых коммутаторов. Да и устройств в каждом из магазинов не так много и бродкаст-домен не большой.
Тянуть новые СКС и подключать отдельные точки доступа для мобильной группы. Или менять текущие точки доступа и ставить управляемые коммутаторы никто не будет.
Хотя это было бы безусловно красивее.
Ну и плюс, вопросы о надежности L2 поверх L3, которое будет загоняться еще в один туннель (когда магазин будет работать на резервном канале), то получаем вероятные проблемы с MTU. Но это не так страшно, как вероятность образования l2 петли.
Так-что, уж лучше Dinymac Routing.
MrJeos
05.06.2016 16:54А IP-адреса жестко заданы на всех ТСД (их адрес и адрес сервера)? Не увидел этого момента в статье.
feo_sobolev
05.06.2016 17:02Да, IP-адреса заданы жестко для ВСЕХ ТСД, так-же, как и адрес сервера ревизии, который ездит с ними по магазинам.
kvant21
05.06.2016 17:03Ужас, костыли, тлен :( Почему DHCP-то нельзя для ревизионной группы этой? У вас же для остальных устройств в этом магазине есть DHCP?
А про принтер — виндовый DHCP умеет в DNS регистрировать, вообще никаких проблем с этим нет. Даже если у вас там и не виндовый, то скриптом искать нужные MACи в DHCP DB и обновлять DNS записи точно проще, чем «возить за собой» подсеть по филиалам.feo_sobolev
05.06.2016 17:15Повторюсь, что проект был внедрен не сразу, так — чтобы по щелчку пальцев, щелк — все магазины работают по новому.
Моей задачей было организация отказоустойчивой сети, с соблюдением ряда жестких условиях, на случай всяких-разных аварий, об этом более подробно в первой статье.
По завершению проекта, когда сеть отказоустойчева — нет никакой необходимости возить сервер ревизии по магазинам. Но я писал, для чего это делается, т.к. у них были случаи, когда магазины лишали связи. Конечно — это форс-мажор и бывает не каждый раз
По этому, вариант оставить сервер ревизии в офисе, а мобильным ТСД для ревизии выдавать DHCP проблем нет. В целом это было бы правильнее. Но, т.к. все переводилось постепенно, то дизайн требовал уже предустановленного решения, чтобы работало и там, где переведено и там где не переведено.
Я не администрирую их сервера и сеть, я не работаю в той компании, это был частный проект, в котором я отвечал строго за связь и конвергетность.
Насчет отдельного виндового DHCP, я не являюсь администратором Windows, потому тут ничего на скорую руку предложить бы не смог.
В случае, единого DHCP, в голове рисуется дизайн, с DHCP-Relay на Микротиках, когда они будут запрашивать адреса, для всех подключаемых устройств в том или ином магазине.
И, в каждом из магазинов пул выдаваемых устройств должен быть разным.
Тогда да, если единый DHCP сервер, сможет правильно в зависимости от того, откуда прилетел request выдать IP- из верного пула. Плюс, обновлять запись в DNS, это вероятное решение.
Вообще, так сложилось, что в нашем маленьком городке многие предприятия где есть нечто вроде своей сети, любят назначать статику.
По факту DHCP им был нужен только для различных устройств пользователей — телефонов, например для обмена сообщениями через WhatsApp и только.
kvant21
05.06.2016 17:39+2Ну, вообще говоря, сервер тоже мог бы быть на DHCP, и можно было бы и дальше его возить по филиалам. Можно либо релеить DHCP в центральный офис, либо ставить контроллеры домена в филиалы, которые будут локально раздавать DHCP, регистрировать на своих локальных DNS, и синхронизировать DNS-записи между собой.
Прекрасно понимаю ситуацию, вы решали и решили задачу с помощью доступных вам инструментов. Ничего плохого тут не хочу сказать. Просто в результате получились костыли :) Которые поддерживать несколько сложнее чем более стандартные решения.
А статика повсюду это печаль — администраторы усложняют жизнь сами себе на ровном месте.feo_sobolev
05.06.2016 17:57Вариантов решения этой задачи несколько.
Одним из «сетевых» вариантов, было бы действительно туннелирование, о котором писали Выше, плюс отдельные Virtual-SSID с нужным VLAN, тогда бы, при перемещении между магазинами, именно мобильная группа была бы в едином broadcast-домен, такой себе end-to-end vlan. Но опять-же, требуются дополнительные устройства + плюс уменьшение mtu (не очень страшно) + риск петли, если какое-то из устройств — глюканет. Хотя, для этого есть STP. Либо делать туннелирование до конкретного IP, маршрут к которому будет меняться если пропадет основной канал.
Ваш сценарий мне понравился. Однако он требует настройки дополнительного решения, уже за пределами тех девайсов, что у меня были.
Если его брать, то только релить, т.к. на то, чтобы что-то дополнительно ставить в другие магазины они бы точно не пошли. А опыта работы с Windows DHCP + DNS у меня к сожалению нет.
feo_sobolev
05.06.2016 18:03Плюс, опять-же единый DHCP сервер для всех филиалов, это такая-себе точка отказа.
Скажем, если вдруг в офисе не будет света (а такое, уже было, во время внедрения) и, он полностью уйдет в down, то тогда устройства в магазинах перестанут получать DHCP.
Ведь изначально планировалось, чтобы магазины по максимуму были автономны. И не завис или от офиса, только если им не нужно с ним работать, например в БД по RDP, к примеру кассы у них автономны и должна оставаться возможность проведения безналичных платежей.
Так-же некоторые сотрудники, во время работы, регулярно фотографируют товары и передают их друг друг через WhatsApp, по этому если они не смогут получить DHCP это будет небольшой но все-таки проблемой.
А так, каждый филиал полностью автономен. В общем, игра компромиссов :)
rub_ak
05.06.2016 21:00А зачем держать два канала, если предпологаеться возможное вылетание офиса?
Просто интерсно какие доводы были за два канала, если магазины рассчитаны на автономную работу?
Неужели сложно в офисе поддерживать работу, у нас как-то было тоже офис наполовину обесточили, так мы переноски кидали с тех мест откуда можно было запитаться, и выключили все по максимуму, но продолжали работать.
PS Я правильно понял что у вас l2, но кастрированный и ospf не работает, нельзя ли было попросить заменить оборудование, чтобы был полноценный l2?feo_sobolev
05.06.2016 21:16Начну с ответа на P.S.
И да и нет. L2 там скорее полноценный: IP, GRE, пакеты ходят, PPPoE ходит. Однако, в некоторых местах точки подключены через PON-технологию.
О которой Вы можете прочитать здесь. Абонентские терминалы Huawei H810E, не пропускают OSPF пакеты со стороны OLT в сторону абонента.
Также были случаи, когда например со стороны абонента вверх не ходили DHCP-Offer пакеты.
Еще изначально по умолчанию, трафик в одном vlan между разными ONU подключенными к одной OLT не ходит, но это решается на olt специальной фичей. С OSPF пока не разобрались как активировать, но мысли куда копать есть.
Просто, среди наших клиентов, никто не использует dynamic routing. (По крайней-мере среди тех, кто подключен через PON)
Плюсов у него больше, чем минусов.
По поводу автономности, я просто привел пример с полным down в офисе, естественно, такого быть не должно.
Просто, кассы на этот счет автономны, и могут отпускать товар без связи с офисом, за наличку при отсутствии интернета, а учитывая что банковские карты нынче распространены, то интернет быть обязан, для обеспечение безналичных платежей.
Поэтому если связь с офисом пропадет, магазин в плане работы с клиентами будет работать и отпускать товар. Продажи не остановятся.
Тем не менее, не смотря на то, что кассы автономны, несколько раз в сутки они выполняют синхронизацию БД, по этому связь необходима, хоть и не постоянна.
Так-же ТСД, что находятся в магазинах, и выполняют прием товаров и другие обработки, тоже работают напрямую с серверами которые находятся в офисе.rub_ak
05.06.2016 21:40Да я знаю что такое PON у самих интернет и второй офис по pon подключен, но у нас все по другому. Везде openvpn TAP туннели на отдельных железках (просто маленькие системники с убунтой сервер, даже там где темное волокно) а к ним уже маршрутизаторы подключены, правда у нас и сети везде разные и DHCP один, и железок которые как у вас путешествуют нету, а чтобы кто-то канал намерено отрубил такое просто невозможно. Но у нас и нету 20 магазинов, у нас пока только 3 удаленные точки подключения.
feo_sobolev
05.06.2016 22:00Ну, не совсем у нас, т.к. я работаю инженером технической поддержки в ISP, который как раз и организовывает связь между всеми магазинами предприятия, среди которых есть и супермаркеты. Ко мне обратились наши клиенты, я по мере своих знаний, умений и возможности реализовал проект. По тем требованиям и задачам, что передо мной стояли.
Изначально у них была плоская сеть, с одним большим l2 доменом, где в которой в одном месте поднимался интернет, а другие магазины в этой локальной сети уже брали интернет и остальные сервисы из офиса. Со временем сеть росла, дальше Вы знаете :)
В целом правильно, что используете туннели внутри провайдера.
Удивительно, но это далеко не единственная компания в нашем городе, имеющая более 5 разбросанных по городу точек, объединенных во едино, из тех, что являются нашими клиентами. А это и магазины и сети аптек.
Однако ни у кого нет сегментации, везде один l2. Правда, иногда вводят логическую адресацию разную, чтобы было проще ориентироваться и везде юзают статику.
feo_sobolev
05.06.2016 21:23Просто, я не очень корректно выразился, насчет полного down в офисе, это скорее очень большой Форс-Мажор, который, конечно, будут быстро исправлять. Просто единый DHCP-сервер для всех, это все-таки, пожалуй также узкое место, в плане автономности каждого магазина, с точки зрения работы сети. Ведь одной из главных целей, была также и автономность, чтобы сбой в офисе, или в каком-то из магазинов, как можно менее критично отражался на работе других магазинов.
lalexrus
06.06.2016 08:562 канала — при автономной работе магазинов это излишне, мало того подавляющее большинство кассового ПО позволяют работать без постоянного подключения к кассовому серверу. Работа с ревизиями так это вообще песня — это просто адъ и треш — носить сервер на ревизии (вот бы наши сисадмины порадовались бы :) ), причем у ревизоров есть ТСД (!!!!) наличие доступа к некому серверу ревизий тут вообще не имеет какой-либо обоснованности, т.к. обычно (если подходить к вопросу правильно) — ревизия это снятие фактических остатков, никаких серверов в «онлайн» доступе для этого не надо, достаточно загрузить нужный набор номенклатуры и ШК (ну я в общем случае — возможны варианты).
И еще во-первых я бы отказался от VPN ISP по многим причинам — вполне реально (если уж речь у вас про mikrotik) сделать vpn относительно недорого на mikrotik (к примеру 1100 голова, 951UI или G в качестве магазинских), во-вторых делать ОДИН DHCP сервер это как то сверх моего понимания — магазин может работать на «свистке», либо быть вдали от жизни (у нас например +500 км от Салехарда есть магазин — на каком-то мысе :) ), и если нет связе то все капут?feo_sobolev
06.06.2016 10:34Вы наверное не читали первую статью, эта статья является продолжением первой, скорее даже не продолжение а дополнением, так как задачи и проблемы описаны в первой статье, а здесь лишь некоторые дополнительные нюансы, возникшие при решении первостепенных задач.
Я не системный администратор работающий в той компании, я человек со стороны, которого пригласили решить проблемы с сетью.
Попробую вкратце:
1. ТСД — представляет из себя мобильное устройство: КПК, с Windows Mobile (6.x) на борту, сканером штрихкодов, и Wi-Fi сетевым адаптером.
Оно работает по принципу: устройство подключается к Wi-Fi, имея статический IP (или получая по DHCP), далее по RDP через сеть, подключается к серверу в офисе. Затем человек работает с БД.
2. Кассы работают автономно, как Вы и указали, однако тем не менее, им необходимо, периодическая синхронизация цен с БД расположенной в офисе, синхронизация остатков. Для закрытия и открытия магазина, так-же требуется синхронизация.
3. Изначально все магазины подключены к одному ISP, где получают от него транзиутную сеть, а не выделенный интернет на каждый магазин.
Прежде всего, это просто дешевле, услуга организации локальной сети у провайдера, стоит дешевле, чем предоставление интернета в каждый магазин. Да и им, на первом этапе это было проще. До тех пор, пока сеть не разрослась.
4. По-скольку магазины все были в одной сети, предоставленной провайдером, то считайте, подключены к одному коммутатору, естественно DHCP был один и в офисе.
В офис, от провайдера заходят 2 линка (считайте Dual-homed схема), но переключение между линками осуществлялось вручную.
Какие здесь могут быть проблемы, с таким дизайном:
1. Нет связи между конкретным магазином и ISP. Результат в магазине нет инета, платежи не проходят, нет связи с сервером для ТСД.
2. Нет связи между линком 1 от ISP с офисом, во всех магазинах повторение ситуации N1, пока админы вручную не переключат линк с медика на PON-терминал. В таком случае все работает, за исключением DHCP для мобильных устройств сотрудников в магазине.
3. Нет интернета у ISP. Локалка работает, платежи через безнал не прохдят.
4. Полный ахтунг, нету обоих линков от ISP к офису. Комментировать последствия думаю не надо.
Что было сделано, можете прочитать в 1-й статье, повторюсь эта статья лишь дополнение к той. И да, как раз таки в офисе был установлен Mikrotik RB 1100, а в филиалах Mikrotik hEx (он по мощнее чем 951UI/G), однако было решено, что:
A. Магазины по прежнему в приоритете берут интернет (для проведения онлайн платежей) из офиса.
B. В случае, если нет связи с офисом, берут интерет через резерв.
C. Должна быть связь с офисом для синхронизации касс и работы ТСД.
И да, после внедрения Mikrotik DHCP в каждом магазине раздавался отдельный своим роутером, находящимся в самом магазине.
Уже после начала перевода магазинов на Mikrotik выяснилось то, о чем эта статья.lalexrus
11.06.2016 16:45hEx без WiFi, в нашем случае никак не катит, т.к. ТСД работают через Wifi.
а вот RB1100 изначально думали менять на что-то из CCR, в итоге по результатам опытной эксплуатации признали это не целесообразным т.к. 1100 прекрасно справляется с нашим количеством торговых объектов.
и все таки мне кажется вся эта система излишне дорогая и не надежная (падение одного/двух линков — инет из офиса — например, элементарно — нет электричества несколько часов) фактически накрывает все медным тазом (я включаю в это и объем авральных работ со стороны сисадминов).
я не знаю чем думают сисадмины этой компании, но вам следовало бы на это указать, и предложить интернет в магазинах непосредственно, это бы повысило автономность торговых объектов как минимум в части розничной продажи — что собственно и является приоритетом.feo_sobolev
11.06.2016 21:00Все правильно, поэтому в каждую торговую точку, был заведен второй провайдер (ADSL, Rostelecom), от которого они берут чистый интернет. (Без локальной сети)
А система работает следующим образом:
1. В штатном режиме, магазин берет интернет из офиса, через локальную сеть провайдера (в магазине это единственный линк через ISP1, а в офисе это линк 1 от ISP1)
2. В офис приходят 2 линка от ISP-1 (основной и резерв именно от ISP1 ) + еще один линк от ISP-2, если падает 1-й линк ISP-1, то магазины берут инет c офиса через 2-й линк по ISP-1.
3. Если в офисе падают оба линка от ISP-1 то все магазины берут интернет от ISP-2 (локальные ADSL модемы, каждый в своем магазине), и так-же имеют связь с офисом по VPN через мир по каналу ISP-2 (ADSL)
4. Если в офисе есть 2 линка с ISP-1 и локальная сеть работает штатно, но у ISP-1 не работает интернет, тогда офис работает через ISP2, а все магазины берут инет не от Офиса (который уже сидит на ISP2) а через свои локально подключенные модемы ADSL через ISP-2.
Об этом я подробно писал в первой статье.
Wi-Fi точки доступа в каждом магазине уже были свои :) На момент начала работ. В каждом из магазинов было от 2 до 4х точек доступа.
feo_sobolev
11.06.2016 21:05Добавлю по пункту 4.
В случае, если у ISP-1 нет инета. но он продолжает нормально обеспечивать локальную связь межуду магазинами и офисом, то магазины берут только интернет через ISP-2, а локальная связь между магазинами и офисом, продолжает работать через быстрый канал от ISP-1
alexkuzko
Первое что пришло в голову, а почему не использовать ДНС имена?.. Трафик к 53-му порту заворачивается легко и принтер легко найти.
feo_sobolev
Добрый вечер! Только сейчас увидел Ваш комментарий.
Не совсем понял, что именно Вы имели ввиду, под использованием DNS-имен.
И как 53-й порт поможет отыскать местонахождение принтера.
rub_ak
Он имеет в виду что у устройств есть DNS имена, и серверам и терминалам становиться все равно какие у них IP и из каких сетей.
feo_sobolev
Хорошо, допустим. А где будет хранится запись DNS-имени устройства?
Как работает DNS? Он по символьному имени к примеру printer.local должен вернуть актуальный IP-адрес принтера (наприер 192.168.3.3).
Каким образом, сервер DNS будет знать актуальный IP-адрес принтера? Кроме как, если его забить в ручную?
Это в том случае, если принтер имеет статический IP-адрес, впрочем в нашем случае, принтер как раз и имеет статический IP-адрес.
Далее, даже если мы создадим статическую A-запись DNS с этим IP на DNS-сервере,
printer.local = 192.168.3.3
Мы получим аналогичную ситуацию, откуда нам знать, в каком из магазинов в данный момент будет находится устройство с DNS-именем printer.local и заданным к этому имени IP: 192.168.3.2
Вот, если бы, принтер умел автоматически после получения динамического IP информировать сервер DNS о том, что его IP был изменен, (что-то вроде DDNS на Soho-ротуреах), тогда да.
Но, это обычный маленький ручной принтер, который всего-лишь цепляется к Wi-Fi сети и печатает ценники :)
satoo
Можно переключить терминалы на dhcp. В микротике есть возможность запускать скрипт при выдаче Ip адреса. А в скрипте биндидь ip и dns запись.
feo_sobolev
Можно, но для этого должен быть один общий DHCP-сервер, т.к. в каждом магазине своей роутер со своим DHCP и своей адресацией.
Кстати, вспомнил аргумент почему терминалы группы ревизии со статическим IP, это также сделано для того, чтобы за каждым сотрудником закрепить конкретный терминал, и на этот терминал можно было попасть удаленно сис.админам, в случае чего.
satoo
1. можно сделать обновление в одном, двух, трех и пр dns сервером. уверен, что внутренний dns сервер (и не один есть). если он не будет работать, то будет плохо не только инвентаризации.
2. не составляет труда выдавать конкретные адреса для конкретных терминалов. кроме того, мы же будем подключаться к terminal2.domain.local
я не критикую, а показываю еще один способ решения задачи. кстати, судя по всему, у вас привязки во многом к ip адресам, а не к dns именам. хоть это может показаться более надежным — в действительности это плохо. dns очень простая, где-то не очень нужная, а где-то прямо необходимая служба. кроме того, она позволяет более гибко резервировать оборудование и распределять нагрузку.
feo_sobolev
Спасибо. Для себя уже этот момент уяснил, не Вы один сегодня дали такую рекомендацию.
Вероятно, в других проектах, которые будут попадаться мне на моем пути, попробую данное решение.