Важное уведомление: |
В этой статье мы рассмотрим наиболее распространенные проблемы - если устройство не работает в автономном режиме, не отображаются данные/журналы (PoE, использование процессора, использование данных, журналы и т.д.), не происходит подкачка конфигураций (управление прошивкой), используются журналы событий.
Мы очень рады, что наше облачное решение Nebula набирает обороты на местах и становится все более и более ключевым направлением в расширении нашего портфеля. То, что начиналось как "побочное" решение, стало, в соответствии с нашими инвестициями и прогнозами, краеугольным камнем наших операций и продуктов. Однако в результате такого смещения акцентов оборудование с поддержкой Nebula все чаще используется в профессиональных сетевых средах. В связи с этим у многих наших заказчиков возникает вопрос: "Что я могу сделать для анализа своих проблем, прежде чем обращаться к кому-то еще?"
В данном руководстве представлены некоторые идеи и рекомендации по проверке устройств в случае их некорректной работы - некоторые из них носят общий характер (= примеры лучших практик), некоторые из них более специфичны для различных технологических областей.
В качестве предварительного материала мы уже подготовили руководство по доступу к межсетевым экранам с поддержкой Nebula через SSH, которое в сочетании со справочными руководствами по CLI может помочь вам получить некоторое представление о различных возможностях проверки при подключении через SSH к соответствующим устройствам Nebula:
Доступ к брандмауэру Nebula через SSH и захват пакетов / трассировка пакетов из Интернета
Примечание: Управляемые устройства Nebula не предназначены для конфигурирования в любой форме через консольное соединение - пожалуйста, используйте доступ по SSH к устройствам Nebula только для мониторинга и, возможно, в сотрудничестве с нашим отделом поддержки и разработок, для отладочных измерений.
Устройства остаются в автономном режиме
Представьте себе, что вы успешно зарегистрировали свое устройство, возможно, даже сконфигурировали некоторые настройки по своему вкусу и теперь находитесь на этапе развертывания устройства. Однако по неизвестным пока причинам устройство, о котором идет речь, просто-напросто не хочет выходить в сеть как на месте, работать, так и полностью показывать, что оно в сети и реагирует на запросы.
Это одна из наиболее распространенных проблем при развертывании устройств Nebula - причина ее, если говорить кратко, заключается в том, что устройства по умолчанию пытаются разрешиться либо на s.nebula.zyxel.com, либо на d.nebula.zyxel.com. Это связано с двумя проблемами:
- Многократно каскадированный поддомен (например, this.that.andthis.alsothis.domain.com) может привести к проблемам у некоторых DNS-провайдеров.
- Согласно новым стандартам, поддомен может состоять и из одного символа, тогда как раньше он состоял минимум из трех символов. Некоторые DNS-серверы испытывают с этим проблемы.
Очень часто мы наблюдаем проблемы с DNS-серверами интернет-провайдеров. Наша рекомендация: измените DNS-сервер по умолчанию на 8.8.8.8 или 1.1.1.1. Более подробную информацию можно найти здесь:
Я не вижу никаких данных!
Иногда клиенты обращаются к нам с жалобами на то, что они впервые вошли в систему после длительного перерыва, а их данные либо исчезли, либо "ничего не отображается". Возможно, из-за длительного бездействия на портале организация перешла в режим экономии облака, который отключает сбор информации после 30 дней простоя. О переходе в режим Cloud-Saving Mode должно сигнализировать соответствующее сообщение и баннер (светло-голубой баннер). Решение: отключите режим экономии облачных данных и подождите несколько минут, после чего данные должны восстановиться.
Более подробную информацию можно найти здесь: Режим экономии облаков (Nebula BASE Pack)
Конфигурации не загружаются
Возможно, у вас возникла проблема, когда устройство действительно отображается в сети, но изменение конфигурации не происходит? Проверьте прошивку! Для корректной работы некоторых изменений может потребоваться последняя версия микропрограммы, и иногда изменения задерживаются из-за этого:
Это идеальный пример того, что мы не хотели бы видеть - в данном случае прошивка брандмауэра устарела, и это сдерживает применение новых блоков конфигурации, в то время как все остальные показатели (процессор, использование оперативной памяти, номер клиента, состояние online/offline) выглядят нормально. Особенно, но не исключительно, это касается новых функций, реализованных в последних прошивках. Так что, помимо представленной выше "DNS-проблемы", это может быть ценным советом.
Мониторинг через Nebula - полезные сведения под рукой!
Функции мониторинга предоставляют реальные преимущества и инструменты для ваших средств мониторинга и аналитики. Начнем с самого простого - устройство отображается как нерабочее, но у вас есть ощущение, что оно продолжает нормально взаимодействовать с облачным центром Nebula? Просто перейдите на главную страницу устройства - для шлюзов это будет:
Devices -> Firewall
и выполните Ping-тест - если в ходе ping-теста удастся успешно передать устройству команду "Ping destination W.X.Y.Z" и устройство действительно получит ее и сможет выдать сообщение об успешном пинге, это означает, что устройство действительно продолжает взаимодействовать с NCC, а состояние offline может быть связано с кэшем браузера или куками.
Другой пример из реальной жизни: на нескольких портах коммутатора постоянно появляются сообщения журнала событий, указывающие на переключение между соединениями 10 Мбит/с и 1 Гбит/с, и вы не уверены, что причиной проблем является коммутатор?
Проверьте таблицу MAC-адресов через:
Devices > Switches > (select Switch) > Live Tools > Switch Tables > Run-Button
Вы знаете информацию, которая может вам помочь - в реальном примере оказалось, что все порты коммутатора, демонстрирующие такое поведение, имеют очень специфического производителя MAC, что, в свою очередь, указывает скорее на то, что данная проблема есть у определенного типа клиента, а значит, у коммутатора ее нет - возможным решением здесь может быть настройка фиксированной скорости на указанных клиентах и соответствующих портах коммутатора.
Можно привести еще много примеров того, как мониторинг может творить чудеса для устранения ошибок, но, думаю, суть вы поняли.
Использование журналов событий для лучшего понимания процессов "под капотом"
Журналы событий, которые в каждой технологической области свои, оказывают огромную помощь в информировании о причинах неработоспособности - особенно в вопросах, связанных с WiFi.
Рассмотрим один пример на примере сети WiFi, в котором показаны три различные записи:
Давайте последовательно проанализируем эти три различные точки:
- Это говорит нам о том, что определенная станция с определенным MAC-адресом подключилась к соответствующей точке доступа. Она подключилась с уровнем сигнала -81dBm, что, в конечном счете, слишком слабо (для справки посмотрите это руководство: Улучшение роуминга WiFi на моих точках доступа Nebula? )
- Станция покинула определенный SSID, точку доступа, канал по WiFi причине 3. Коды причин WiFi - это унифицированные коды для идентификации и понимания поведения WiFi. Для справки, пожалуйста, ознакомьтесь с этой статьей: Каково значение кодов причин деаутентификации 802.11?
Код причины WiFi 3 просто говорит о том, что станция проактивно решила покинуть SSID. - Имел место процесс роуминга (= перемещения от одной точки доступа к другой) определенного клиента.
Конечно, это лишь поверхностный взгляд на то, что могут рассказать журналы событий, но он показывает, что журналы событий могут быть мощным инструментом для понимания того, что на самом деле происходит с вашей сетью. Если говорить конкретно о проблемах WiFi, то существуют дополнительные инструменты для оценки качества WiFi, такие как Wireless Health, Client lists и т.д. Следующие статьи могут дать вам больше информации по этой теме: