Решения Wi-Fi-мост для Digital Signage и удалённых устройств

Wi-Fi-мост соединяет проводные сетевые устройства с интернетом или вышестоящей сетью через имеющееся Wi-Fi-соединение. Технически это клиентский мост (Client-Bridge): маршрутизатор подключается к имеющейся Wi-Fi-сети — точно так же, как это делал бы ноутбук или смартфон, — и предоставляет на своей задней панели собственную проводную LAN-сеть с Ethernet-портами. Всё, что вы подключаете к этим портам, оказывается тем самым опосредованно подключено к Wi-Fi, не имея собственного Wi-Fi-оборудования.

Этот режим работы называется режимом Wi-Fi-клиента или «WiFi as WAN»: маршрутизатор использует свой Wi-Fi-модуль не для того, чтобы развернуть собственную сеть, а чтобы — подобно обычному конечному устройству — подключиться к чужой сети. Настоящая сложность заключается в следующем вопросе: как устройства за мостом становятся видимыми в чужой сети?

Очевидным решением было бы прозрачное мостовое соединение на уровне 2 (Layer 2) — в этом случае мост передавал бы в Wi-Fi-сеть собственный MAC-адрес (уникальный аппаратный идентификатор сетевого устройства) каждого подключённого устройства без изменений, так что каждое устройство выглядело бы как самостоятельный участник сети. На практике это регулярно терпит неудачу: чужие и ограничивающие сети — корпоративные Wi-Fi-сети, гостевые сети в отелях, залах или на строительных площадках — редко рассчитаны на то, чтобы принимать произвольное количество чужих MAC-адресов и IP-запросов с одного подключения.

Более надёжный путь — это NAT-маршрутизация (Network Address Translation, преобразование сетевых адресов): мост выступает во внешней сети как единое устройство — один MAC-адрес, один IP-адрес — и внутренне транслирует между этим одним внешним адресом и множеством адресов устройств в собственной LAN-сети за ним. Для чужой сети это выглядит как единственное, неприметное конечное устройство. Именно это свойство позволяет использовать Wi-Fi-мосты на основе NAT даже в тех сетях, где настоящее мостовое соединение уровня 2 никогда не было бы разрешено.

Кратко о разграничении понятий, поскольку их часто путают: репитер или mesh-система лишь увеличивают радиус действия той же самой Wi-Fi-сети, не создавая новую сеть и не выполняя преобразование адресов, а радиорелейная связь (Wi-Fi «точка-точка») соединяет две площадки — например, два здания — на большем расстоянии. Это две другие задачи, отличные от задачи клиентского моста, который делает чужую Wi-Fi-сеть пригодной для использования проводными устройствами.

Так выглядел реальный запрос, который стал толчком для этого решения: клиент хотел эксплуатировать на удалённой площадке несколько дисплеев Digital Signage — подключённых проводным способом к Wi-Fi-маршрутизатору Teltonika, который был встроен в имеющуюся на месте сеть в роли моста. Однако сеть на месте не была собственной — это была чужая гостевая или корпоративная Wi-Fi-сеть, к настройкам которой у клиента не было доступа. Кроме того, дисплеи должно было быть возможно удалённо «пробуждать» с помощью Wake-on-LAN — сигнала, который через сеть выводит «спящее» устройство из режима сна — например, чтобы переводить их в энергосберегающий режим вне часов использования и своевременно поднимать перед следующим использованием.

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

1. Отсутствие поддержки WDS. Wireless Distribution System (WDS) — это технология, позволяющая объединить несколько точек доступа в единую прозрачную сеть. Многие гостевые сети вообще не поддерживают её — мост, рассчитанный на WDS, там даже не сможет подключиться к сети.

2. Обязательный 802.1X. 802.1X — это стандарт аутентификации, при котором каждое устройство перед доступом к сети должно подтвердить свою подлинность сертификатом или учётными данными. Корпоративные Wi-Fi-сети часто требуют этого от каждого отдельного участника — препятствие, которое простой мост не преодолевает без дополнительных мер.

3. Ограничения по MAC-адресам. Многие сети допускают лишь ограниченное количество MAC-адресов на одно подключение. Мост, который пытается передавать MAC-адреса всех подключённых устройств без изменений, быстро блокируется.

