Будет ли работать сеть на Zyxel Nebula, если опустят железный занавес?
Выдержит ли Zyxel Nebula блокировки Роскомнадзора? Мы много раз рассматривали систему управления Nebula Control Center от компании Zyxel. Это - облачный сервис, который позволяет через интернет настраивать и мониторить сетевой стек компании, в том числе настраивать Wi-Fi, объединять офисы через VPN и что самое приятное - легко выходить из неприятных ситуаций, когда администратор ошибся в установках LAN и внутренняя сеть заблокировалась. Постоянный доступ ко всем устройствам через WAN, да ещё и в режиме одного окна - это ключевая особенность Nebula Control Center, ради которой пользователи покупают оборудование Zyxel. Особенно удобно настраивать через Nebula какие-то удалённые Edge-узлы, которые оператор может сконфигурировать, не выходя из дома, через мобильное приложение на смартфоне. Но, у этого решения есть один недостаток, который сегодня стал актуален как никогда…
Nebula Control Center - это полностью облачное решение, работающее только через интернет, и в отличии от программных контроллеров TP-Link Omada SDN (см. нашу статью) или Ubiquiti Unifi Controller (см. наше сравнение Zyxel vs Ubiquiti), здесь нет никакого варианта установить управляющий софт на локальный сервер или VDS. Времена свободного интернета, похоже, остались далеко в прошлом, и сегодня железный занавес может в любой момент опуститься, превратив то, что мы называем глобальной сетью, в то,чему дали звонкое имя «Чебурнет» (см.нашу статью о Чебурнете). Что станет с вашей сетью в этом случае, превратятся ли Zyxel-и в «кирпич», и что делать в данном случае, рассмотрим в данном обзоре.
Как и что мы тестировали?
Для тестирования был использован стандартный стек: шлюз доступа Zyxel ATP200 + PoE коммутатор + точка доступа, настроенные через Nebula Control Center. На вышестоящем оборудовании был развёрнут шлюз PFSense, что давало возможность устраивать собственный мини-роскомнадзор со своими блокировками и обходными тоннелями. Снизу, через точку доступа, были подключены обычные клиенты с обычной сетевой жизнью: интернетом, VPN, соцсетями и ютубом.
При тестировании меня интересовало 2 вопроса:
СТОП! Самый важный момент - что будет с моей сетью?
ОК, чтобы протестировать самый жёсткий вариант блокировок, мы опускаем «железный занавес» на PFSense и блокируем шлюзу Zyxel ATP200 доступ к WAN, после чего перегружаем всё оборудование Zyxel.
Сеть продолжает работать - Wi-Fi SSIDы активны, клиенты чувствуют себя как ни в чём не бывало: открываются локальные ресурсы, идут запросы в WAN. Приложение Nebula на смартфоне рапортует о том, что точки доступа, шлюз и коммутатор перешли в режим offline, но раздражающие уведомления можно отключить.
Открываем доступ в WAN, но блокируем запросы к серверам Nebula, после чего перегружаем оборудование. Сеть работает в штатном режиме: клиентам доступны как локальные ресурсы, так и интернет (точнее то, что от него осталось). Управление через приложение или Nebula CC недоступно.
Если вы настраивали 2-факторную аутентификацию по E-Mail или Captive Portal для Wi-Fi, то эти сервисы сыграют с вами злую шутку, не пуская в Wi-Fi, поэтому если есть необходимость в дополнительном подтверждении личности пользователя, рекомендую использовать 2F-Auth через приложение Google на смартфоне (подробнее о настройке 2ФА в Zyxel Nebula читайте в нашей статье).
ИТОГО: даже при отключении доступа к серверам, располагающимся в недружественных странах,
! ! ! СЕТЬ ПРОДОЛЖИТ РАБОТАТЬ ! ! !
У вас будет достаточно времени, чтобы спланировать и осуществить возврат контроля за оборудованием.
А что значит «вернуть себе контроль за сетевым оборудованием»?
Дело в том, что Nebula Control Center при регистрации устройства, полностью перехватывает на себя его управление и даже меняет пароль к WebUI всех устройств. Сам пароль можно найти в разделе «площадки» в интерфейсе Nebula, и я рекомендую вам прямо сейчас, во время прочтения этой статьи, зайти в аккаунт Nebula и скопировать оттуда пароль доступа к устройствам в надёжное место (Nebula -> Площадка -> Общие настройки -> окошко "Конфигурации устройств").
Даже подключившись к Nebula, некоторые устройства, например, коммутаторы, оставляют часть функций в Web-интерфейсе девайса, например, в коммутаторах это называется «гибридный режим», и через WebUI можно настроить VLAN, отключить порты или перегрузить устройство.
Но чтобы полноценно управлять сетевым оборудованием, вам нужно чтобы и вы, и каждая единица оборудования, будь то шлюз, точка доступа или коммутатор, имели возможность «достучаться» до серверов Nebula Control Center. Но есть и хорошие новости: единожды получив конфигурацию сети из Nebula Control Center, устройствам больше не обязательно иметь доступ к этому облаку: конфигурация прописывается локально, и загружается из флэш-памяти девайсов, поэтому работать сеть продолжит, а вот управлять ею или получать статистику уже не выйдет. Правда, вернуть себе контроль за сетевым оборудованием совсем не сложно.
Сложный вариант: настроить через CLI или SNMP
Продвинутые системные администраторы могут подключиться к устройствам через командную строку по SSH или RS-232, или провести настройку через SNMP. Сделать это можно, не удаляя оборудование из Nebula, интерфейс и наборы команд здесь типовые. Другое дело, что не каждому сисадмину легко даётся командная строка.
Почему бы просто не сбросить устройства к заводским установкам?
Если сбросить устройство, подключенное в Nebula Control Center в заводские установки, отключив ему доступ к серверам Nebula, то оно загрузится в автономном режиме и продолжит в нём работать, пока не достучится до «облака». В этом случае оно скачает на себя конфигурацию и снова перейдёт под управление «Небулы». Так вот, эту возможность можно использовать, чтобы безболезненно перевести вашу сеть в автономный режим.
Для коммутаторов алгоритм простой: нужно либо нажать скрытую кнопку скрепкой, либо же зайти в Web-интерфейс, используя пароль из аккаунта Nebula (надеюсь, когда вы читаете эти строки, вы его уже скопировали, как я рекомендовал выше) и во вкладке Maintance / Обслуживание нажать «Factory Default». После перезагрузки опять зайти в WebUI, используя пару admin/1234 и в настройках Cloud Management снять флажок Discovery с пункта Nebula.
Чтобы не лазить по стенам и потолкам для аппаратного сброса точек доступа, достаточно зайти на каждую из них через SSH с тем паролем, что вы, надеюсь, наконец-то сохранили у себя в надёжном месте и выполнить команду:
apply /conf/system-default.conf
Либо же эту:
copy /conf/system-default.conf /conf/startup-config.conf
После чего даём команду на перезагрузку:
reboot
Затем аналогично заходим в web-интерфейс точки доступа (адрес настраивается автоматически через DHCP) и прямо на первой странице отключаем флажок Discovery в окошке Nebula Control Center.
Всё! Теперь устройства - ваши! Никто у вас ничего не заберёт, не перехватит и не заблокирует управление!
А можно попросить друга из-за границы зайти в мой аккаунт Nebula и удалить конфигурацию?
Да, можно, но это имеет смысл делать, если вы уже прошли прошлый шаг и сбросили девайсы в настройки по-умолчанию.
А как быть с облачными коммутаторами, не имеющими локального управления?
Да,у Zyxel есть линейка оборудования, которое вообще не имеет автономного режима работы, а управляется исключительно через облако. Например, это коммутаторы серии NSW, которые пока что не получили широкого распространения. Для них лучше всего использовать VPN или прокси.
То есть можно подключиться через Proxy?
К счастью, в корпоративном мире частенько клиенты располагаются за прокси, поэтому в настройках каждой точки доступа, каждого коммутатора, каждого шлюза, есть возможность прописать прокси-сервер для доступа к Nebula СС, и возможно, это окажется спасительным вариантом, хотя попытки обхода блокировок через прокси эффективно пресекались ещё в 2021 году.
А ещё прокси может помочь в том случае, когда вы не можете направить управляющий трафик к Nebula через VPN, например в случаях, когда устройство непосредственно подключено к сети провайдера без маршрутизатора. В данном случае вам нужно указать в его настройках просто адрес Proxy во внутренней сети вашего VPN соединения, предварительно настроив для этих целей Squid на шлюзе VPS провайдера.
Будет ли работать Nebula через VPN?
Пожалуй, это самый «экологический вариант». Механика здесь достаточно прозаичная: покупается 2-долларовый VPS в «дружественной» юрисдикции, где настраивается VPN-шлюз, и весь Nebula-трафик направляется через него. Здесь есть небольшая сложность: над коммутаторами и точками доступа нужно иметь хороший роутер, способный направить определённый трафик в VPN, и сегодня эта функция есть даже в домашних Keenetic-ах, не говоря уже о бизнес-моделях.
Что интересно, при подключении через VPN (в нашем случае - парижский), оборудование продолжает правильно определять локальный публичный (в нашем случае - московский) IP адрес, так что какие-то настройки, завязанные на IP соединения WAN, не слетят.
В принципе, хороший добрый VPN, да ещё и обёрнутый в Stunnel, может спасать вас годами, поддерживая управление сетью боеспособном состоянии. Но я всё же не рекомендую пытаться обходить блокировки через VPN+Stunnel на 443 порту, который «пробивается» даже через «Великий Китайский Firewall» и не подвластен никакому анализу DPI. Нет, не рекомендую, да как я могу? Вы что? Мы же - законопослушные граждане!
ИТОГО: как и в случае с доступом к запрещённым сайтам, VPN - это спасение, потому что
! ! ! NEBULA РАБОТАЕТ ЧЕРЕЗ VPN ! ! !
при этом, она корректно определяет внешний IP и прописывает маршруты на локальные шлюзы.
Почему Zyxel не откроет зеркало Nebula в России?
Я могу лишь предполагать, что здесь имеют место репутационные риски: в то время, как крупные компании, так называемые А-Бренды, горделиво заявляют, что покидают рынок России, громко хлопая дверью и закрывая офисы, но продолжая поставлять своё оборудование контрабандой, никто в здравом уме не будет вкладывать силы и средства, чтобы делать локальное облако для страны, которая сама себя закрывает от внешнего мира. Риски, связанные с государственным управлением, на этой территории как никогда высоки, и брать их на себя не целесообразно ни по экономическим причинам, ни по каким-то другим.
На позитивной ноте
Как видите, проблема переоценена. Сам по себе риск блокировки сервиса Nebula ничтожен: сегодня уже никто не блокирует неугодные ресурсы по IP адресам, используя вместо этого анализ DNS запросов с подменой ответа от сервера. И даже в случае, если железный занавес опустится, отрезая Россию от глобальной сети, ваша локальная сеть продолжит работать: отчёты - отправляться, письма - приниматься, вконтактик - открываться. В общем хаосе у вас будет достаточно времени, чтобы отвязать устройства от облака и перенастроить под свои задачи, и если есть настроение - можете начать это делать заранее. Если вы заранее скопировали пароль из контрольной панели Nebula (больше напоминать не буду!), то скорее всего вам даже не придётся лезть к устройствам со скрепкой, откручивая точку доступа с потолка.
Нужно ли сейчас разворачивать новые проекты на Nebula или стоит делать это в автономном режиме?
Nebula очень сильно упрощает настройку Wi-Fi и функций, связанных с безопасностью и мониторингом сети. Учитывая, что в базовом варианте весь этот функционал предлагается совершенно бесплатно, я не вижу причин отказываться от этих возможностей. Я считаю, что в случае, если всё же железный занавес опустится, отключение облака будет наименьшей из проблем, свалившихся на IT организацию. В случае, если вы обслуживаете сети на outsource основе, эти риски и вовсе можно переложить на клиента или причислить к форс-мажору.
Однако, стоит учитывать, что Nebula Control Center - это не панацея, и как только вам потребуется глубокая настройка сети (L3 на коммутаторах, L7 на шлюзах), вам придётся переводить устройства в автономный режим и настраивать по-старинке, через WebUI или CLI (о том, что умеют NGFW от Zyxel читайте в нашем обзоре). Поэтому я бы советовал вам исходить в этом вопросе из потребностей вашего клиента, вашей организации и вашей сети, а не наводить панику вида "ой, Небулу отключат".
Михаил Дегтярёв (aka LIKE OFF)
16/02.2023
