В статье пойдет речь о проблемах организации сетевой инфраструктуры традиционным способом и о методах решения тех же самых вопросов при помощи облачных технологий.
Для справки. Nebula — облачная среда SaaS для удаленного поддержания сетевой инфраструктуры. Все устройства, поддерживающие Nebula, управляются из облака через безопасное соединение. Можно управлять крупной распределенной сетевой инфраструктурой из единого центра, не затратив усилия по его созданию.
Для чего нужен очередной облачный сервис?
Основная проблема при работе с сетевой инфраструктурой — это не проектирование сети и закупка оборудования, и даже не монтаж в стойку, а все то остальное, что с этой сетью в дальнейшем предстоит делать.
Сеть новая — заботы старые
При вводе в эксплуатацию нового узла сети после монтажа и подключения оборудования начинается первоначальная настройка. С точки зрения «большого начальства» — ничего сложного: «Берем рабочую документацию по проекту и начинаем настраивать…» Это так здорово говорится, когда все сетевые элементы стоят в одном ЦОД. Если же они разбросаны по филиалам, начинается головная боль с обеспечением удаленного доступа. Такой вот замкнутый круг: чтобы получить удаленный доступ по сети, нужно настроить сетевое оборудование, а для этого нужен доступ по сети…
Приходится придумывать различные схемы для выхода из вышеописанного тупика. Например, ноутбук с доступом в Интернет через USB 4G модем подключается через патчкорд к настраиваемой сети. На этом ноутбуке поднимается VPN клиент, и через него сетевой администратор из штаб-квартиры пытается получить доступ к сети филиала. Схема не самая прозрачная — даже если привезти ноутбук с заранее настроенным VPN на удаленную площадку и попросить его включить, далеко не факт что всё заработает с первого раза. Особенно если речь о другом регионе с другим провайдером.
Получается, самый надежный способ — держать «на другом конце провода» хорошего специалиста, который сможет настроить свою часть согласно проекту. Если такого в штате филиала не имеется, остаются варианты: либо аутсорсинг, либо командировка.
Ещё нужна система мониторинга. Её требуется установить, настроить, обслуживать (хотя бы следить за местом на диске, и регулярно делать резервные копии). И которая ничего не знает о наших устройствах, пока мы ей не сообщим. Для этого нужно прописать настройки для всех единиц оборудования и регулярно следить за актуальностью записей.
Замечательно, когда в штате есть свой «человек-оркестр», который, помимо специфических знаний сетевого администратора, умеет работать с Zabbix или с другой аналогичной системой. В противном случае берем ещё одного человека в штат или отдаем на аутсорсинг.
Примечание. Самые печальные проколы начинаются со слов: «Да что там этот Zabbix (Nagios,OpenView и т.д.) настраивать? Я сейчас вот его быстренько подниму и готово!»
От внедрения к эксплуатации
Рассмотрим конкретный пример.
Получено тревожное сообщение о том, что где-то не отвечает точка доступа WiFi.
Где она находится?
Разумеется, у хорошего сетевого администратора есть свой личный справочник, в котором всё записано. Вопросы начинаются, когда этой информацией нужно делиться. Например, надо срочно послать гонца, чтобы разобраться на месте, а для этого нужно выдать что-то вроде: «Точка доступа в бизнес-центре на улице Строителей, дом 1, на 3-м этаже, кабинет N 301 рядом с входной дверью под потолком».
Допустим, нам повезло и точка доступа питается через PoE, а коммутатор позволяет её перезагрузить удаленно. Ехать не надо, но нужен удаленный доступ до коммутатора. Остается настроить проброс портов через PAT на маршрутизаторе, разобраться с VLAN для подключения извне и так далее. Хорошо, если все настроено заранее. Работа, может, и не сложная, но делать нужно.
Итак, точку по питанию перезагрузили. Не помогло?
Допустим, что-то не так в аппаратной части. Теперь ищем информацию о гарантии, начале эксплуатации и других интересующих деталях.
Кстати о WiFi. Использование домашнего варианта WPA2-PSK, в котором один ключ на все устройства — в корпоративной среде не рекомендуется. Во-первых, один ключ на всех — это попросту небезопасно, во-вторых, когда один сотрудник увольняется, то приходится менять этот общий ключ и заново выполнять настройки на всех устройствах у всех пользователей. Чтобы избежать подобных неприятностей, существует WPA2-Enterprise с индивидуальной аутентификацией для каждого пользователя. Но для этого нужен RADIUS сервер — ещё одна инфраструктурная единица, которую надо контролировать, делать резервные копии и так далее.
Обратите внимание, на каждом этапе, будь то внедрение или эксплуатация, мы пользовались вспомогательными системами. Это и ноутбук со «сторонним» выходом в Интернет, и система мониторинга, и справочная база по оборудованию, и RADIUS как система аутентификации. Помимо сетевых устройств, приходится обслуживать ещё и сторонние сервисы.
В таких случаях можно услышать совет: «Отдать в облако и не мучиться». Наверняка есть облачный Zabbix, возможно где-то есть облачный RADIUS, и даже облачная база данных, чтобы вести список устройств. Беда в том, что это нужно не порознь, а «в одном флаконе». И всё равно встают вопросы организации доступа, первоначальной настройки устройств, безопасности и многое другое.
Как это выглядит при использовании Nebula?
Разумеется, первоначально «облако» ничего не знает ни о наших планах, ни о приобретенном оборудовании.
Сперва создается профиль организации. То есть вся инфраструктура: штаб-квартира и филиалы вначале прописывается в облаке. Указываются реквизиты, создаются учетные записи для делегирования полномочий.
Зарегистрировать используемые устройства в облаке можно двумя способами: по старинке — просто вписав серийник при заполнении веб-формы или отсканировав QR-код при помощи мобильного телефона. Всё что нужно для второго способа — смартфон с камерой и доступом в Интернет, в том числе через мобильного провайдера.
Разумеется, необходимую инфраструктуру для хранения информации, как учетной, так и настроек предоставляет Zyxel Nebula.
Рисунок 1. Отчет безопасности Nebula Control Center.
А что с настройкой доступа? Открытием портов, пробросом трафика через входящий шлюз, всем тем, что администраторы безопасности ласково называют: «наковырять дырок»? К счастью, этого всего делать не нужно. Устройства под управлением Nebula устанавливают исходящее соединение. И администратор для настройки подключается не к отдельному устройству, а к облаку. Nebula выступает посредником между двумя соединениями: с устройством и с компьютером сетевого администратора. Это означает, что этап с вызовом приходящего админа можно свести к минимуму, либо пропустить вовсе. И никаких дополнительных «дырок» на файрволе.
А как же RADUIS сервер? Ведь нужна какая-то централизованная аутентификация!
И эти функцию тоже берет на себя Nеbula. Аутентификации учетных записей для доступа к оборудования идет через защищенную базу данных. Это сильно упрощает делегирование или изъятие прав по управлению системой. Нужно передать права — заводим пользователя, назначаем роль. Нужно отобрать права — выполняем обратные действия.
Отдельно стоит сказать о WPA2-Enterprise, для которого нужен отдельный сервис аутентификации. У Zyxel Nebula есть собственный аналог — DPPSK, который позволяет использовать WPA2-PSK с индивидуальным ключом для каждого пользователя.
«Неудобные» вопросы
Ниже попробуем дать ответы на наиболее каверзные вопросы, которые часто задают при вхождении в облачный сервис
А это точно безопасно?
При любом делегировании контроля и управления для обеспечения безопасности важную роль играют два фактора: анонимизация и шифрование.
Использование шифрования для защиты трафика от посторонних глаз — это читателям более или менее знакомо.
Анонимизация скрывает от персонала облачного провайдера информацию о владельце и источнике. Персональная информация удаляется, а записям присваивается «безликий» идентификатор. Ни разработчик облачного ПО, ни администратор, обслуживающий облачную систему — не могут знать владельца запросов. «Откуда это пришло? Кого это может заинтересовать?», — такие вопросы останутся без ответа. Отсутствие данных о владельце и источнике делает инсайдинг бессмысленной тратой времени.
Если сравнивать данный подход с традиционной практикой передачи на аутсорсинг или найма приходящего админа — очевидно, что облачные технологии безопаснее. Приходящий ИТ специалист знает о своей подопечной организации достаточно много, и может волей или неволей нанести существенный вред в плане безопасности. Ещё надо решить вопрос увольнения или завершения договора. Иногда, помимо блокировки или удаления учетной записи, это влечет глобальную смену паролей для доступа к сервисам, а также аудит всех ресурсов на предмет «забытых» точек входа и возможных «закладок».
Насколько Nebula дороже или дешевле приходящего админа?
Всё познается в сравнении. Базовые функции Nebula доступны бесплатно. Собственно, что может быть ещё дешевле?
Разумеется, совершенно обойтись без сетевого администратора или лица, его заменяющего не получится. Вопрос в количестве людей, их специализации и распределении по площадкам.
Что же касается платного расширенного сервиса, то ставить прямой вопрос: дороже или дешевле — такой подход всегда будет неточным и однобоким. Правильнее будет сравнить множество факторов, начиная от денег на оплату работы конкретных специалистов и заканчивая затратами по обеспечению их взаимодействия с подрядной организацией или физлицом: контроль качества выполнения, составление документации, поддержание уровня безопасности и так далее.
Если же говорить на тему выгодно или не выгодно приобретать платный пакет услуг (Pro-Pack), то примерный ответ может звучать так: если организация маленькая, можно обойтись базовой версией, если организация растет, то имеет смысл подумать о Pro-Pack. Различие между версиями Zyxel Nebula можно посмотреть в таблице 1.
Таблица 1. Различия наборов функций базовой версии и версии Pro-Pack для Nebula.
Это и расширенная отчетность, и аудит пользователей, и клонирование конфигурации, и многое другое.
А что с защитой трафика?
Nebula использует протокол для обеспечения безопасности работы с сетевым оборудованием.
NETCONF может работать поверх нескольких транспортных протоколов:
- ();
- ();
- ();
- ().
Если сравнивать NETCONF с другими методами, например, управление через SNMP — следует отметить, что NETCONF поддерживает исходящее TCP-соединение для преодоления барьера NAT и считается более надежным.
Что с поддержкой оборудования?
Разумеется, не стоит превращать серверную в зоопарк с представителями редких и вымирающих видов оборудования. Крайне желательно, чтобы оборудование, объединенное технологией управления, закрывало все направления: от центрального коммутатора до точек доступа. Инженеры Zyxel позаботились о такой возможности. Под управлением Nebula работает множество устройств:
- центральные коммутаторы 10G;
- коммутаторы уровня доступа;
- коммутаторы с PoE;
- точки доступа;
- сетевые шлюзы.
Используя широкий спектр поддерживаемых устройств можно строить сети под различные типы задач. Особенно это актуально для компаний, которые растут не вверх, а вширь, постоянно осваивая новые площадки для ведения бизнеса.
Постоянное развитие
Сетевые устройства с традиционным методом управления имеют только один путь совершенствования — изменение самого устройства, будь то новая прошивка или дополнительные модули. В случае с Zyxel Nebula есть дополнительный путь для улучшений — через совершенствование облачной инфраструктуры. Например, после обновления Nebula Control Center (NCC) до версии 10.1. (21 сентября 2020) пользователям доступны новые возможности, вот некоторые из них:
- владелец организации теперь может передать все права владения другому администратору в той же организации;
- новая роль под названием «Представитель владельца», которая имеет те же права, что и владелец организации;
- новая функция обновления прошивки в масштабах всей организации (функция Pro-Pack);
- в топологию добавлены две новые опции: перезагрузка устройства и включение и выключение питания порта PoE (функция Pro-Pack);
- поддержка новых моделей точек доступа: WAC500, WAC500H, WAC5302D-Sv2 и NWA1123ACv3;
- поддержка аутентификации по ваучерам с печатью QR-кодов (функция Pro-Pack).
Полезные ссылки
Источник: habr.com