4. Captive Portal. Captive Portal — это страница входа, которая на многих хотспотах и в гостевых сетях автоматически открывается при первой попытке подключения и открывает настоящий доступ к сети только после подтверждения или входа. Устройство без экрана — например, маршрутизатор или плеер Digital Signage — не может самостоятельно взаимодействовать с этим порталом.

5. Особенности DHCP. DHCP (Dynamic Host Configuration Protocol) — это служба, автоматически назначающая устройствам в сети IP-адрес. Если несколько устройств за мостом должны получить собственный адрес из чужой сети, требуется дополнительная передача DHCP (DHCP-relaying) — в сети с неизвестными правилами файрвола это часто становится бездонной бочкой.

Для клиента это означало: без продуманного решения любое из этих пяти препятствий могло бы полностью остановить проект — и даже если бы мост подключился к сети, удалённое пробуждение дисплеев с помощью Wake-on-LAN представляло бы собой отдельную проблему. Подробнее об этом — в следующем разделе.

Ответом на эти пять препятствий служит NAT-мост на основе клиентского режима из раздела основ выше: маршрутизатор Teltonika серии RUT подключается к гостевой сети в режиме Wi-Fi-клиента — как единое устройство, с одним MAC-адресом и одним IP-адресом. Поддержка WDS не требуется, поскольку прозрачное мостовое соединение не используется. Аутентификацию по 802.1X маршрутизатор проходит сам, от имени всех устройств за ним. Ограничения по MAC-адресам не действуют, поскольку снаружи в любом случае виден только один адрес. Captive Portal при необходимости можно один раз пройти заранее, а периодический повторный вход можно поддерживать с помощью мониторинга и скриптов — при этом мы не даём обещания стопроцентной автоматизации для любого мыслимого типа портала, но предлагаем проверенное решение для конкретной целевой площадки. А передача DHCP (DHCP-relaying) становится ненужной, поскольку устройства за мостом получают свои адреса из собственной LAN-сети, управляемой Ascend, а не из чужой сети.

Остаётся вопрос из практического случая: как удалённо пробудить устройства за таким мостом? Wake-on-LAN (WOL) в своей основе устроен предельно просто — так называемый Magic Packet, специальный широковещательный пакет данных на уровне сети 2, отправляется в локальную сеть и выводит нужное устройство из спящего режима по его MAC-адресу. Проблема в том, что широковещательный пакет не пересекает границы сетей сам по себе — тем более границу NAT моста, и тем более через туннель в интернет. Magic Packet, отправленный удалённо, просто не доходит до устройства за мостом, если никто не вводит его туда целенаправленно.

Именно для этого мы разработали собственные скрипты перенаправления WOL: они принимают команду пробуждения через управляемый Uplink моста и затем целенаправленно отправляют Magic Packet в локальную LAN-сеть за мостом — туда, куда он действительно должен попасть. Так дисплей или терминал на удалённой площадке можно пробудить удалённо без каких-либо действий на месте. Требование со стороны устройства: Wake-on-LAN должен быть включён в BIOS либо на сетевом адаптере (NIC) целевого устройства — это мы проверяем совместно с вами перед внедрением.

Ascend предоставляет всё из одних рук: оборудование (предварительно настроенные маршрутизаторы Teltonika), программное обеспечение (скрипты перенаправления WOL и конфигурацию NAT), консультацию по подходящей настройке для вашей целевой площадки и полную конфигурацию — подготовленную в дата-центре Ascend ещё до того, как устройство вообще увидит место эксплуатации.

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

Проверить профиль Wi-Fi заранее. Сообщите нам, желательно ещё до настройки, какая аутентификация требуется на целевой площадке, есть ли ограничения по MAC-адресам и существует ли Captive Portal. Чем точнее мы знаем целевую сеть, тем надёжнее мост работает с первого дня.

Протестировать Wake-on-LAN перед внедрением. Проверьте на пилотном устройстве, включён ли Wake-on-LAN в BIOS либо на сетевом адаптере, перед тем как одновременно развернуть решение на нескольких площадках.

Использовать мониторинг с самого начала. Мост, который незаметно уходит в офлайн, хуже моста, который изначально не работает — потому что никто не замечает, что его нет. Удалённое управление активно с момента запуска в работу.

Одной линии недостаточно? Если одного подключения не хватает и вы хотите объединить несколько линий в общую пропускную способность, узнайте больше о нашем Multi-WAN Bonding с Viprinet.