Облачные технологии

Предсказывать будущее дело неблагодарное: говорят, в этом преуспел разве что Нострадамус да одна слепая болгарская старушка. Вместе с тем, некоторые тенденции развития IT-технологий явно намекают нам на то, что уже в ближайшей перспективе вычислительные мощности и возможности девайсов будут расти, а сами эти устройства становиться проще и дешеветь. Как такое возможно? Ответ прост: облака.

Облачный софт

Когда в октябре 2006 года корпорация Google анонсировала запуск сервиса Google Docs, а спустя пять лет к ним подтянулась Microsoft со своим Office 365 по подписке, лично я воспринял появление этих новинок с некоторым скепсисом. С одной стороны, подобная модель SAAS позволяет избавиться от необходимости устанавливать софт на свой компьютер, экономя тем самым дисковое пространство. Да и самим софтом можно пользоваться на любой, даже довольно слабой машине, с любой архитектурой и операционной системой для работы с Документами от Google вообще требуется только браузер. С другой стороны, устройство должно иметь стабильное соединение с интернетом, причем на приличной скорости, что и стало основной причиной моих сомнений. У нас тут всё-таки не Сингапур, и если в обеих столицах с доступом к сети все более-менее в порядке, то стоит отъехать от кольцевой автодороги на сотню километров В общем, вы поняли.

Однако за минувшее десятилетие широкая поступь технического прогресса добралась до весьма отдалённых уголков нашей необъятной страны. Даже в деревне, где мы с семьёй проводим лето, и где еще пару лет назад можно было проверить почту, лишь забравшись с мобильником на самую высокую березу, сейчас вполне уверенно принимается сигнал 3G. В заграничных поездках жизнь тоже стала потихоньку налаживаться: бесплатный wi-fi для постояльцев теперь можно найти даже в паршивых трех звездах, пусть только на ресепшен, но тем не менее. Да и сами сервисы активно развиваются: те же гугловские Таблицы давным-давно научились работать с формулами, и, хотя пока еще уступают по своим возможностям Excel, скоро наверняка догонят средств у разработчика для этого вполне достаточно. Скорее всего, даже опередят. Ко всему прочему, именно облачность Таблиц позволяет использовать их в качестве базы данных для интернет-магазина, бекэнда для веб-приложений, и даже в целях фишинга.

Еще один интересный проект, с которым я познакомился некоторое время назад это новая мелодия на мотив Chromium OS под названием Cloud Ready. Операционка, представляющая собой по большому счету ядро Linux с браузером, а для всего остального функционала использующая облачные сервисы, позволила изрядно взбодрить один из моих старых ноутбуков, который с трудом тянул даже Xubuntu. Быстрая загрузка, вполне современный графический интерфейс, минимально необходимый набор софта (включающий те же самые Документы Google) и довольно шустрая работа на древнем, как бивень мамонта, железе что еще нужно для просмотра котиков в интернете и работы с текстами?



Не знаю, как у вас, а лично у меня уже почти не осталось сомнений в том, что очень скоро большинство приложений и игрушек окончательно мигрируют в облака. Во-первых, это снизит расходы на железо, поскольку с облачным софтом можно довольно уверенно работать почти на любом устройстве, включая планшеты и смартфоны, под которые далеко не всегда можно подобрать адекватные офисные приложения. Во-вторых это простота переноса пользовательских данных. Меня до сих пор поражает, насколько эффективно эту проблему решила Apple в iOS, в сравнении с тем же Android, где мне приходилось изрядно помучиться, чтобы перетащить информацию со старого телефона на новый. Думаю, недалек тот момент, когда и в прочих операционках после первого запуска и входа в аккаунт все пользовательские файлы, установленные программы, драйверы, почта, фотки, сохраненные игры и переписка в мессенджерах будут подтягиваться автоматически разработчики Windows 10 уже сейчас пытаются это реализовать с помощью учетной записи Microsoft в сочетании с OneDrive. Работает, правда, пока еще кривовато, но вектор в целом понятен.

Интернет вещей

Но больше всего перспектив у облачных технологий, пожалуй, в мире интернета вещей и микрокомпьютеров. Еще недавно (да ладно, прямо сейчас) арсенал возможностей контроллеров и одноплатников во многом ограничивался аппаратной конфигурацией. Архитектура и частота процессора, объем оперативной памяти именно от этого в первую очередь зависит, какой софт можно запустить на таком девайсе, какой объем данных он сможет обработать, и к чему его, следовательно, можно приспособить. Ведь так? Забудьте.

Выше мы говорили о модели SaaS софт как услуга, но существуют еще две категории облачных решений: платформа как услуга (PaaS), и инфраструктура как услуга (IaaS), когда клиенту предоставляется все необходимое для разработки и запуска собственных решений на разном уровне. Именно развитие подобных сервисов, думается, и позволит в не столь уж отдаленном будущем полностью перенести бекэнд IoT-приложений в облака, оставив на самом устройстве только необходимый минимум софта не требовательного к аппаратным ресурсам и способного запускаться на очень слабом дешевом железе. Примерно так, например, сейчас работают многие IP-камеры: само устройство только создает и передает по сети картинку, а все настройки девайса, да и собственно видео доступны на удаленном облачном сервере. Такой подход позволит сделать большинство IoT-приложений кроссплатформенными и практически полностью решить проблемы, связанные с поддержкой разных аппаратных конфигураций и разных протоколов, а также объединить различные устройства и датчики с универсальными мобильными приложениями то есть, строить сложные гетерогенные сети, не беспокоясь о поддержке их отдельных компонентов. Кроме того, облачные архитектуры легко масштабируемы. Примечательно, что подобные решения существуют уже сейчас, просто на данном этапе они пока еще не обрели популярность, достаточную для конкуренции с более успешными коммерческими проектами.


Помимо уже привычных систем умный дом распределенные архитектуры с облачным бекэндом могут успешно применяться в телемедицине и дистанционной диагностике, в интеллектуальных промышленных приложениях, связанных с эксплуатацией производственного оборудования, в логистике, в управлении транспортом, в розничной торговле, в инфраструктуре мониторинга окружающей среды и измерительных приборов Да много где.

Большинство решений из мира IoT, включая пресловутый умный дом, требуют анализа больших массивов информации, в том числе, исторических данных, а также предполагают выявление закономерностей для построения сценариев поведения оборудования в будущем. С помощью облачных вычислений можно заметно разгрузить оборудование на стороне пользователя. Извлечение полезной информации из сложных потоковых данных, таких как видео, еще один пример анализа, требующего большого объема обработки. И эти объемы со временем будут только расти. Растет потребность в обработке данных из различных источников в разных сочетаниях, требуется проводить их сравнительный и эвристический анализ. Нельзя забывать, что системы IoT это системы реального времени, в которых поток информации поступает из множества источников непрерывно, и для управления этими потоками необходимы соответствующие ресурсы. Нужно оперативно отсеивать недостоверную информацию, поступающую от неисправных датчиков, поскольку такие данные могут привести в конечном итоге к повреждению оборудования или нанести вред пользователю. Кроме того, всю эту бигдату нужно где-то хранить. Облака тут являются фактически безальтернативным решением, но оно, конечно, имеет и собственный набор узких мест.

Проблемы и решения

Одним из существенных препятствий на пути переноса всех ресурсоемких задач по обработке данных в облака является необходимость изначально строить серверные приложения с прицелом на облачную инфраструктуру. Если в качестве источника данных выступает гетерогенная сеть с большим арсеналом совершенно разных устройств, конструкция бекэнда может приобрести поистине монструозные формы.

Очевидным решением тут является переход от монолита к микросервисной архитектуре. Использование микросервисов гарантирует масштабируемость, гибкость, а также возможность модификации под новые задачи и обновления серверных решений без необходимости полностью останавливать процесс обработки данных. Собственно, сегодня уже мало кто сомневается, что управляемые микросервисы это перспективная технология, позволяющая справиться с наиболее сложными задачами в мире больших данных.



Второй проблемой переноса обработки данных в облако может стать, как ни странно, связанность. Какие-либо проблемы на уровне публичных или магистральных сетей способны привести к сбоям в передаче информации между конечными устройствами и облачным сервером. Еще несколько лет назад блокировки отдельных ресурсов провайдерами по требованию российских контролирующих органов приводили к периодическим проблемам при обращении к сервисам Amazon Cloud и Microsoft Azure. И застраховаться от подобных явлений, увы, очень сложно. Одно из очевидных решений резервирование каналов связи и использование сторонних NS-служб не может служить стопроцентной гарантией, что система будет работать без сбоев.

Сейчас в дополнение к облачным технологиям понемногу развивается концепция так называемых туманных вычислений (Fog Computing), которые считаются более эффективными при обработке данных в реальном времени. Это действительно очень важно, поскольку, согласно прогнозам IDC, к 2024 году количество конечных устройств в сетях IoT достигнет по всему миру 41,6 миллиарда, а совокупный объем генерируемого ими трафика составит 79,4 зеттабайт. Однако одними только вычислительными мощностями, потребными для обработки таких массивов данных, сложности облачного интернета вещей не ограничиваются.

Вопросы безопасности

Что такое Shodan, знают, наверное, все. Подобных сервисов, предназначенных для поиска подключенных к интернету умных устройств, сейчас развелось уже довольно много и хакеры активно используют их в своих интересах. Поэтому промежуточное звено между конечными устройствами интернета вещей и облачным центром обработки данных в виде публичных сетей может стать той самой ахиллесовой пятой, которая поставит под угрозу безопасность всей инфраструктуры. Шифрование тут может рассматриваться, как действенное рабочее решение, но вряд ли станет панацеей.



Хранение критических данных в облаке тоже вряд ли вызовет энтузиазм у поборников безопасности сообщения о взломах облачных сервисов мы читаем с завидной регулярностью. Как бы ни старались вендоры защитить виртуальные серверы и хранилища от различных видов атак, в любом софте рано или поздно может отыскаться критическая уязвимость, ведущая к компрометации. Да и защитить пользователя от себя самого вряд ли возможно.

И здесь мы приходим еще к одному важному обстоятельству, о котором нельзя не упомянуть в контексте интернета вещей: причиной множества успешных взломов, да и появления поисковиков вроде пресловутого Shodan, являются ошибки в конфигурации. Некоторые пользователи умных девайсов банально не утруждают себя сменой дефолтных настроек и пароля по умолчанию, из-за чего доступ к ним может получить любой желающий. Не говоря уже о более тонких материях вроде открытых портов, отключения двухфакторной аутентификации или отказа от использования VPN там, где это необходимо. Иными словами, инженер по облачной безопасности это, вероятно, еще одна профессия, актуальность которой в ближайшей перспективе будет только расти.

И что потом?

Миграция сервисов в облака это неизбежный и неотвратимый процесс, но вместе с тем, не стоит рассматривать его, как конечную точку на маршруте технического прогресса. Перенос технологии в облако и переход к микросервисным архитектурам не приводит к автоматическому повышению производительности, росту общей эффективности или прибыли. Это прекрасный инструмент для оптимизации технологии, но не более того.

Если же вернуться к вопросу миграции в облака приложений, с которого я начал эту статью, то в условиях пандемии и национальных локдаунов, когда бизнес стремится к децентрализации, а рабочие места все чаще и чаще становятся удаленными, это стало актуальным, как никогда ранее. Думается, ориентация на облачные технологии во многом изменит сами подходы в разработке прикладного софта и рынок ПО в пользу модели SaaS с постепенным отходом от традиционных схем дистрибуции.

По данным crn.com, в 2021 году оборот глобального рынка облачных сервисов достиг отметки в 120 миллиардов долларов и продолжает уверенно расти. А по прогнозам аналитиков в следующем году рынок общедоступной облачной инфраструктуры расширится еще на 28 процентов. Данный сегмент технологий сейчас можно назвать одним из самых быстрорастущих, а значит, в ближайшем будущем мы сможем наблюдать переход в облака все большего и большего числа сервисов игровых, софтверных, коммуникационных и прочих. Таково наше будущее. И с этим ничего не поделать.

Так устроена наша компания, что она не может не развиваться. В прошлом году ABBYY приобрела TimelinePI разработчика платформы для анализа бизнес-процессов и вышла на новый рынок. А сейчас мы активно переходим на современные облачные архитектуры.

Конечно, пока за рубежом cloud-сервисами пользуются активнее, чем в России. По данным Gartner, в 2019 года мировой рынок публичных облаков составил $242,7 млрд, а в нашей стране пока 73 млрд рублей (~$1 млрд), следует из отчета ТМТ Консалтинг, хотя в России этот рынок растет быстрыми темпами.

Наши международные клиенты уже пользуются решениями, которые работают в облаке, например, ABBYY FlexiCapture и Cloud OCR SDK. Они помогают заказчикам автоматически распознавать штрихкоды, извлекать из товарных накладных суммы и даты и многое другое и делать все это со всевозможных устройств, различных операционных систем, удобно и безопасно. Нам бы хотелось, чтобы наши интеллектуальные решения становились еще доступнее для пользователей. Ведь даже в пандемию компаниям во всем мире все равно нужно обрабатывать счета, готовить налоговую отчетность, сравнивать написанное мелким шрифтом в разных версиях кредитных договоров, а также внедрять решения для удаленного обслуживания клиентов. Чтобы все эти задачи можно было решить в любое время, где угодно и в необходимом объеме, мы взяли курс на интеграцию наших продуктов с облачными технологиями.

Именно поэтому в 2019 году в нашей команде появился главный архитектор человек с хорошим знанием подходов к созданию архитектуры программного обеспечения в компании сегмента B2B и с большим опытом в построении и развитии облачных сервисов. Им стал Владимир Юнев, в прошлом облачный архитектор и эксперт по стратегическим технологиям Microsoft, известный в сообществе на Хабре как @XaocCPS.

Мы поговорили с Володей о том, чем занимается главный архитектор ABBYY и его команда, какими навыками и знаниями важно обладать такому специалисту и за какими ИТ-архитектурами будущее.

Чтобы стать главным архитектором, ты наверняка проделал большой путь. Расскажи, с чего ты начинал и как развивался в профессии?

Я начал работать в 17 лет в компании, которую образовали преподаватели ВУЗа, где я учился. Там на C++ и ассемблере мы уже в 1998 году делали то, что сегодня называют IoT. Мы автоматизировали процессы по обеспечению безопасности шахт: для этого собирали десятки метрик, анализировали их, предсказывали взрывоопасные ситуации. Набравшись опыта низкоуровневого программирования, я ушел работать в финансовое учреждение, где занимался клиент-серверной разработкой. Затем перешел в крупную IT-компанию, где начал разрабатывать первые продукты на базе веб-технологий. Примерно в 2005 году я перебрался в Свердловскую область и там работал над крупным публичным банковским порталом, который функционирует и сейчас.

В Екатеринбурге я познакомился с тусовкой разработчиков, использующих технологии Microsoft, а затем и с техническими представителями компании. Мы много общались и однажды с одним из сотрудников решили написать книгу про новую на то время технологию ASP.NET MVC. Книга вышла через год, и тираж раскупили за пару недель.

Я продолжал тесно общаться со специалистами Microsoft, мы делали совместные проекты, и вскоре я получил приглашение на работу. В 2011 году я стал экспертом по стратегическим технологиям Microsoft и за 6 лет получил все основные навыки, которыми обладаю сейчас. Сложно переоценить, как много дает работа в крупной глобальной ИТ-компании. Набравшись опыта в веб- и облачных технологиях, помогая внедрять и использовать их в стартапах, партнерах и клиентах Microsoft, я перешел на главную для себя роль облачного архитектора.

Облачный архитектор помогает клиентам компании эффективно применять купленные облачные сервисы и технологии. Я работал над проектами в таких крупных компаниях, как Сбербанк, Лаборатория Касперского, Тандер (сеть Магнит), Балтика и других. Кроме того, мы общались и с ABBYY, где у нас было много добрых знакомых.

Как ты попал в ABBYY и почему именно на должность главного архитектора?

На самом деле, это забавная история. На тот момент я проработал более трех лет архитектором в Microsoft. Осенью 2019 года я отдыхал с семьей в Турции и как-то просматривал на пляже уведомления на телефоне. Одно из них, судьбоносное, было от LinkedIn со списком подходящих для вас вакансий, среди которых я заметил должность Chief Architect в ABBYY. Ответить на предложение можно было в один клик, и я решил испытать судьбу, не особенно рассчитывая на результат. Работы я не искал, но всегда смотрел на рынок, изучая, какие в наше время требуются технологии и навыки. Позиция Chief Architect в одном из лидеров рынка тогда сразу показалась мне логичным развитием карьеры. В результате я стал главным архитектором и подключился к работе над очень интересными проектами компании.

Насколько я знаю, в ABBYY до твоего прихода не было должности главного архитектора. Получается, ты начал выстраивать работу в ABBYY c нуля? Расскажи об этом подробнее.

Да, я пришел в ABBYY в разгар достаточно сложной и большой перестройки внутренней структуры компании. Одним из нововведений стало появление моей позиции. Оно связано с решением ABBYY взять курс на развитие современных облачных архитектур, так как и технологические тренды, и рынок, и сами клиенты заявляют о совершенно определенных требованиях к продуктам и стеку технологий. Кроме того, современная разработка ведется очень энергично, и без применения новых методов, подходов и технологий добиться быстрых и качественных выпусков становится почти невозможно. В итоге, именно выбор современных средств и архитектур становится конкурентным преимуществом, которое позволяет удовлетворять спрос и потребности клиентов.

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

Чем ты занимаешься в ABBYY каждый день?

Мы в ABBYY разрабатываем решения, которые помогают компаниям автоматизировать процессы и быстрее решать рутинные задачи, например, обрабатывать информацию из сотен тысяч товарных накладных, счетов-фактур, актов и вносить данные из них в учетные системы.

Сегодня наш стек технологий построен на базе современных платформ и инструментов с открытым исходным кодом. Это такие платформы как Kubernetes и Docker c обширным набором инструментов из экосистемы, средства хранения и обработки данных Redis и PostgreSQL, платформа и языки разработки .NET Core и C#, средства обмена сообщениями RabbitMQ и так далее.

Вместе с этим, разрабатывая решение для публичных облаков, мы используем и управляемые готовые сервисы. Они предлагают публичные облака, и в нашем облаке мы применяем эти средства, чтобы еще больше снизить затраты на их сопровождение и поддержку. Например, любой облачный провайдер предлагает готовые сервисы для организации обмена сообщениями, хранения блобов, управляемые базы данных и многие другие компоненты, включая управляемые кластеры Kubernetes. Все это позволяет еще быстрее разрабатывать продукт и предоставлять более качественный сервис.

Помимо непосредственно архитектурных задач я возглавляю Chief Architect Office, куда входят разные команды, одна из которых команда общих библиотек. Общие библиотеки это строительные компоненты, на основе которых в компании выстраивают части больших продуктов. Важнейший их компонент библиотеку алгоритмов и машинного обучения NeoML мы с нашей крутой командой недавно выпустили на GitHub с открытым исходным кодом.

Расскажи про NeoML: как вы готовились к запуску библиотеки на GitHub и какие вызовы стояли перед вами?

NeoML масштабный проект, над которым команда ABBYY работала не один год. О том, как происходило создание библиотеки и о ее технических подробностях, мы рассказали в недавнем посте на Хабре.

Я пришел в компанию 19 декабря и мне поручили руководить выпуском фреймворка в open source. Над этим работала по-настоящему классная команда из самых разных департаментов. 16 июня мы официально опубликовали NeoML на GitHub. Работы за полгода было проделано много: подготовка и инспекция исходного кода, создание примеров приложений, перевод документации и комментариев, организация маркетинговой кампании, юридическое сопровождение и множество других мелких задач. Самым интересным и довольно сложным занятием оказался выбор названия библиотеки. Это заслуживает отдельной статьи, но, если кратко довольно тяжело в наши дни подобрать название ИТ-продукта так, чтобы оно не нарушило торговые марки других участников рынка.

NeoML это гордость компании, в библиотеке мы собрали многолетний опыт разработки интеллектуальных продуктов в ABBYY и технологический вклад десятков людей. Это не сырой проект, а зрелый набор инструментов, уже давно и успешно используемый нами в коммерческих продуктах. По сути, NeoML это технологическое основание бизнеса ABBYY, и теперь оно доступно для каждого на платформе GitHub.

Только за первый месяц мы получили более 400 звезд на GitHub и массу положительных отзывов как от сообщества, так и от наших клиентов. Они с энтузиазмом отреагировали на то, что их партнер делится своими технологиями на открытой платформе. Для многих клиентов это уверенность в том, что используемый ими продукт действительно обладает уникальными интеллектуальными возможностями.

Расскажи немного о своей команде: много ли в ней человек, как вы взаимодействуете?

Команда NeoML небольшая, но очень профессиональная, и я горжусь, что работаю с ней. У нас 5 разработчиков, включая тимлида, менеджера проекта и девопс-инженеров, которые помогают нам с инфраструктурными задачами. С составлением и переводом документации нам помогают опытные технические писатели. Кроме того, нашу команду поддерживает руководство департамента Product Development, куда входит и R&D. Оно активно участвует в стратегическом планировании развития библиотеки.

Какие у тебя впечатления об атмосфере работы в ABBYY? Компания чем-то отличается от других мест, в которых ты работал?

В первые дни в ABBYY удивительным открытием для меня стало то, что в компании многие люди работают десять и более лет и продолжают расти в профессиональном плане. Это большая редкость для ИТ-компаний, где наблюдается постоянная текучка кадров. Наверное, этому способствует особая открытая атмосфера, где сотрудники ценят человеческие отношения в работе, уважают мнение каждого и решают все трудности вместе. Многие приходят сюда после института и, развиваясь в одном и том же месте на протяжении долгого времени, успешно строят карьеру. Это, кстати, может быть как вертикальный, так и горизонтальный рост.

ABBYY международная компания. Многие коллеги работают в зарубежных офисах, и мы периодически общаемся онлайн. Кроме того, меня и других сотрудников приглашают сопровождать встречи с крупнейшими клиентами по всему миру из США и стран Европы, где мы общаемся и отвечаем на вопросы, рассказываем о наших архитектурных и технических решениях. Сегодня заказчики обладают глубокими техническими знаниями и хотят знать подробности продуктов.

На твой взгляд, какими знаниями, навыками и опытом важно обладать хорошему главному архитектору?

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

Оставаться при своих знаниях недостаточно. Необходимо постоянно следить за текущими трендами и развитием ключевых технологий и сервисов, облачных и других платформ. В нашей индустрии все очень быстро меняется, знания устаревают, появляются новые инструменты и подходы решения задач.

Для того чтобы быть в курсе трендов, потребуется тщательно отобрать источники информации, которые будут ежедневно поставлять новости. Это могут быть аккаунты инфлюенсеров (еще один термин из евангелизма, который означает ключевых персон в том или ином направлении) в социальных сетях; блоги крупнейших вендоров компаний, которые влияют на рынок своими продуктами и вкладом в технологии (например, блоги AWS, Google и Azure на тему новинок в облаках); новостные агрегаторы по темам как от крупных изданий, так и от энтузиастов, которые публикуют подборки новостей и технических статей. Наконец, заведите подписку на один из сервисов технической литературы, чтобы получить доступ к самым свежим книгам и публикациям.

Что бы ты посоветовал тем, кто хочет стать главным архитектором?

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

Мой топ-3 книг для начинающих архитекторов распределенных систем:

• Cloud Native by Boris Scholl, Trent Swanson, Peter Jausovec
• Fundamentals of Software Architecture by Mark Richards, Neal Ford
• Kubernetes: Up and Running, 2nd Edition by Brendan Burns, Joe Beda, Kelsey Hightower

Есть ли у тебя видение, какое будущее ждет рынок интеллектуальной обработки информации и анализа бизнес-процессов лет через 5-10?

Во-первых, я очень надеюсь, что мы вскоре полностью откажемся от бумажных носителей и мой ребенок уже не будет сталкиваться с бумажными формами в документообороте. Все к этому идет, многое уже в цифре.

Вместе с этим, объемы информации будут расти еще быстрее. Согласно исследованию IDC Data Age 2025, к 2025 году общий объем новых данных увеличится до 175 ЗБ по сравнению с 33 ЗБ в 2018 году. Нам кажется, что вокруг много информации, но ее станет еще больше. Что с ней делать? Анализировать, сортировать, выделять значимое и автоматизировать все эти процессы, чтобы видеть только самое полезное. И здесь пригодится опыт компании ABBYY. Наши клиенты получают самые современные инструменты для извлечения информации, интеллектуальной обработки данных и автоматического анализа процессов. С каждым годом мы делаем наши продукты все более интеллектуальными и умными, а наши клиенты пользуются этим, чтобы управлять потоком информации.

Через 5-10 лет все чаще решения будут принимать искусственный интеллект и алгоритмы, построенные на все более сложных моделях и математическом аппарате. И мы в ABBYY приближаем эти дни своими разработками.

Как главный архитектор, как ты думаешь, за какой архитектурой ИТ-проектов будущее? К чему все движется?

Все движется по спирали. Текущий тренд распределенная разработка на базе микросервисов уже сегодня начинает подвергаться критике, а казавшиеся вчера плохими монолитные системы внезапно, с реорганизацией, приобретают множество сторонников.

Вычислительные мощности растут огромными темпами. Задачи, на которые ранее требовался отдельный кластер из множества серверов, теперь решаются едва ли не на одном процессоре. За этим следует и переосмысление архитектурных подходов.

Сложно сказать, к чему все движется, потому что нет никакой цели есть только развитие. И как раз тут критически важно оставаться в курсе текущих трендов и не переставать узнавать новое.

Не так давно я писал про мониторинг Netflow/IPFIX и про Cisco StealthWatch аналитическое решение, которое позволяет детектировать такие события, как сканирования, распространение сетевых червей, шпионское ПО, нелегитимные взаимодействия и различного рода аномалии. О расследовании инцидентов с помощью StealthWatch написано в статье.
Мониторинг облачной инфраструктуры давно уже не является новой задачей, так у каждого крупного игрока, есть свои инструменты Amazon CloudWatch или Amazon S3, Google Stackdriver, Azure Monitor. Эти инструменты отлично подходят для мониторинга приложений, производительности и инфраструктуры в целом, но они не закрывают задачи по безопасности (да и сами провайдеры облаков не сильно ей обеспокоены): распространение зловредного ПО, ботнет-коммуникации, обнаружение аномалий, попытки сканирования, нелегитимный доступ (включая варианты с использованием легитимных учетных данных) и многое другое.

StealthWatch Cloud

StealthWatch Cloud (SWC) SaaS-решение, которое напоминает Stealthwatch Enterprise (не зря Cisco последнее время стирает границы между этими двумя решениями в своей архитектуре), но учитывает специфику облачных сред. Если для Stealthwatch Enterprise важным источником информации является телеметрия на базе Netflow, то Stealthwatch Cloud использует в качестве таких данных журналы облачных сред (не ограничиваясь логами, получая и другие виды телеметрии). Дальше выполняются привычные для StealthWatch действия: моделирование объектов, построение их поведенческих моделей, обнаружение отклонений, проверка соответствия политикам, обнаружение событий безопасности (как встроенных, так и заданных пользователем) и многое другое. Угрозы, аномальная и зловредная активность обнаруживаются быстрее, как следствие, ущерб от инцидента снижается или даже полностью нивелируется.
При этом у тревог Stealthwatch Cloud есть привычная для XXI века функция: заказчик может оценить полезность сгенерированной тревоги одним кликом мышки. На текущий момент 96% тревог, сгенерированных для существующих заказчиков StealthWatch Cloud, признаны полезными.
Область применения StealthWatch Cloud не ограничена облаками: решение может использоваться для мониторинга публичных облаков, частных облаков, классической корпоративной инфраструктуры, а также, безусловно, гибридной архитектуры с использованием любого сочетания этих трёх компонентов. Учтены в Stealthwatch Cloud и варианты обслуживания нескольких клиентов при оказании услуг по обеспечении безопасности.
Варианты развертывания можно представить примерно следующим образом.


Рисунок 1. Варианты использования StealthWatch Cloud

StealthWatch Cloud можно использовать при работе с публичными облаками (Amazon, Azure, Google), приватными и гибридными облаками, которые построены на инфраструктуре из Kubernetes и, разумеется, корпоративными сетями.
К слову, Mail.ru являются сертифицированным партнером Kubernetes (K8s). В StealthWatch Cloud отправляются журналы событий подов K8s и потоки трафика между этими подами. В результате приобретаются полная видимость подов K8s, сущностей приватного облака и обнаружение инцидентов безопасности, о которых сказано ранее. На рисунке 2 изображена схема взаимодействия.


Рисунок 2. Схема интеграции StealthWatch Cloud c Kubernetes

В случае работы с частными корпоративными сетями требуется установка виртуальной машины (Virtual Sensor аналог Flow Sensor в StealthWatch Enterprise). На рисунке 3 изображено, что на сенсор отправляется Netflow, IPFIX, SPAN, а по шифрованному туннелю сенсор отправляет информацию в StealthWatch Cloud, где и производится вся аналитика. Тем самым, вычислительные мощности заказчика не задействуются от слова совсем, а внедрение и пилот проходят максимально оперативно.


Рисунок 3. Схема интеграции StealthWatch Cloud с корпоративной сетью

Также хочется отметить, что установка Virtual Sensor влечет за собой массу положительных моментов:

• Поддерживается интеграция c Cisco ISE, AD;
• Работает технология ETA (Encrypted Traffic Analytics), позволяющая обнаруживать зловредные подключения в зашифрованном трафике без его расшифровки. Более того, данная технология позволяет разбирать HTTPS на версии TLS и криптографические протоколы, которые используются при соединениях;
• Доступен сигнатурный анализ вместе с безсигнатурным, который основывается на телеметрии.

Существует вариант и без установки виртуального сенсора (Virtual Sensor), но тогда StealthWatch Cloud сможет работать только с телеметрией, то есть сигнатурный анализ доступен не будет.
Еще немного плюсов StealthWatch Cloud:

• Гибкая модель лицензирования по мега-потокам (Effective Mega Flows EMF, где 1 EMF = 1 млн. логов, которые предварительно дедуплицируются, т.е. остаются в едином экземпляре, и считаются в конце месяца);
• Поддержка многопользовательских сред (это плюс для партнеров, предоставляющих SOC на аутсорс, из одной консоли можно мониторить всех заказчиков).

Выводы:
При работе с публичными, приватными и гибридными облаками StealthWatch Cloud позволяет обнаруживать следующие инциденты безопасности:

• Аномальное поведение пользователей, хостов
• Ботнет активность
• Брутфорс
• Попытки удаленного доступа, в том числе из необычных геолокаций
• Распространение зловредного ПО и обращения к зловредным URL
• Нарушение ролей взаимодействия
• Новые устройства, потоки
• Попытки сканирования
• Флуд трафика, штормы
• Система обнаружения вторжений (IDS)
• Специфичные события для AWS, Azure, GCP

При работе с частными корпоративными сетями добавляется практически весь функционал StealthWatch Enterprise.

Интеграция с Amazon Web Services (AWS)

StealthWatch Cloud использует AWS Lambda API (сервис по автоматическому исполнению программного кода и управлению вычислительными ресурсами в AWS) и Identity and Access Management (IAM) API. Это позволяет получать информацию о политиках доступа к инстансам, изменениях исполнения программного кода, проводить аудит инстансов и другое.
Дополнительно SWC использует данные о потоках (взаимодействиях сетевого уровня) с мониторинговых сервисов Amazon CloudWatch или Amazon S3. VPC (Virtual Private Cloud) Flow logs так называются данные о потоках в терминологии AWS.
Следовательно, со стороны администратора в личном кабинете Amazon Web Services следует дать права на чтение потоков (VPC Flow logs) и журналов событий с сервисов Amazon CloudTrail, Amazon IAM, Amazon GuardDuty, AWS Lambda, Amazon Inspector и AWS Config, если вы их используете.
На рисунке 4 изображены схема работы StealthWatch Cloud и AWS.


Рисунок 4. Схема работы StealthWatch Cloud и AWS

В свою очередь, SWC проводит аналитику и выводит ее на дэшборды, позволяя оперативно ознакомиться с текущим трафиком, загрузкой инфраструктуры и даже предсказать будущую загрузку рисунок 5.


Рисунок 5. Консоль мониторинга Amazon Web Services в StealthWatch Cloud

Интеграция с Microsoft Azure

В случае работы с Azure StealthWatch Cloud обращается к API Azure для считывания журналов событий, которые содержат информацию о трафике север-юг и запад-восток внутри облачной инфраструктуры. Называются такие журналы NSG Flow logs. По своей сути похожи на потоки Netflow, так как содержат в себе заголовки пакетов.
Большим отличием от кейса с AWS является то, что Azure может отправлять копию трафика с виртуальных машин через VTAP виртуальные ответвители трафика. VTAP является технологией разработанной Microsoft, но доступна для интеграции со всеми третьими решениями. Использование VTAP эффективно, потому что:

1. Копия трафика с нужных сегментов позволит SWC получить полную видимость и, как следствие, максимальное детектирование угроз.
2. Нагрузка на виртуальные машины не увеличивается, так как VTAP это трафик с виртуального коммутатора, а не самой машины.
3. Взаимодействие с SWC осуществляется по шифрованному TLS туннелю.

На рисунке 6 изображена схема взаимодействия.


Рисунок 6. Схема работы StealthWatch Cloud и Microsoft Azure

Интеграция с Google Cloud Platform

При интеграции с Google Cloud Platform (GCP) возможно только обращение к API со стороны SWC для считывания ранее упомянутых VPC Flow журналов событий (таких же, как и у Amazon) c Google Stackdriver. Google Stackdriver это сервис, который собирает логи и метрики из GCP, мониторит приложения, виртуальные машины и Google Cloud инфраструктуру в целом. Однако работа только с VPC Flow журналами событий дает немного меньшую видимость. Схема работы изображена на рисунке 7.


Рисунок 7. Схема работы StealthWatch Cloud и Google Cloud Platform

SWC vs. SWE

Хотя Stealthwatch Cloud и Stealthwatch Enterprise решают сходные задачи, области их применения и различия в основных источниках телеметрии обуславливают разные возможности. Сравнительные данные сведены в таблице ниже.
Можно заключить, что StealthWatch Enterprise является отличным вариантом, когда есть своя виртуальная инфраструктура, доступно много вычислительных ресурсов и нужен максимальный функционал по мониторингу корпоративной сети на предмет инцидентов безопасности, легитимных взаимодействий и видимости сети. К слову, можно приобрести и физическое исполнение StealthWatch.
В свою очередь, StealthWatch Cloud привлекателен быстротой развертывания (особенно для пилота), также для него не требуется развертывать и поддерживать виртуальные машины, кроме Virtual Sensor. SWC позволяет мониторить инфраструктуру в публичных, приватных облаках и поддерживает исходную интеграцию с единой платформой управления ИБ решениями Cisco SecureX.

Как протестировать?

Есть два варианта бесплатного пилотного проекта: самому или с партнером. В случае первого варианта, предлагаются обратиться к сайту. Лицензия выдается на 60 дней, гайды по настройке предоставляются на этом же сайте Cisco. В случае, если вы желаете больше погрузиться в детали и максимально качественно решить свои задачи по мониторингу, то обращайтесь к нам по ссылке.

Заключение

StealthWatch Cloud является многогранным решением, которое позволяет в максимально сжатые сроки получить полную видимость в приватном, публичном или гибридном облаке, будь-то Amazon Web Services, Microsoft Azure или Google Cloud Platform. Одновременно с этим данное решение может использоваться и для мониторинга корпоративных сетей, обладая при этом практически одинаковым функционалом в сравнении с on-premise StealthWatch Enterprise. Экономия времени, технических и человеческих ресурсов при работе c SWC вот явные преимущества.
В ближайшее время мы планируем еще несколько технических публикаций по различным продуктам ИБ. Если вам интересна данная тематика, то следите за обновлениями в наших каналах (Telegram, Facebook, VK, TS Solution Blog)!

В современном мире информация является значимым ресурсом, ее сохранность и правильное использование являются одними из первоочередных задач для развития организации и производства и снижения уровня разнообразных рисков. Важнейшим актуальным вопросом для предприятия является вопрос информационной безопасности.

В этой статье мы рассмотрим

• Что такое информационная безопасность?
• В чем отличие информационной безопасности и кибербезопасности?
• Цели информационной безопасности в организации и на предприятии
• Виды информационной безопасности
• Общие риски информационной безопасности
• Громкие инциденты безопасности в 2019 году
• Технологии информационной безопасности

Информационная безопасность (InfoSec) позволяет организациям и предприятиям защищать цифровую и аналоговую информацию. InfoSec обеспечивает покрытие криптографии, мобильных вычислений, социальных сетей, а также инфраструктуры и сетей, содержащих частную, финансовую и корпоративную информацию. Кибербезопасность, с другой стороны, защищает как необработанные, так и значимые данные, но только от интернет-угроз.
Организации уделяют значительное внимание вопросам информационной безопасности по многим причинам. Основным назначением InfoSec является обеспечение конфиденциальности, целостности и доступности информации о предприятии. Поскольку InfoSec охватывает многие области, она часто включает в себя реализацию различных типов безопасности, включая безопасность приложений, безопасность инфраструктуры, криптографию, реагирование на инциденты, управление уязвимостями и аварийное восстановление.

Что такое информационная безопасность?

InfoSec или информационная безопасность это набор инструментов и методов, используемых для защиты своей цифровой и аналоговой информации. InfoSec охватывает целый ряд IT-областей, включая инфраструктуру и сетевую безопасность, аудит и тестирование. Он использует такие инструменты, как аутентификация и разрешения, чтобы ограничить несанкционированный доступ пользователей к частной информации. Эти меры помогут вам предотвратить вред, связанный с кражей, изменением или потерей информации.

В чем отличие информационной безопасности и кибербезопасности?

Кибербезопасность и информационная безопасность охватывают различные цели и области, но и имеют некоторые общие черты. Информационная безопасность это более широкая категория защиты, охватывающая криптографию, мобильные вычисления и социальные сети. Она связана с обеспечением информационной безопасности, используемой для защиты информации от угроз, не связанных с человеком, таких как сбои серверов или стихийные бедствия. В свою очередь, кибербезопасность охватывает только интернет-угрозы и цифровые данные. Кроме того, кибербезопасность обеспечивает защиту необработанных, несекретных данных, в то время как информационная безопасность нет.

Цели информационной безопасности в организации и на предприятии

Существует три основные цели, защищаемые информационной безопасностью, в совокупности известной как CIA:

• Конфиденциальность предотвращает несанкционированный доступ пользователей к информации для защиты конфиденциальности информационного контента. Конфиденциальность обеспечивается за счет ограничений доступа. Нарушение конфиденциальности может произойти из-за человеческой ошибки, преднамеренного обмена информацией или злонамеренного проникновения.
  
• Целостность обеспечивает достоверность и точность информации. Целостность поддерживается путем ограничения прав на редактирование или возможности изменять информацию. Потеря целостности может произойти, когда аналоговая информация не защищена от внешних условий, цифровая информация не передается должным образом или когда пользователи вносят неутвержденные изменения.
• Доступность гарантирует, что авторизованные пользователи могут надежно получить доступ к информации. Доступность поддерживается за счет непрерывности процедур доступа, резервного копирования или дублирования информации, а также обслуживания аппаратных средств и сетевых соединений. Потеря доступности может произойти, когда сети подвергаются атаке из-за стихийных бедствий или когда клиентские устройства выходят из строя.

Виды информационной безопасности

При рассмотрении информационной безопасности информационной безопасности существует несколько классификаций. Эти классификации охватывают конкретные типы информации, инструменты, используемые для защиты информации, и области, где информация нуждается в защите.

Безопасность приложений

Стратегии безопасности приложений защищают приложения и интерфейсы прикладного программирования (API). Вы можете использовать эти стратегии для предотвращения, обнаружения и исправления ошибок или других уязвимостей в ваших приложениях. Если они не защищены, уязвимости приложений и API могут стать шлюзом для более широких систем, подвергая риску вашу информацию.

Безопасность инфраструктуры

Стратегии безопасности инфраструктуры защищают компоненты инфраструктуры, включая сети, серверы, клиентские устройства, мобильные устройства и центры обработки данных. Растущая связь между этими и другими компонентами инфраструктуры ставит информацию под угрозу без надлежащих мер предосторожности.

Этот риск связан с тем, что подключение расширяет уязвимые места в ваших системах. Если одна из частей вашей инфраструктуры выходит из строя или подвергается риску, все зависимые компоненты также подвергаются воздействию. В связи с этим важной целью обеспечения безопасности инфраструктуры является минимизация зависимостей и изоляция компонентов при одновременном обеспечении возможности взаимодействия.

Облачная безопасность

Облачная безопасность обеспечивает аналогичную защиту безопасности приложений и инфраструктуры, но ориентирована на облачные или подключенные к облаку компоненты и информацию. Облачная безопасность добавляет дополнительные средства защиты и инструменты, чтобы сосредоточиться на уязвимостях, которые исходят от интернет-сервисов и общих сред, таких как общедоступные облака. При использовании облачных ресурсов и приложений вы часто не можете полностью контролировать свои среды, поскольку инфраструктура обычно управляется за вас. Это означает, что методы облачной безопасности должны учитывать ограниченный контроль и принимать меры для ограничения доступности и уязвимости, исходящие от подрядчиков или поставщиков.



Криптография

Криптография использует шифрование, чтобы защитить информацию, скрывая ее содержание. Когда информация зашифрована, она доступна только тем пользователям, у которых есть правильный ключ шифрования. Если у пользователей нет этого ключа, то информация для него недоступна. Команды безопасности могут использовать шифрование для защиты конфиденциальности и целостности информации на протяжении всего ее срока службы, в том числе при хранении и передаче. Однако, как только пользователь расшифровывает данные, они становятся уязвимыми для кражи, разоблачения или модификации.

Для шифрования информации команды безопасности используют такие инструменты, как алгоритмы шифрования или технологии, такие как блокчейн. Алгоритмы шифрования, такие как advanced encryption standard (AES), более распространены, так как существует большая поддержка этих инструментов и меньше накладных расходов на их использование.

Реагирование на инциденты

Реагирование на инциденты это набор процедур и инструментов, которые можно использовать для выявления, расследования и реагирования на угрозы или разрушительные события. Он устраняет или уменьшает ущерб, причиненный системам в результате атак, стихийных бедствий, системных сбоев или человеческой ошибки.
Обычно используемым инструментом реагирования на инциденты является план реагирования на инциденты (IRPs). IRPs определяют роли и обязанности по реагированию на инциденты. Эти планы также содержат информацию о политике безопасности, содержат руководящие принципы или процедуры действий.

Управление уязвимостями

Управление уязвимостями это практика, направленная на снижение присущих приложению или системе рисков. Идея этой практики заключается в обнаружении и исправлении уязвимостей до того, как проблемы будут раскрыты или использованы. Чем меньше уязвимостей имеет компонент или система, тем более безопасны ваши данные и ресурсы.
Методы управления уязвимостями основаны на тестировании, аудите и сканировании для обнаружения проблем. Эти процессы часто автоматизируются, чтобы гарантировать, что компоненты оцениваются в соответствии с определенным стандартом и чтобы обеспечить обнаружение уязвимостей как можно быстрее. Другой метод, который вы можете использовать, это поиск угроз, который включает в себя исследование систем в режиме реального времени для выявления признаков угроз или обнаружения потенциальных уязвимостей.

Аварийное восстановление

Стратегии аварийного восстановления защищают вашу организацию от потерь или повреждений, вызванных непредвиденными событиями. Например, вымогатели, стихийные бедствия или отдельные точки сбоя. Стратегии аварийного восстановления обычно определяют, как можно восстановить информацию, как можно восстановить системы и как можно возобновить операции. Эти стратегии часто являются частью плана управления непрерывностью бизнеса (BCM), разработанного для того, чтобы позволить организациям поддерживать операции с минимальными простоями.

Общие риски информационной безопасности

В вашей повседневной деятельности многие риски могут повлиять на вашу систему и информационную безопасность. Ниже приведены некоторые общие риски, о которых следует знать.

Социальная инженерия включает в себя использование психологии, чтобы обмануть пользователей в предоставлении информации или доступа к злоумышленникам.Фишинг это один из распространенных видов социальной инженерии, обычно выполняемый с помощью электронной почты. При фишинговых атаках злоумышленники притворяются надежными или законными источниками, запрашивающими информацию или предупреждающими пользователей о необходимости принятия мер. Например, электронные письма могут просить пользователей подтвердить личные данные или войти в свои учетные записи через включенную (вредоносную) ссылку. Если пользователи подчиняются, злоумышленники могут получить доступ к учетным данным или другой конфиденциальной информации.

Расширенные постоянные угрозы(APT) это угрозы, при которых отдельные лица или группы получают доступ к вашим системам и остаются в них в течение длительного периода времени. Злоумышленники осуществляют эти атаки для сбора конфиденциальной информации с течением времени или в качестве основы для будущих атак. Теракты АПТ совершаются организованными группами, которые могут оплачиваться конкурирующими национальными государствами, террористическими организациями или промышленными конкурентами.

Угрозы инсайдерской информации это уязвимости, создаваемые отдельными лицами в вашей организации. Эти угрозы могут быть случайными или преднамеренными и включать злоумышленников, злоупотребляющих законными привилегиями для доступа к системам или информации. В случае случайных угроз сотрудники могут непреднамеренно делиться или раскрывать информацию, загружать вредоносные программы. При преднамеренных угрозах инсайдеры намеренно повреждают, скачивают или крадут информацию для личной или профессиональной выгоды.

Криптоджекинг, также называемый крипто-майнингом, это когда злоумышленники злоупотребляют вашими системными ресурсами для добычи криптовалюты. Злоумышленники обычно достигают этого путем обмана пользователей в загрузке вредоносных программ или когда пользователи открывают файлы с включенными вредоносными скриптами.

Распределенный отказ в обслуживании(DDoS). DDoS-атаки происходят, когда злоумышленники перегружают серверы или ресурсы запросами. Злоумышленники могут выполнять эти атаки вручную или через ботнеты, сети скомпрометированных устройств, используемых для распространения источников запросов. Цель DDoS-атаки состоит в том, чтобы помешать пользователям получить доступ к сервисам или отвлечь команды безопасности во время других атак.
Вымогатели используют вредоносные программы для шифрования ваших данных и хранения их для выкупа. Как правило, злоумышленники требуют информацию, чтобы какие-то действия были предприняты, или оплату от организации в обмен на расшифровку данных. В зависимости от типа используемой программы-вымогателя, вы не сможете восстановить зашифрованные данные. В этих случаях вы можете восстановить данные только путем замены зараженных систем чистыми резервными копиями.

Атака Man-in-the-middl (MitM) Атаки MitM происходят, когда сообщения передаются по небезопасным каналам. Во время этих атак злоумышленники перехватывают запросы и ответы, чтобы прочитать содержимое, манипулировать данными или перенаправлять пользователей.
Типы атак MitM:

• захват сеанса в котором злоумышленники заменяют свой собственный IP-адрес для законных пользователей, чтобы использовать их сеанс и учетные данные для получения доступа к системе.
  
• IP-подмена в которой злоумышленники имитируют надежные источники, чтобы отправить вредоносную информацию в систему или запросить информацию обратно.
• подслушивающие атаки в ходе которых злоумышленники собирают информацию, передаваемую в коммуникациях между законными пользователями и вашими системами.

Громкие инциденты безопасности в 2019 году

В марте крупнейший мировой производитель алюминия Norsk Hydro был вынужден приостановить работу производственных объектов из-за атаки вымогателя LockerGoga. По оценкам компании, ущерб от инцидента составил порядка $35-41 млн. В числе жертв различных программ-вымогателей также оказались, швейцарский производитель спецтехники Aebi Schmidt, немецкий концерн Rheinmetall и пр.

В конце июня были обнародованы подробности о масштабной кампании по кибершпионажу, в рамках которой преступники внедрились в сети крупнейших мировых телекоммуникационных компаний с целью перехвата информации о конкретных лицах. Организатором кампании предположительно являлась связанная с КНР группировка APT10. Злоумышленникам удалось похитить порядка 100 ГБ информации и с помощью подробных данных о вызове (Call Detail Records, CDR) отслеживать передвижения и действия интересовавших их лиц.

Технологии информационной безопасности

Создание эффективной стратегии информационной безопасности требует применения различных инструментов и технологий. В большинстве стратегий используется определенная комбинация следующих технологий.


Брандмауэры это уровень защиты, который можно применить к сетям или приложениям. Эти инструменты позволяют фильтровать трафик и передавать данные о трафике в системы мониторинга и обнаружения. Брандмауэры часто используют установленные списки разрешенного или не разрешенного трафика и политики, определяющие скорость или объем разрешенного трафика.

Решения SIEM для управления инцидентами и событиями безопасности позволяют вам получать и сопоставлять информацию из разных систем. Такое объединение данных позволяет командам более эффективно обнаруживать угрозы, более эффективно управлять предупреждениями и обеспечивать лучший контекст для расследований. Решения SIEM также полезны для регистрации событий, происходящих в системе, или для составления отчетов о событиях и производительности. Затем вы можете использовать эту информацию для подтверждения соответствия или оптимизации конфигураций.

Стратегии предотвращения потери данных (DLP) включают в себя инструменты и методы, которые защищают данные от потери или модификации. Это включает в себя классификацию данных, резервное копирование данных и мониторинг того, как данные совместно используются в организации и за ее пределами.

Система обнаружения вторжений (IDS) это инструменты для мониторинга входящего трафика и обнаружения угроз. Эти инструменты оценивают трафик и предупреждают о любых случаях, которые кажутся подозрительными или вредоносными.

Система предотвращения вторжений (IPS) эти решения реагируют на трафик, который идентифицируется как подозрительный или вредоносный, блокируя запросы или завершая сеансы пользователя. Вы можете использовать IP-решения для управления сетевым трафиком в соответствии с определенными политиками безопасности.

Поведенческая аналитика пользователей (UBA) решения UBA собирают информацию о действиях пользователей и соотносят их поведение с базовым уровнем. Затем решения используют этот базовый уровень в качестве сравнения с новыми моделями поведения для выявления несоответствий. Затем решение помечает эти несоответствия как потенциальные угрозы.

Блокчейн-кибербезопасность это технология, которая опирается на неизменяемые транзакционные события. В блокчейн-технологиях распределенные сети пользователей проверяют подлинность транзакций и обеспечивают поддержание целостности.

Решения по кибербезопасности EDR позволяют отслеживать активность конечных точек, выявлять подозрительные действия и автоматически реагировать на угрозы. Эти решения предназначены для улучшения видимости конечных устройств и могут быть использованы для предотвращения проникновения угроз в ваши сети или выхода информации. Решения EDR основаны на непрерывном сборе данных конечных точек, механизмах обнаружения и регистрации событий.

Управление положением облачной безопасности (CSPM) это набор практик и технологий, которые вы можете использовать для оценки безопасности ваших облачных ресурсов. Эти технологии позволяют сканировать конфигурации, сравнивать средства защиты с эталонными показателями и обеспечивать единообразное применение политик безопасности. Часто решения CSPM предоставляют рекомендации или рекомендации по устранению неполадок, которые вы можете использовать для улучшения своей позиции безопасности.

Не так давно мы с командой разработали небольшой встраиваемый компьютер для решения задач IIoT и промышленной автоматизации. Первую статью о нашем устройстве можно посмотреть здесь.

Разрабатывать устройство решили на распространенном и оттестированном модуле Raspberry CM3+, что позволило нам создать компьютер с большими вычислительными способностями, огромным сообществом и простотой его использования. Под катом расскажу по этапам, от чего отталкивались и к чему пришли в итоге.

Муки выбора корпуса

Для устройств даже в промышленной сфере очень важен внешний вид устройства и законченность, таким образом начались долгие поиски корпуса, подходившие под наши требования по размеру. Хотелось максимально много уместить в одну коробку и самые минимальные параметры платы получались 10*10 см.

После того, как мы заказали несколько вариантов корпусов, пришлось большее количество из них выбросить, так как они подходили только для домашних поделок и продавать их людям в таком виде не представлялось возможным. Основным претендентом на тот момент стал алюминиевый корпус с пластиковыми крышками 10*10*5 см (рисунок 1).


Рисунок 1 Первый вариант корпуса

Получив этот корпус в руки, было принято решение остановиться на нем. В этот же момент разработка платы подходила к концу и уже можно было по чертежам предварительно оценить, каким образом обрабатывать торцы для выводных разъемов. Однако пластиковые крышки корпуса после механической обработки сделали вид не товарным и мы опять пришли к поделке, а не к законченному коммерческому продукту.

Глянец весь быстро поцарапался и в этой блестящей рамке отверстия выглядели очень асимметрично (рисунок 2). Ожидание и реальность, как говорится.


Рисунок 2 Пластиковые крышки корпуса

Однако отказываться от корпуса не пришлось, потому что у производителя был такой же, но с алюминиевыми торцами, мы быстро его заказали и удивились, насколько он идеально выглядел (рисунок 3). Торцы очень красивые, матовые и бонусом была дополнительная помехозащищенность. Стоил такой корпус уже немного дороже, но красота требует жертв.


Рисунок 3 Металлический корпус

Вторая попытка обработать торцы была гораздо удачнее. Технологию надписей мы выбрали путём гравировки (рисунок 4), однако были недостатки которые пришлось решать. Самое главное это то, что гравер (сверло) очень маленький и нежный, скорость нанесения гравировки достаточно низкая. Плюс само сверло часто ломается. Из-за всего этого сильно растёт цена из-за потребляемой электроэнергии и трудозатрат. Также внутрь гравировки набивается грязь и постепенно окисляется алюминий, делая надписи менее заметными.


Рисунок 4 Гравировка металлического корпус

Эту технологию пробовали менять на лазерную гравировку, но получилось некрасиво. Лазер выжигал краску некорректно, а надписи получались темными.

В итоге мы пришли к шелкографии с запеканием в печи (рисунок 5). Эта технология оказалась самой быстрой и очень крепкой. Всё свелось к тому, чтобы заказать единожды шаблон (фотовывод) и по нему делать партию до 50 штук в день.


Рисунок 5 Шелкография корпуса

Исправление недоработок

С корпусом закончили, а вот с платой оставались недоработки. Задумка нашего компьютера в том, чтобы любой пользователь мог спокойно установить дополнительное оборудование в устройство, открутив четыре болта на корпусе, как в свой ноутбук. Я думаю прошли те времена, когда на корпуса клеили наклеечки Не вскрывать, потеря гарантии.

Внутри корпуса есть периферия для прошивки вычислительного модуля, SIM-карта и многое другое. Однако была одна проблема с монтажом платы в корпус, а именно выводные светодиоды на ножках, которые постоянно гнулись у наших клиентов, взявших прототипы на тест (рисунок 6).


Рисунок 6 Выводные светодиоды на ножках

В этой связи пришлось поменять диоды на ножках на SMD-светодиоды, которые светят в бок и проблема с установкой платы в корпус решилась, больше ничего не гнулось (рисунок 7).


Рисунок 7 SMD-светодиоды

Индикация была глубоко внутри корпуса и чтобы увидеть свет приходилось смотреть под прямым углом на торец. В голову пришла идея световодов из полимерных прозрачных материалов (рисунок 8). Оставалось найти бюджетный, но эстетически красивый вариант. В голову пришел молочный плексиглас с прозрачностью 20% с толщиной листа 3 мм, в первой же фирме лазерной резки подобрали диаметр миниатюрного цилиндра, он был равен диаметру отверстия в корпусе. Особенность в том, что станок при лазерной резке дает небольшой скос нижнего диаметра на 0.1 мм и таким образом мы получили мешок миниатюрных усеченных конусов с нижним диаметром 2,9 мм и верхним 3 мм, а высота была 3 мм как и толщина торцов нашего корпуса. Вставляем конус в отверстие и запрессовка крепко загоняет эти световоды в отверстие, а небольшая капелька клея с обратной стороны фиксирует их намертво.


Рисунок 8 Световоды из плексигласа

Итак, устройство получило эстетичный вид при небольших вложениях в корпус, однако этот путь хорош на старте производства и уменьшение издержек планируется путем изготовления подобного корпуса при наращивании производства. Литье из пластика не рассматривается в виду дорогого запуска производства и низких экранирующих способностей по сравнению с металлом.

Итог

Спасибо за внимание! Надеемся, что мы вдохновим читателей на переработку Ваших личных проектов в более масштабное производство с коммерческими перспективами. В нашей великой стране на полочках у инициаторов пылятся действительно нужные вещи, которые могут заменять зарубежные производства.

В следующей статье мы расскажем Вам историю тестирования и тонкости настройки mPCIe 3G-модема Huawei и mPCIe LoraWan-модуля MikroTik.

В сфере промышленной автоматизации существует негласная парадигма, в которой многие производители промышленного оборудования делают контроллеры отдельно, а модемы отдельно. Как правило, каждое устройство помещается в свой корпус, имеет своё питание, большие габариты и высокую стоимость. Такой вариант разделения функционала имеет свои преимущества и недостатки, но, по нашему мнению, он ведет, скорее, к бльшей коммерциализации, чем обусловлен какими-то объективными причинами. Поэтому мы решили пойти немного по другому пути и сделали универсальное устройство, которое представляет из себя свободно программируемый контроллер на базе Linux с модемом в едином корпусе. Это нам позволило в своих проектах практически совсем отказаться от привычных всем щитов автоматизации и прийти к более мобильным решениям.

Под катом этой статьи мы поделимся с Вами тонкостями настройки модема и несколькими полезными скриптами для более стабильного 3G-соединения.

Предпосылки и решения

При разработке своего устройства мы руководствовались тем, что оно должно выходить в мобильный интернет, чтобы подключаться к облачным платформам. Было два пути: напаивать модем на плату, либо использовать mPCIe-разъемы. Мы остановились на втором варианте и предусмотрели сразу два mPCIe-разъема (рисунок 1), поскольку такой вариант нам показался более интересным и гибким. Ведь установка и замена модема занимает считанные секунды, плюс для пользователя появляется необходимая вариативность и он может использовать такие комбинации mPCIe-модулей, которые ему необходимы под конкретный проект. Кроме 3G-модема это может быть LoraWan или Wi-Fi модули. Плюс ко всему mPCIe-решения зарекомендовали себя как достаточно надежные и качественные.


Рисунок 1 mPCIe-разъемы

В качестве основного 3G-модуля для нашего устройства мы рассматривали следующие варианты:

• MikroTik R11e-LTE6
• Quectel EC25-E
• YUGA CLM920 TE5
• HUAWEI MU709s-2p

Однако после проведения тестов наиболее предпочтительным для нас в плане надежности и соотношения цена-качество оказался модем фирмы HUAWEI (рисунок 2). Мы взяли его за основу и устанавливаем опционально в наши устройства. Поэтому в дальнейшем мы будем рассматривать настройку и скрипты относительного модема этой модели. Возможно, этот скрипт будет универсальным и будет полезен для других модемов, однако стабильность работы с другими моделями не гарантируется. Для Rasbian Buster и HUAWEI MU709s-2p всё работает отлично.


Рисунок 2 Модем HUAWEI MU709s-2p, установленный на плату устройства

Использование скрипта для перезагрузки 3G-модема

Для более устойчивой и безотказной работы мы написали скрипт, который будет пинговать заданный IP-адрес, а если же определенное в настройках количество пингов не прошло, то GSM-модем перезагрузится, тем самым восстанавливая зависшее сетевое соединение. Стоит отметить, что модем определяется в системе как сетевая карта lan1.

Архив со всеми необходимыми файлами можно скачать по этой ссылке. Также текст самих скриптов представим ниже.

Файл check_inet.sh необходим для проверки наличия интернет соединения. Если заданный IP-адрес не пингуется, то мы дергаем 19 ногу и перезапускаем модем по питанию. Код из себя представляет следующий вид:

#!/bin/bash#count=0;#echo "Start script"#echo 19 > '/sys/class/gpio/export'while [ true ]; do# sleep 30. /home/pi/igate.conf#echo $usb_port#echo 'AT^NDISDUP=1,1,''"'$apn'"''\r\n' #echo 'AT^NDISDUP=1,1,"internet.mts.ru"\r\n' flag=0for ((i = 1; i <= $ping_count; i++)); do#for i in {1..$ping_count}; do #делаем 5 пингов до сервера#ping -I eth1 -c 1 8.8.8.8 > /dev/null || flag=$(($flag+1))ping -I $interface -c 1 $ping_ip || flag=$(($flag+1))sleep 1doneif [ "$flag" -ge "$ping_error" ]; then #если потерь пакетов больше 3х#echo "рестарт модема - начало"#count=$((count+1))#echo $count#рестарт модемаsudo ifconfig eth1 downecho 19 > '/sys/class/gpio/export'echo out > '/sys/class/gpio/gpio19/direction'echo 0 > '/sys/class/gpio/gpio19/value'sleep 1echo 1 > '/sys/class/gpio/gpio19/value'sleep 15sudo ifconfig eth1 upsleep 1#echo -en 'AT^NDISDUP=1,1,"internet.mts.ru"\r\n' > /dev/ttyUSB3#АТ команда для записи настроек точки доступа APNecho -en 'AT^NDISDUP=1,1,''"'$apn'"''\r\n' > $usb_port#echo "рестарт модема - конец"fisleep $timeoutdone 

Файл start_inet.sh запускает check_inet.sh после перезагрузки устройства:

#!/bin/bash### BEGIN INIT INFO# Provides:          start_inet# Required-Start:    $remote_fs $syslog# Required-Stop:     $remote_fs $syslog# Default-Start:     2 3 4 5# Default-Stop:      0 1 6# Short-Description: Example initscript# Description:       This service is used to manage a servo### END INIT INFOcase "$1" in     start)        echo "Starting check_inet"        sudo /home/pi/check_inet.sh > /dev/null 2>&1 &        #/home/pi/check_inet.sh        ;;    stop)        echo "Stopping check_inet"        #killall servod        sudo kill -USR1 $(ps ax | grep 'check_inet' | awk '{print $1}')        ;;    *)        echo "Usage: /etc/init.d/check_inet start|stop"        exit 1        ;;esacexit 0

Также в архиве находится файл конфигурации igate.conf

Последовательность настройки:
1. Добавьте правило соответствия физического подключения COM-порта модема к концентратору USB. Для этого поправьте файл по следующему пути:

sudo nano /etc/udev/rules.d/99-com.rules

2. Добавьте в файл следующую строку:

KERNEL==ttyUSB*, KERNELS==1-1.5:2.4, SYMLINK+=GSM

3. Сохраните правила и перезагрузите устройство. Теперь порт Вашего модема будут определять по удобному псевдониму /dev/GSM;
4. Скачайте архив по предложенной выше ссылки, либо самостоятельно создайте файлы check_inet.sh, start_inet.sh и igate.conf;
5. Скопируйте файл check_inet.sh в папку:

/home/pi/

6. Сделайте файл check_inet.sh исполняемым:

sudo chmod +x /home/pi/check_inet.sh

7. Скопируйте файл start_inet.sh в папку:

/etc/init.d/

8. Сделайте файл start_inet.sh исполняемым:

sudo chmod +x /etc/init.d/start_inet.sh

9. Обновите конфигурацию автозагрузки выполнив команду:

sudo update-rc.d start_inet.sh defaults

10. Скопируйте файл igate.conf в папку:

/home/pi/

11. Настройте файл конфигурации. Ниже представлен файл конфигурации с комментариями:

#ip-адрес пинга. Скрипт будет пытаться пинговать этот ip-адрес, если определенное в параметре [ping_error] количество пингов не прошло, скрипт будет перезагружать GSM-модем, тем самым восстанавливая зависшее сетевое соединение.ping_ip=8.8.8.8#точка доступа APN. Это адрес точки доступа Вашего интернет-провайдера, он выдается вместе с сим-картой.apn=internet.mts.ru#период проверки соединения 3G (период пинга). Период выполнения скрипта. Каждые 30 секунд будет осуществляться проверка пингов.timeout=30#количество пингов. Общее количество пингов.ping_count=5#количество неуспешных пингов для рестарта модема. Количество неуспешных пингов, после которых необходимо выполнять перезагрузку модема. Не может быть больше чем [ping_count]. Процент потерянных пакетов нужно подбирать индивидуально в зависимости от качества покрытия сети.ping_error=3#LAN интерфейс модема. Сетевой интерфейс модема, обычно на устройстве AntexGate определяется как [eth1], посмотреть название можно выполнив команду ifconfiginterface=eth1#USB порт модема. Физический USB порт к которому подключена сетевая карта, обычно на устройстве AntexGate определяется как [ttyUSB4]usb_port=/dev/GSM

Управление скриптом

Запуск в фоновом режиме файла скрипта check_inet.sh:

/etc/init.d/start_inet.sh start

Остановить check_inet.sh:

/etc/init.d/start_inet.sh stop

Скрипт также автоматически запускается после перезагрузки устройства.

Варианты применения устройства

Рассмотрим основные задачи, под которые можно использовать устройство:

1. Контроллер с выходом в интернет для передачи данных в облако;
2. 3G-роутер для задач в поле;
3. Контроллер для умного дома с резервирующим каналом 3G. То есть можно использовать LAN-порт как основной канал связи, а 3G в качестве резервного, чтобы всегда был доступ к устройству;
4. Базовая станция LoRaWAN, то есть опрос устройств по LoRaWAN и передача данных в облако через сеть 3G или LTE;
5. Устройство для мониторинга транспорта (подключение по CAN и стыковка с различными сервисами)

На самом деле, вариантов применения такого устройства может быть очень много и несомненным его плюсом является законченность, универсальность и мобильность. Одно устройство может заменить привычный шкаф автоматизации и стать незаменимым решением в Ваших проектах.

Вторая ежегодная конференция Yandex Scale начнётся сегодня, 23 сентября, в 18.00 по Москве. В этот раз она пройдёт онлайн, а мы проведем текстовую трансляцию на Хабре.



Развитие облачных технологий в этом году позволило компаниям и разработчикам стать мобильнее, быстрее реагировать на изменения и создавать новые качественные продукты. Мы в Yandex.Cloud, в свою очередь, проделали большую работу по развитию платформы, реализовали крупные проекты и сегодня представим новые возможности и сервисы нашего облака.

Вести трансляцию будет редактор Yandex.Cloud Евгений Левашов levashove и руководитель направления архитектуры облачных решений Григорий Атрепьев farlol.

В статье пойдет речь о проблемах организации сетевой инфраструктуры традиционным способом и о методах решения тех же самых вопросов при помощи облачных технологий.

Для справки. 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 может работать поверх нескольких транспортных протоколов:

• SSH (RFC 4742);

  
  

• SOAP (RFC 4743);

  
  

• BEEP (RFC 4744);

  
  

• TLS (RFC 5539).

  
  

Если сравнивать 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).

  
  

Полезные ссылки

1. Telegram chat Zyxel

   
   

2. Форум по оборудованию Zyxel

   
   

3. Много полезного видео на канале Youtube

   
   

4. Zyxel Nebula простота управления как основа экономии

   
   

5. Различие между версиями Zyxel Nebula

   
   

6. Zyxel Nebula и рост компании

   
   

7. Сверхновое облако Zyxel Nebula экономичный путь к безопасности?

   
   

8. Zyxel Nebula Options for Your Business

   
   

Какой коммутатор использовать для решения той или иной задачи: управляемый или неуправляемый? Разумеется, однозначные ответы вроде: Нужно брать который круче или который дешевле не подходят, оборудование нужно подбираться строго по требуемым характеристикам. А какие они, эти характеристики? И какие существуют преимущества у той или иной группы устройств?

Примечание. В этой статье мы говорим о сетях семейства Ethernet, в том числе: Fast Ethernet, Gigabit Ethernet, 10 Gigabit Ethernet. Для экономии времени все эти сети для краткости мы будем называть термином Ethernet.

Для чего нужны неуправляемые коммутаторы

Неуправляемыми коммутаторами называют самые простые устройства без возможности принудительно изменять какие-либо характеристики. В основе лежит принцип: включил и работай.

Преимущества неуправляемых коммутаторов

Как уже было сказано, это достаточно простые устройства. Они не содержат сложных контроллеров, не требуют повышенного питания, меньше греются, их работу сложнее нарушить, а при выходе из строя их довольно просто заменить (не надо ничего перенастраивать).

Ещё один несомненный плюс неуправляемые коммутаторы стоят дешевле.

Такие устройства применяются в простых сетях, где не требуется применения сложных сетевых конфигураций. Тут надо отменить, что под понятием простые сети может скрываться вполне себе развитая инфраструктура среднего предприятия на 100+ локальных клиентов.

Ещё одна область применения в отдельных выделенных сетях, куда посторонним вход запрещен. Например, в сети видеонаблюдения, в которой кроме службы безопасности и администратора остальным сотрудникам офиса делать нечего.

Из практики. Сетевые инфраструктуры только из неуправляемых коммутаторов без применения другого сетевого оборудования (за исключением Интернет-шлюза) редко переходят за порог 254 устройства. Такие LAN часто оформляются в виде одной подсети класса С. На это есть свои причины если слишком много устройств находится в одном широковещательном домене, то служебный Ethernet трафик достигает существенной величины и начинает мешать передаче информации. Это связано с тем, что каждое устройство обязано принять и обработать широковещательные кадры, а это, в свою очередь создает ненужную нагрузку и засоряет канал связи. Чем больше устройств, тем больше широковещательных посылок время от времени проходит по сети, которые принимают все эти же устройства. В свою очередь маска подсети класса С 255.255.255.0 и префикс 192.168.xxx.xxx популярные значения, а предел в 254 устройства для сетей этого класса является, помимо всего прочего, своего рода психологической отметкой, когда приходит понимание, что c разросшейся сетью надо что-то делать.

Ещё одна сфера применения неуправляемых коммутаторов удешевление сетевой инфраструктуры. Строить развернутую сеть на базе только управляемых коммутаторов достаточно дорогое удовольствие. На практике возникают случаи, когда большое число однотипных устройств находятся в одной подсети и расположены относительно недалеко. В качестве примера можно привести пользователей тонких клиентов в опенспейсе, которым назначен отдельный изолированный VLAN. В таких простых случаях функции управления на коммутаторе уровня доступа не так уж и востребовано. За вопросы безопасности и перенаправления трафика отвечает уровень распределения (агрегации) и далее ядро сети.

Ещё один классический пример: специально выделенная сеть для управления оборудованием, куда подключены, интерфейсы IPMI для управления серверами, IP-KVM и так далее.

Для таких сегментов можно использовать один или несколько неуправляемых коммутаторов с Uplink в выделенный VLAN для связи с остальной сетевой инфраструктурой. Разумеется, в этом случае теряется возможность гибкого управления целым фрагментом, но так ли уж нужно чем-то там управлять?

Некоторые мифы и заблуждения

Миф 1. Неуправляемые коммутаторы это отсталое старьё, рассчитанное на небольшие скорости (до 1 Гбит/сек. максимум), сейчас все новые современные коммутаторы управляемые.

Это далеко не так. Неуправляемые коммутаторы выпускаются и успешно применяются. Мало того, обеспечивают вполне приличные скорости. В качестве примера можно привести современные мультигигабитные коммутаторы, позволяющие повысить скорость передачи данных без замены кабельной системы.

Рисунок 1. Zyxel XGS1010-12 12-портовый неуправляемый мультигигабитный коммутатор с 2 портами 2.5G и 2 портами 10G SFP+

Миф 2. Сейчас неуправляемые коммутаторы это для не корпоративных сетей. Они не выпускаются в формфакторе 19 дюймовых стоек и содержат не больше 16-ти портов.

Это тоже не соответствует действительности стоечные неуправляемые коммутаторы выпускаются и находят свое место в том числе в корпоративных сетях. В качестве примера можно привести Zyxel GS1100-24 24-портовый гигабитный неуправляемый коммутатор с гигабитным Uplink.

Рисунок 2. Zyxel GS1100-24 24-портовый гигабитный неуправляемый коммутатор в стоечном исполнении.

Миф 3. С PoE бывают только управляемые коммутаторы. Аналогичное заблуждение: с PoE только неуправляемые.

На самом деле и управляемые, и неуправляемые коммутаторы бывают как с PoE, так и без. Все зависит от конкретной модели и линейки оборудования. Для более подробного ознакомления рекомендуем статью IP-камеры PoE, особые требования и бесперебойная работа сводим всё воедино.

Рисунок 3. Zyxel GS1300-26HP 24-портовый гигабитный (+2 Uplink) неуправляемый коммутатор для систем видеонаблюдения с расширенной поддержкой PoE.

Удивительное рядом. Можно ли управлять неуправляемым коммутатором? Казалось бы, ответ уже понятен из названия (вот и Капитан Очевидность нам то же самое говорит). Однако, что мы понимаем под словом управлять? Например, отключать или включать питание, или выполнить перезапуск устройства это ведь тоже управление? В этом случае нам помогут такие устройства как SmartPDU. Часто под управлением понимают настройку запретов и разрешений для клиентского доступа. В этом случае, например, можно не выключать порты, а настроить фильтрацию по MAC этажом выше, то есть на управляемом коммутаторе уровня распределения (агрегации). Тогда на верхний уровень будет проходить трафик только от разрешенных MAC. Разумеется, злоумышленник в качестве цели для атаки может избрать рядом стоящие компьютеры или тонкие клиенты, но для нанесения большого вреда вроде положить ядро сети фильтрация по MAC на уровне распределения (агрегации) создает определенные затруднения. В итоге коммутатор как был, так и остается неуправляемым, но мы можем управлять его окружением и даже выполнять какие-то действия с ним самим.

Ограничение неуправляемых коммутаторов

Ограничение одно и весьма большое неуправляемость. Если нужно что-то большее, чем просто соединять два порта и передавать кадры Ethernet нужно использовать управляемые коммутаторы.

Управляемые коммутаторы

В отличие от их более простых собратьев, которые выше канального уровня (2-й уровень модели OSI) не поднимались, управляемые коммутаторы выпускаются уровней L2, L2+, L3 и даже L3+.

При таком разнообразии описать все функции и особенности работы в рамках одной статьи просто нереально. Поэтому мы ограничимся описанием основных возможностей управляемых коммутаторов уровня L2.

Функции управления в коммутаторах L2

Управляемые коммутаторы L2 вещь довольно распространенная. Например, их удобно использовать на уровне доступа, чтобы гибко управлять клиентским трафиком.

Коммутаторы L2 можно встретить и на уровне ядра сети. Коммутаторы на этом участке обеспечивают скоростное взаимодействие всех ветвей сети. При такой загрузке те или иные крутые функции L3 оказываются не востребованы, а иногда просто мешают. Роль анализаторов и фильтров трафика в такой архитектуре целиком возложена на коммутаторы уровня распределения (агрегации).

Ниже приводится очень сокращенный список функций управления, характерный для коммутаторов L2. Разумеется, для коммутаторов L2+ и, тем более, L3 список возможностей будет куда как длиннее. Но даже из этого сокращенного перечня хорошо понятны отличия от их неуправляемых собратьев.

Возможность удаленной перезагрузки или выключения

Редко, но такая возможность бывает востребована. Например, перезагрузка может потребоваться при перепрошивке устройства или необходимости откатиться назад без сохранения конфигурации. Выключение коммутатора тоже может быть полезно. Например, мягкое выключение коммутатора уровня доступа может быть эффективно в качестве крайней меры при опасности массового заражения рабочих станций.

Port UP/Down

Возможность отключить порты весьма полезная возможность для поддержания требуемого уровня безопасности. Работающая сетевая розетка в тихом месте, оставленная без присмотра это потенциальная дыра. Самый простой способ избавиться от такой беды просто перевести порт на коммутаторе в состояние Down.

Пример: неиспользуемые розетки в переговорной. Изредка они нужны, когда необходимо подключить дополнительное оборудование, например, для видеоконференций, а также ПК, МФУ и другие устройства. Однако при собеседовании кандидатов для приема на работу такие свободные порты могут оказаться брешью в безопасности, которую лучше прикрыть.

Разумеется, можно постоянно бегать в серверную и отключать-подключать порты вручную, выдергивая патчкорды из коммутатора или патчпанели. Но такой подход чреват не только необходимостью постоянно держать поблизости человека, способного это проделать, но и быстрым выходом разъемов из строя. Поэтому возможности менять состояние Up-Down для каждого порта рано или поздно окупится.

Защита от петель

Ошибки в виде двойного подключения приводят к созданию петель в сетях Ethernet и лишают сеть работоспособности.

Для их защиты придуманы специальные средства в первую очередь мы говорим о семействе протоколов STP (Spanning Tree Protocol), который, кроме защиты от петель, предотвращает возникновение широковещательного шторма в сетях. Протоколы семейства STP работают на 2 уровне модели OSI (L2).

Агрегирование каналов

Позволяет объединить два или несколько портов (обычно применяется число, кратное 2) в один канал передачи данных. Один из известных проколов для агрегации LACP (Link Aggregation Control Protocol), поддерживаемый большинством Unix-like операционных систем. LACP работает в режиме Active-Active и, благодаря ему, помимо повышения отказоустойчивости увеличивается и скорость передачи данных

Поддержка VLAN

VLAN (Virtual Local Area Network) группа устройств, обменивающихся трафиком на канальном уровне (2 уровень сетевой модели OSI), хотя физически они могут быть подключены к разным коммутаторам.

Известен и обратный прием, когда один коммутатор при помощи VLAN нарезается на несколько независимых сегментов. Устройства из разных VLAN по умолчанию (без маршрутизации) недоступны на канальном уровне, не важно, подключены они к одному коммутатору или к разным. В то время как устройства из одного VLAN могут общаться между собой на канальном уровне, даже будучи подключенными к разным коммутаторам.

Это применяется как при разделении сети на подсети, например, для снижения уровня широковещательного трафика, так и для объединения устройств из различных сегментов крупной корпоративной сети в одну подсеть, организованную по единым правилам.

Например, если всей бухгалтерии, находящейся на 2-м, 3-м и 5-м этажах необходимо дать доступ к серверу 1С, но при этом запретить доступ к сети вычислительного кластера для инженерных расчетов, то разумнее всего сделать дополнительный VLAN, настроить общие ограничения, после чего приписать к нему порты всех бухгалтерских компьютеров.

QoS

Под QoS (Quality of Service) обычно подразумевают способность сети обеспечить необходимый уровень сервиса заданному сетевому трафику.

Например, в сети, при работе оборудования для видеоконференций, трафик между источником и приемником видеотрансляции будет более приоритетным, чем, например, копирование документов для инженеров техподдержки.

Существует множество различных инструментов, облегчающие подобные задачи, в том числе создание аппаратных очередей, flow-control и так далее.

Безопасность

Под безопасностью можно понимать самые разнообразные функции, например, те же VLAN.

Также среди наиболее известных: Port Security, фильтрация Layer 3 IP, фильтрация Layer 4 TCP/UDP.

Например, вот список функций безопасности для коммутаторов L2 серии GS2220:

• Port security
• Фильтрация Layer 2 MAC
• Фильтрация Layer 3 IP
• Фильтрация Layer 4 TCP/UDP
• Static MAC forwarding
• Несколько серверов RADIUS
• Несколько серверов TACACS+
• 802.1x VLAN and 802.1p assignment by RADIUS
• Аутентификация RADIUS
• Аутентификация TACACS+
• TACACS+ аккаунтинг
• RADIUS аккаунтинг
• Авторизация RADIUS
• Авторизация TACACS+
• SSH v2
• SSL
• MAC freeze
• DHCP snooping IPv4
• DHCP snooping IPv6
• ARP inspection
• Static IP-MAC-Port binding
• Policy-based security filtering
• Port isolation
• IP source guard (IPv4/IPv6)
• MAC search
• Guest VLAN
• ACL packet filtering (IPv4/IPv6)
• CPU protection
• Interface related trap enable disable (by port)
• MAC-based authentication per VLAN

Как видим, есть довольно много возможностей, которые востребованы в тех или иных обстоятельствах.

Рисунок 4. GS2220-50HP 48-портовый гигабитный PoE коммутатор L2 c 2 Uplink SFP GBE.

Управление

Возможности управления и контроля могут быть самые различные. Например, через веб-интерфейс, CLI (интерфейс командной строки), настройка через консольный порт RS-232, сохранение, извлечение и клонирование конфигурации, расписание включения PoE (для коммутаторов с PoE).

Для случаев расследования нарушений безопасности и анализа сетевых проблем интерес вызывают такие функции, как зеркалирование портов.

Старый добрый SNMP протокол тоже играет немаловажную роль, как в плане опроса и управления по протоколам SNMP v1/2c/3, так и оповещения с использованием механизма SNMP Trap.

И, наконец, последний писк моды централизованное управление через облачную систему, такую как Zyxel Nebula, позволяющую забыть о вопросах локального доступа для управления, учета оборудования и других наболевших темах.

Что в итоге

Не бывает плохих и хороших направлений развития сетевых устройств. Для каждого типа оборудования существует своя область применения. Зная особенности того или иного класса устройств, можно подобрать для каждой задачи наиболее эффективное решение.

Полезные ссылки

1. Telegram chat Zyxel
2. Форум по оборудованию Zyxel
3. Много полезного видео на канале Youtube
4. IP-камеры PoE, особые требования и бесперебойная работа сводим всё воедино
5. 12-портовый неуправляемый многогигабитный коммутатор с 2 портами 2.5G и 2 портами 10G SFP+
6. Специализированный коммутатор для систем видеонаблюдения GS1300 Series
7. 8/16/24-портовые гигабитные неуправляемые коммутаторы серии GS1100
8. Управляемые 10/28/50-портовые гигабитные коммутаторы L2 серии

Ноябрь месяц особенный. Целых два профессиональных праздника для российских безопасников: День специалиста по безопасности в России 12 ноября и Международный день защиты информации 30 ноября.

Находясь между этими датами, невольно задумываешься на тему: а что есть безопасность в принципе? И что приносит больший вред: внешние атаки или сумасшедшие ошибки, странные предрассудки и просто нежелание что-либо сделать хорошо?

Предлагаем вашему вниманию перечень вредных советов, надеюсь, они вам понравятся.

Для начала пример из жизни

Один замечательный начальник отдела ИТ искренне считал, что главное это быстро бегать по заявкам пользователей, производя впечатление максимальной загруженности. А ещё важно экономить на всём. На каждом совещании он не забывал похвалить себя и свой отдел, рассказывая, сколько чего было сэкономлено для компании.

Примечателен тот факт, что в сети ранее была создана вся необходимая структура для обеспечения стабильности, безопасности и т.д. В том числе закуплены коммутаторы L3, новенькие точки доступа Wi-Fi и много другого полезного.

Но вся эта техника просто не использовалась. А зачем? Никто этого не оценит. Зато быстро прибежавшего сисадмина сразу после телефонного звонка пользователи обязательно похвалят и даже угостят карамелькой. Пара новейших коммутаторов грустно лежала в коробке, потому что установить их было просто некому.

В итоге всё находилось в одной подсети. Ни о каких VLAN не могло быть и речи.

Разумеется, и СХД, и рабочие станции, и даже веб-сервер с внешним сайтом компании всё было в одной сети класса С. Все 254 адреса были давным-давно оприходованы. И когда возник дефицит IP адресов, то начальник отдела ИТ принял оригинальное решение: урезать диапазон динамических IP адресов и снизить время лизинга IP адресов на DHCP сервере до 1 секунды.
Таким образом, компьютеры тех сотрудников, кто приходили на работу пораньше, получали доступ к локальной сети, а опоздавшие или те, кто приходил ровно к началу рабочего дня курили бамбук. Классический вариант: кто раньше встал, того и тапки. Тем самым удалось и модернизации избежать, и дисциплину поднять, ведь теперь работники, мало того, что стараются прийти пораньше, так ещё и на работе задерживаются.
Но как же быть с теми хитрецами, кто не выключал компьютеры, уходя домой, чтобы сохранить доступ в сеть? Очень просто: все компьютеры, кроме ноутбуков топ-менеджеров в 22-00 выключались принудительно.

Кроссовый журнал не вёлся. Мало того, повсеместно применялись сплиттеры, когда два компьютера сотрудников подключались к сети через одну настенную розетку. Сплиттеры делались силами сотрудников ИТ отдела из обычных внешних телефонных розеток и хитрых патчкордов, где с одной стороны был RJ45, а с другой телефонный штекер.

К любым, даже самым простым мерам безопасности вроде обновить антивирусные базы этот начальник ИТ относился с опасением. Фразы у нас честная фирма, нам нечего скрывать и да кому мы нужны были главным определяющим фактором при принятии решений. Все работники имели права администратора на своем компьютере. Примерно треть пользователей администраторы домена. А вдруг ответственному сотруднику внезапно понадобится какой-нибудь информационный ресурс для работы? Пароли были самые простые. Пользователи ведь не должны напрягаться, чтобы запоминать сложные пароли? Сочетание 1234 уже считалось вполне нормальным.

Вы считаете это выдумкой? Или такое возможно только в маленьких компаниях вроде Я, секретарша и директор? Увы, этот пример целиком взят из жизни.

Мало того, фирма, где это происходило довольно крупная столичная компания, вполне современная, так сказать, внедряющая прогрессивные методы работы с клиентами.

Почему руководство компании терпело этот кавардак? Все вокруг искренне считали, что без этого незаменимого сотрудника в этом хаосе больше никто не разберется. Поэтому уволить такого ценного кадра, чтобы сделать резервную копию (кстати, системы резервного копирования не было тоже, её пришлось бы строить с нуля) и потом всё отстроить заново никак не решались. Всё-таки бизнес простаивать будет, а так, пусть через пень колоду, но вроде пока ещё как-то работает...

Чтобы избежать таких даже не ошибок, а просто нелепостей, предлагаем вашему вниманию перечень вредных советов. Если им не следовать, то можно избежать многих проблем.

Проектирование и документация

При построении сети не составляйте даже эскизного проекта. Все решения должны приниматься спонтанно.

Если начальство требует привлечь для проекта стороннюю организацию, то выбирайте самый дешевый вариант. Из всех предложений на рынке наймите самую низкооплачиваемую команду проектировщиков.

Наличие документации совершенно не важно, лучше если её вообще не будет. И уж точно вас не должны волновать несоответствие в документации и того, что есть в реальности.

Логическая организация и сервисы

Не разделяйте сети. Не используйте VLAN. На самом деле это придумали те, кто просто хочет побольше заморочиться.

Не используйте STP и другие средства отказоустойчивости. Чем больше петель и обрывов тем круче сеть.

Никакого контроля за IP адресами. Пусть и сервер DHCP, и статические адреса берутся из одного диапазона адресов не глядя. Если кому-то не повезло и адреса совпали дело житейское. Повезет в следующий раз. И вообще, Что наша жизнь? Игра!

Не планируйте запас IP адресов на вырост. Помните, что простой сети класса С и любимой маски 255.255.255.0 хватит на все случаи жизни.

Если у вас есть промышленное оборудование с IoT, то подключайте офисную сеть к промышленной напрямую в один и тот же сегмент сети, и всё это сразу подключите к Интернет через самый дешевый роутер.

Оборудование

Не обращайте внимание на элементную базу. Качество монтажа, качество комплектующих вещи абсолютно незначимые.

Обязательно используйте оборудование от самых разных производителей, в первую очередь неизвестных и малоизвестных фирм. Вообще зоопарк из самых диковинных образчиков сетевых устройств это удивляет воображение и дает волю фантазии. Лучше всего сочетаются ископаемые древности с новехонькой техникой от NoName производителей.

Совет: чем диковиннее железки, тем больше вероятность, что только вы будете знать, как управиться со всем этим разношерстым хозяйством. А если и не знаете, то не расстраивайтесь, ведь никто другой, скорее всего, это тоже не знает.*

При выборе оборудования не обращайте внимание на наличие русскоязычной техподдержки сами во всем разберемся.

Не используйте резервирование. Ничего страшного если что-то постоит без работы, кто-нибудь да отремонтирует.

Не заключайте договор о расширенной гарантии и поддержке. Сгорит значит сгорит. Нужно стоически принимать удары судьбы.

Не имейте спасательного фонда. Только с колес. Если что-то выйдет из строя всегда можно срочно купить устройство на замену, желательно за наличные из такого же хлама, что подвернется под руку.

Wi-Fi

При развертывании Wi-Fi не используйте гостевую сеть. Смело раздавайте всем на право и налево ключ от офисного Wi-Fi. Разумеется, пароль обязательно быть один на всех. Никаких RADUS, Dynamic Personal Pre-Shared Key (DPPSK) и прочих ненужных вещей!

Покупайте устаревшие модели точек доступа просто потому что они дешевле. Лучше брать с рук или на рынке, без гарантии и документации, от неизвестного производителя.

Разместите точку единственную доступа в самом труднодоступном изолированном месте. Глухой подвал с железной дверь вполне подойдет.

Используйте только одну точку доступа на всех. Если все жалуются, что у них не ловит пусть поищут в офисе место, где сигнал стабильней. Например, пусть все выйдут в коридор.

Поставьте рядом с точкой доступа побольше микроволновок, устройств с BlueTooth и других гаджетов, использующих радиовещание или создающее помехи.

Если начальство требует что-то сделать с Wi-Fi, который не ловит разместите несколько одинаковых точек доступа рядом друг другом. Не настраивайте никаких параметров для снижения взаимного влияния.

Не используйте никакие средства Wi-Fi роуминга. Контроллеры точек Wi-Fi (даже если за эту функцию не надо платить, и она уже есть в сетевом оборудовании) жутко обременительная вещь.

Никогда не используйте облачные решения для контроля точек доступа. Лучше всё настраивать вручную.

Не используйте удаленное управление точками доступа. Например, чтобы перезагрузить точку по питанию, лучше послать человека с раскладной лестницей.

Не используйте PoE для питания точек доступа. Если розеток недостаточно или точки находятся в трудно доступных местах используйте обычные удлинители для электропитания. Хорошей идеей также будет втыкать удлинители электропитания один в другой, чтобы получить нужную длину. Если искрит значит работает!

Не используйте шифрование в Wi-Fi. Если этого требует начальство используйте самый простой вариант. Если ваша точка доступа всё ещё поддерживает WEP используйте именно это. А то вдруг кто-то придет с устаревшим ноутбуком, который поддерживает только этот вариант...

СКС и учет оборудования

Никакой маркировки кабелей! Забудьте про кроссовый журнал. Только по памяти или методом "тыка".

Совет: Чтобы узнавать, что куда подключено, лучше всего просто выдернуть патчкорд из порта, и подождать, кто прибежит. Так можно узнать не только какое оборудование висит на данном проводе, но и насколько оно важно для работы сети.

Не ведите никакого учета оборудования. Только то, что в голове, только по памяти. Если заставляют вести документацию смело пишите в ней что попало. И, конечно, не вздумайте использовать никакую централизованную облачную систему.

Всегда прокладывайте СКС самым дешевым и устаревшим кабелем. Помните, что категория 5 (не 5E, а именно чистая пятерка) на высоких скоростях работает ничуть не хуже, чем более современные 5E, 6, 6A, 7...

Покупайте только самые дешевые патчкорды.

Не используйте патчпанели. Лучше всего провод сразу из стены обжать и воткнуть в порт оборудования.

Старый разболтанный обжимной инструмент от неизвестного производителя это самый лучший вариант для оконцовывания кабелей. Не имейте ничего хорошего и надежного.

Безопасность

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

Не используйте VPN и любое другое шифрование трафика. Честным людям нечего скрывать.

Не читайте логи безопасности. Всё равно ничего полезного там не прочтете, а если прочтете, то всё равно не поймете.

В настройках безопасности используйте самый простой режим по умолчанию.

Используйте прямое подключение через Интернет. Никаких этих дурацких вещей вроде DMZ и тому подобного. Только сразу напрямую к серверам во внутренней сети. И никаких дополнительных средств защиты!

Используйте неизвестные программы от третьих лиц вместо фирменного ПО. Например, зачем использовать Zyxel One Network, если можно воспользоваться каким-нибудь левым сканером сети с хакерского сайта, желательно ещё и крякнутой версией.

Совет. Разумеется, это всё гораздо надежнее, чем использовать облачные решения, ведь там за безопасностью следят злые админы, а это добрые люди на форуме посоветовали. Поэтому в облако ни-ни.

Не используйте антивирус. Ни на шлюзе, нигде. Все знают, что антивирус замедляет компьютеры. Пусть всё добро из Интернет незамедлительно проходит сразу на серверы и компьютеры пользователей.

Не используйте антиспам. Любая фильтрация нарушает свободу переписки. Вдруг прямо сейчас кто-то из сотрудников получит письмо о наследстве из Нигерии. Он непременно будет вам признателен за эту возможность.

Не проводите поведенческого анализа действий пользователей в сети. Пусть сотрудники качают всё, что им вздумается. Чем больше они скачают на компьютеры, тем меньше останется в Интернет, и ваша компания станет несомненно богаче.

Модернизация имеющейся сети

Всячески уклоняйтесь от модернизации. По большому счету не важно, какая пропускная способность сети. Ethernet HUB 10Mb/s ни в чем не уступает коммутатору L3 10 Gigabit Ethernet.

Совет 1. Если начальство всё же настаивает на модернизации сети, начните проводить плановые работы в самое неудобное время, например, в активные бизнес-часы. Посидят несколько часов без сети авось поумнеют и отвяжутся со своей модернизацией.

Совет 2. Составьте список из самого дорого оборудования (пусть даже вам не так нужен весь этот набор функций) и запросите для начальства счет с кругленькой цифрой. Они непременно откажутся от планов модернизации, увидев, как много денег им придется потратить.

При выполнении работ не составляйте никаких планов заранее. Всё должно происходить строго по наитию. Спонтанные решения всегда лучше тщательного предварительной проработки.

Никогда, вы слышите, никогда не читайте документацию! Даже если ничего не знаете, методом тыка действовать всегда лучше, чем вооружившись инструкцией. И вообще, это глупо тратить бесценное время на чтение, если уже сразу можно начать ковыряться в настройках и железе.

Не обновляйте firmware сетевого оборудования. Не используйте централизованную систему контроля версий прошивок.

Даже если оборудование уже куплено, просто не устанавливайте его. Ведь для этого нужно научится с ним работать, потом произвести плановую остановку, выполнить какие-то действия по замене и настройке Проще потратить деньги и отчитаться.

Совет. Если установки не избежать, то по возможности оттяните её как можно дольше, когда новое оборудование уже изрядно устареет. Так вы всегда можете сказать: "Ну вот видите, поставили новое, а получился всё равно отстой".

Мониторинг

Не контролируйте сеть. Не читайте логи. Вообще не используйте систему мониторинга. И уж точно не используйте никакие облачные системы от производителя.

Не настраивайте никакого информирования: ни по почте, ни по СМС, ни-че-го Пока не знаете о проблеме и голова не болит.

Не используйте никакую удаленную систему управления. Только личный приход в серверную избавит вас от большинства проблем.

Работа с персоналом

Не определяйте даже примерно зоны ответственности. Пусть все отвечают за всё.

Настоящий профессионал всегда знает всё. Если человек говорит, что с чем-то до этого момента не сталкивался и ему надо почитать литературу это слабак, его надо немедленно уволить и нанять всезнайку. Эффект Даннинга-Крюгера выдумали просто так, для утешения неудачников.

Никогда не признавайте свои ошибки. Лучше потихоньку замести следы или доказывать, что оно само так получилось.

Всегда нанимайте для выполнения работ случайных людей подешевле. Помните, что хороший специалист всегда соглашается поработать бесплатно, а самые крутые ещё доплатят вам, потому что работать в этой компании большая честь для них.

Никогда ничего не проверяйте и не тестируйте. Помните, что настоящие профессионалы никогда не ошибаются.

Вот и закончился наш список. Разумеется, это всего лишь шутка. Но в каждой шутки есть доля правды.

И мы выражаем поддержку тем, кто не допускает подобных вещей или вынужден бороться против подобного.

Полезные ссылки

Telegram chat Zyxel

Форум по оборудованию Zyxel

Много полезного видео на канале Youtube

Черепаха особое построение римских легионеров.

До сих пор существует практика разделять подход к безопасности для небольших компаний и для крупного бизнеса. С одной стороны, вроде бы логика в этом прослеживается. Якобы для штаб-квартиры в столице требуется высокий уровень безопасности, а для небольшого филиала уровень попроще и пониже.

Но, может быть, стоит посмотреть с другой стороны? Владельцы хотят максимально обезопасить свой бизнес, даже если он небольшой. А если государственная организация находится не в столице, то это не значит, что она должна работать с перебоями только потому, что в ИТ из-за проблем с безопасностью что-то нарушилось и никак не восстановят.

Когда вместо того, чтобы взламывать хорошо оберегаемый центральный узел, достаточно получить доступ к менее защищённой сети филиала это уже давно является классикой жанра. А сетевые администраторы постоянно решают множество интересных проблем из-за необходимости поддерживать одновременно целый зоопарк линеек оборудования: посерьёзнее и подороже для штаб-квартиры и попроще и подешевле для филиалов и небольших предприятий.

С другой стороны, и на уровне Enterprise возникает ситуация, что любое локальное решение может быть недостаточным. Проще говоря, какую сверхмощную железку ни поставишь её возможностей всё равно будет мало.

Zyxel знает про эти проблемы и предлагает комплексный подход для решения.

Во-первых, можно сделать продуктовую линейку соответствующих устройств более широкой. Включающей оборудование как для небольшой сети, так и для крупной ИТ инфраструктуры.

Во-вторых, подключить внешние облачные сервисы. Тогда небольшие мощности используемого железа компенсируются за счёт возможностей облака.

Ниже мы разберём, как это выглядит на практике. Забегая вперёд, стоит сказать, что речь пойдёт о недавно поступившей в продажу платформе USG FLEX.

Почему облачные технологии так важны?

Коллективная защита

Количество угроз постоянно растёт. Если ограничить выбор только в пользу обычных локальных средств, то потребуется всё больше ресурсов. И всё больше усилий будет уходить на постоянную модернизацию, постоянный контроль ресурсов, попытки снизить нагрузку на шлюз безопасности и так далее.

Борьба средств безопасности против сетевых угроз это уже не классический сценарий самый твёрдый наконечник против самого крепкого щита, сейчас ситуация стала значительно интересней. Представьте себе поле боя, когда количество копий, мечей, секир и других атакующих объектов несётся на вас со всех сторон, а у вас в руках один щит. Тут самое время попросить помощи у соратников. Если сложить щиты в плотную конструкцию, можно отразить гораздо больше атак с самых разных сторон, нежели в одиночку.

В 5 веке до нашей эры римская армия, до этого копирующая боевое построение греков фалангу, кардинальна сменила тактику в пользу манипульного построения пехотинцев (см. рисунок выше). Современники в то время крутили пальцем у виска, предрекая Риму скорое поражение. Однако смелый ход оправдал себя и позволил Риму уверенно побеждать на протяжении следующих 600 лет.

Примерно такой подход реализован в облаке. Облачные решения позволяют использовать мощные центральные ресурсы и перехватить большую часть угроз. С другой стороны, расширенный сбор информации об угрозах позволяет быстрее выработать средства защиты и распространить их между подписчиками.

Это интересно. Уже в следующей прошивке будет выпущена полноценная поддержка централизованного облака Zyxel Nebula. Появится возможность использовать облачные ресурсы не только для защиты, но и реализовать централизованное управление крупной сетевой инфраструктурой, подключившись к облаку. Новая прошивка планируется в марте 2021 года.

Что делается для повышения защиты?

В облако Zyxel Security Cloud поступают данные об угрозах из различных источников. В свою очередь межсетевые экраны серии USG FLEX используют облачную базу данных в режиме Cloud Query Express, которая включает миллиарды сигнатур.

То есть это не скромная локальная антивирусная база, целиком загружаемая из Интернет, а гораздо более мощная конструкция. Если говорить о скорости взаимодействия, то функция Cloud Query проверяет хэш-код подозрительного файла за несколько секунд и при этом точно диагностирует угрозу.

Если говорить о количественных показателях, то при работе в режиме Cloud Query Express были получены результаты дополнительного прироста производительности UTM до 500%. При этом уровень потребления локальных вычислительных ресурсов не растёт, а снижается за счёт использования облачных мощностей, высвобождая локальные ресурсы для других задач.

Проще говоря, есть какое-то вычислительное устройство. Мы можем её нагрузить анализом трафика, или можем озадачить другими вещами, например, управлением точками доступа. И таких полезных задач в единицу времени может быть решено гораздо больше благодаря облаку.

В целом, за счёт использование более современной платформы рост производительности межсетевого экрана достигает 125%.

Откуда поступают данные о вредоносных элементах?

В облачной базе данных, поддерживающей USG FLEX, собираются подробные сведения, предоставляемые ведущими компаниями и организациями в области кибербезопасности для накопления информации о проблемных файлах и данных об угрозах. Сбор информации происходит постоянно в режиме реального времени. Мощная база данных позволяет повысить точность выявления вредоносного кода.

Отдельно стоит отметить хорошую контекстную фильтрацию, а также специальный фильтр CTIRU (Counter-Terrorism Internet Referral Unit) для ограничения доступа к экстремистской информации. В последнее время, к сожалению, эта функция становится необходимой.

Давайте попробуем галопом-по-европам пробежаться по основным ступенькам защиты, предоставляемым USG FLEX.

Среди функций безопасности стоит выделить такие возможности, как:

• антивирусная защита;
• антиспам;
• фильтрация URL и IDP для отражения атак извне;
• Патруль приложений;
• контентная фильтрация (вместе с Патрулем приложений эти функции блокируют доступ пользователей к посторонним приложениям и web-сайтам);
• инспекция SSL с поддержкой TLS 1.3. (для анализа защищённого трафика).

Применение этих сервисов позволяет ликвидировать слабые места в системе защиты корпоративной сети.

Аналитические отчёты и углублённый анализ угроз

В принципе, у Zyxel всегда было неплохо со статистикой и построение отчётов. В USG FLEX это поучило дальнейшее развитие. Графические диаграммы по статистике угроз, сводка статистики по трафику выводятся на главной консоли межсетевых экранов, это позволяет быстро понять, что происходит в сети.

Сервис SecuReporter предоставляет детальный анализ угроз, что даёт возможность вовремя проследить изменения в сети и вовремя избежать неприятностей.

Когда все события отображаются на одной централизованной консоли это удобно. Управлять разными клиентами и устройствами теперь стало проще.

Не только безопасность

Как говорится, безопасность безопасностью, но ещё и работать надо. Что предлагается для организации работы в USG FLEX?

Много разных VPN

Серия USG FLEX поддерживает VPN на основе IPsec, L2TP, SSL. Это позволяет не только организовать межсайтовое взаимодействие по защищённым каналам (полезно для крупных организаций с большим числом филиалов), но и наладить безопасный доступ к корпоративной сети удалённым работникам или малым полевым офисам.

Немаловажную роль играют возможности удалённой настройки. Удалённый доступ с нулевой конфигурацией упрощает настройку. В том числе, даже если нет ИТ-поддержки на местах всё равно можно настроить подключение по VPN к удалённому офису.

Для чего нужна расширенная подписка?

При построении защищённых сетей возникает противоречивая ситуация. С одной стороны, необходимо установить высокий уровень безопасности без разделения предприятий на малые и большие (бедные и богатые, столичные и провинциальные и так далее). С другой стороны, для каждой ситуации необходим индивидуальный подход. Порой приходится работать максимально гибко, с привлечением набора дополнительных, но необязательных функций. Для этого и существует расширенная подписка

Расширенная подписка добавляет лицензии на Unified Threat Management для поддержки функций:

• Web Filtering Блокирование доступа к опасным и подозрительным web-сайтам;
• IPS (IDP) проверка пакетов на наличие вредоносного кода;
• Application Patrol анализ поведения приложений, их классификация ранжированный подход в использовании сетевых ресурсов;
• Anti-Malware проверка файлов и выявление опасных сюрпризов с использованием облачных мощностей;
• Email Security поиск и блокировка спама, а также защита от фишинга посредством электронной почты;
• SecuReporter расширенный анализ в области безопасности, построение подробных отчётов.

Пакет сервисов Hospitality

USG FLEX создан не только для обеспечения прямых функций безопасности, но и для контроля сети. Набор функций для Hospitality позволяет автоматически обнаруживать и производить конфигурацию точек доступа. Также в пакет входят: управление хот-спотами (биллинг), управление точками доступа с поддержкой Wi-Fi 6, различные функции управления доступом к сети и увеличение максимально допустимого числа авторизованных пользователей.

Проще говоря, Hospitality Pack служит именно для расширения возможностей контроллера беспроводной сети (сам по себе встроенный контроллер уже может автоматически обнаруживать и производить конфигурацию до 8 точек доступа, в том числе Wi-Fi 6). Hospitality Pack позволяет увеличить количество точек и авторизованных пользователей до максимума, добавить возможности биллинга и поддержки принтеров печати квитанций.

Есть отдельные бессрочные лицензии на увеличение количества точек (+ 2/4/8/64 AP), на увеличение количества авторизованных пользователей (+100/300) и на функцию биллинга с поддержкой принтеров.

Примечание. Hospitality это индустрия гостеприимства (отели, рестораны, кафе...), и для неё больше всего подходит данный набор функций. Однако новые возможности не ограничены этой сферой бизнеса. Например, увеличение количества точек и авторизованных пользователей набор может потребоваться в крупных компаниях с большим количеством приходящих сотрудников.

Панель инструментов серии USG FLEX предоставляет удобную для пользователя сводку трафика и визуальную статистику угроз.

SecuReporter расширяет возможности для дальнейшего анализа угроз с разработкой функции корреляции. Это позволяет не ликвидировать последствия, а предотвращать опасные события. Централизованный подход к анализу сетевых операций позволяет управлять сразу несколькими клиентами.

Миграция без усилий и проблем

Если используются лицензии серии USG в этом случае USG FLEX обеспечивает бесшовную миграцию лицензий. Можно обновить систему защиты до новой комплектной лицензии UTM 6-в-1 более полной версии защиты. Подробнее об этом можно посмотреть в видео.

Подробнее об устройствах USG FLEX

Прежде чем приступим к описанию, остановимся на ключевых моментах.

Как было сказано выше, очень важно обеспечить единообразие среди используемого оборудования. Зачастую системные администраторы сталкиваются с проблемой, когда слабое оборудование уровня СМБ или даже SOHO (начальный уровень) требуется увязать с мощными решениями уровня Enterprise.

Тут возникает масса интересных сюрпризов. Мало того, что слабые устройства для совсем малых (квартирных) сетей могут не поддерживать нужные протоколы (или поддерживать их только на бумаге), так ещё и настройка всего этого хозяйства может занять значительное время. Несмотря на то, что процедура настроек, в принципе, похожа, на практике могут возникать неожиданные нюансы. При этом разработчики интерфейсов управления порой проявляют недюжинную фантазию, а вот желание написать хорошую подробную документацию встречается гораздо реже.

В Zyxel при разработке новых устройств документации уделяется большое значение, а широкая линейка позволяет унифицировать операции по настройке и обслуживанию.

Совет. Чтобы получить устройство на тест, нужно прислать запрос по адресу: Sales_rusc@zyxel.eu

Если говорить про USG Flex, то данная линейка на данный момент содержит целых 5 устройств:

• USG FLEX 100 и версию с точкой доступа Wi-Fi USG FLEX 100W.
• USG FLEX 200;
• USG FLEX 500;
• USG FLEX 700.

Важно отметить, что все они поддерживают одинаковые протоколы VPN, функцию контроллера точек доступа (8 точек со стандартной лицензией при покупке), антивирус, антиспам, IDP (обнаружение и предотвращение вторжений), Патруль приложений, контентную фильтрацию, возможность подключить SecuReporter Premium по подписке.

Ниже мы остановимся подробно на каждой модели USG FLEX.

Описание USG FLEX 100

Это самый простой, экономичный, но, тем не менее, надёжный вариант защиты для небольших филиалов и малых сетей.

Устройство мало потребляет, питание осуществляется от внешнего адаптера на 2A, 12V постоянного тока.

Имеет 4 порта LAN/DMZ, 1 порт WAN, 1 порт SFP.

Также присутствует порт USB, через который можно подключит USB-модем для создания резервного канала.

Рисунок 1. Внешний вид USG FLEX 100.

Несколько слов о USG FLEX 100W

В принципе, модель USG FLEX 100W отличается от модели USG FLEX 100 только встроенным модулем Wi-Fi.

Характеристики Wi-Fi:

• Соответствие стандартам 802.11 a/b/g/n/ac
• Частота радиосвязи 2.4 / 5 ГГц
• Количество радио модулей 2
• Количество SSID 8
• Количество антенн 3 съёмные антенны
• Усиление антенны 2 дБи @ 2.4 ГГц
• Скорость передачи данных 802.11n: до 450 Мбит/сек, 802.11ac: до 1300 Мбит/сек.

Рисунок 2. Внешний вид USG FLEX 100W.

Как уже было сказано выше, основные отличия лежат в количественных показателях:

• Пропускная способность SPI (Мбит/сёк) 900
• Пропускная способность VPN (Мбит/сёк) 270
• Пропускная способность IDP(Мбит/сёк) 540
• Пропускная способность AV (Мбит/сёк) 360
• Пропускная способность UTM (AV и IDP) 360
• Максимум одновременных TCP сессий 300,000
• Максимум одновременных туннелей IPSec 40
• Максимум одновременных туннелей SSL 30

Описание USG FLEX 200

А это уже вариант немного мощнее.

Имеет 4 порта LAN/DMZ, 1 порт SFP, но есть отличие 2 два порта WAN (вместо одного в USG FLEX 100), что позволяет организовать отказоустойчивую схему с двумя проводными провайдерами.

Для питания нужен уже блок на 2,5A 12V постоянного тока.

Рисунок 3. Внешний вид USG FLEX 200.

По производительности и пропускной способности показатели также выше:

• Пропускная способность SPI (Мбит/сёк) 1,800
• Пропускная способность VPN (Мбит/сёк) 450
• Пропускная способность IDP(Мбит/сёк) 1,100
• Пропускная способность AV (Мбит/сёк) 570
• Пропускная способность UTM (AV и IDP) 550
• Максимум одновременных TCP сессий 600,000
• Максимум одновременных туннелей IPSec 100
• Максимум одновременных туннелей SSL 60
• VLAN интерфейсы 16

Если сравнивать с более мощными моделями (о которых пойдет речь ниже), USG FLEX 200 всё-таки создан для сравнительно небольших нагрузок и кабинетного размещения. Об этом говорит и небольшой корпус, и внешний блок питания.

Но, тем не менее, USG FLEX 200 способен обеспечить хорошую поддержку сети в плане безопасности и организации работы сетевых сервисов, таких как управление точками доступа.

Описание USG FLEX 500

Это ещё более мощное устройство, имеет 7 конфигурируемых портов. Также присутствует 1 порт SFP и 2 порта USB 3.0

Примечание. Конфигурируемые порты позволяют избежать привязки к конкретному сценарию использования: нужно 1 порт WAN и 6 LAN нет проблем, нужно организовать отказоустойчивую схему на 3 проводных канала можно легко переназначить 3 WAN и 4 LAN порта.

Видно, что это универсальное устройство для решения широкого спектра задач.

Для питания нужен ещё более мощный блок 4.17А, 12V постоянного тока.

Для охлаждения внутри корпуса используется вентилятор, поэтому может создаваться шум. USG FLEX 500 скорее устройство для серверной или для кроссовой комнаты, нежели для компактного размещения в офисном пространстве.

Рисунок 4. Внешний вид USG FLEX 500.

Разумеется, по сравнению с предыдущими моделями, производительность отличается в большую сторону:

• Пропускная способность SPI (Мбит/сёк) 2,300
• Пропускная способность VPN (Мбит/сёк) 810
• Пропускная способность IDP(Мбит/сёк) 1,500
• Пропускная способность AV (Мбит/сёк) 800
• Пропускная способность UTM (AV и IDP) 800
• Максимум одновременных TCP сессий 1,000,000
• Максимум одновременных туннелей IPSec 300
• Максимум одновременных туннелей SSL 150
• VLAN интерфейсы 64

Описание USG FLEX 700

Это устройство появилось позже всех, его можно назвать флагманом линейки. Имеет целых 12 конфигурируемых портов, 2 порта SFP, 2 порта USB 3.0

Питание производится из стандартной сети переменного тока 100-240V, 50/60Hz, ~2.5А.

Для охлаждения применяется встроенный вентилятор.

Это классическое устройство для серверной или кроссовой, с широкими возможностями как для обеспечения безопасности, так и для организации работы сети.

Рисунок 5. Внешний вид USG FLEX 700.

Имеет самую высокую производительность из всех USG FLEX на данный момент

• Пропускная способность SPI (Мбит/сёк) 5,400
• Пропускная способность VPN (Мбит/сёк) 1,100
• Пропускная способность IDP(Мбит/сёк) 2,000
• Пропускная способность AV (Мбит/сёк) 1,450
• Пропускная способность UTM (AV и IDP) 1,350
• Максимум одновременных TCP сессий 1,600,000
• Максимум одновременных туннелей IPSec 500
• Максимум одновременных туннелей SSL 150
• VLAN интерфейсы 128

Подведём небольшой итог:

• И большие и малые сети требуют заботы о безопасности.
• Облачные решение упрощают построение и обслуживание защищённой сети.
• Новая линейка Zyxel USG FLEX как раз для этого и создавалась.

Полезные ссылки

1. Telegram chat Zyxel
2. Форум по оборудованию Zyxel
3. Много полезного видео на канале Youtube
4. Преимущества USG FLEX
5. Полезная статья в КБ о USG FLEX
6. Видео: Перенос лицензий с устройств USG на устройства USG FLEX Series
7. Описание USG-FLEX-100
8. Описание USG-FLEX-100W
9. Описание USG-FLEX-200
10. Описание USG-FLEX-500
11. Описание USG-FLEX-700

Но это же в любом учебнике по сетям написано! возмутится нетерпеливый читатель.

Однако, не нужно спешить с выводами. Написано по этому поводу много, но, к сожалению, далеко не всегда понятным языком. Вот и рождаются вредные мифы.

Поэтому не всегда в точности понятно, когда и куда какое устройство приспособить. Представьте, звонит сисадмину начальник ИТ отдела и требует быстро подобрать в запас очень бюджетный коммутатор, и чтобы все основные функции закрывал, пока деньги не перехватили и настроение у директора хорошее.

И начинает наш герой ломать голову: взять L3, чтобы на все случаи жизни, но он дорогой или взять подешевле L2, а вдруг прогадаешь Да ещё этот L2+ непонятно что за промежуточный уровень...

Подобные сомнения иногда обуревают даже опытных специалистов, когда встаёт вопрос выбора устройств при жёстком лимите бюджета.

Для начала опровергнем основные мифы

Коммутатор L3 имеет большую пропускную способность чем L2?

Такой взаимосвязи нет. Всё зависит от аппаратного и программного обеспечения (firmware), размещённых портов (интерфейсов), поддержки соответствующих стандартов.

Разумеется, связь с использованием коммутатора уровня L3 через сетевой интерфейс 1Gb/s будет медленнее, чем с использованием коммутатора L2 через 10 Gb/s.

Возможно, этот миф связан с тем, что коммутаторы L3 поддерживают больше функций, что находит отражение в аппаратном обеспечении: быстрее процессор, больше памяти, нежели чем у коммутаторов L2 того же поколения. Но, во-первых, иногда коммутаторы L2 тоже выпускаются на базе мощных контроллеров, позволяющих быстро обрабатывать служебные данные и пересылать кадры Ethernet, во-вторых, даже усиленному железу коммутатора L3 есть чем заняться: управлять VLAN, анализировать ACL на основе IP и так далее. Поэтому если судить по загрузке, однозначно ответить на вопрос: Какой коммутатор мощнее? не получится.

Коммутаторы L3 более современные, а L2 уже вчерашний день?

Это вовсе не так. На сегодняшний день выпускаются как коммутаторы L2, так и коммутаторы L3. Коммутаторов уровня L2 выпускается достаточно много, потому что работать им приходится чаще всего на уровне доступа (пользователей), где и портов, и коммутаторов требуется значительно больше.

Немного теории в вопросах и ответах

Откуда взялись эти названия L2, L3?

Из 7 уровней модели OSI.

Коммутатор L2 работает на втором, канальном уровне.

Коммутатор L3 работает как на втором, так и на третьем уровне.

Примечание. Сетевая модель OSI (The Open Systems Interconnection model) определяет различные уровни взаимодействия систем. При таком разбиении каждому уровню отводится своя роль и назначены определённые функции для взаимодействия по сети.

Таблица 1. Уровни модели OSI ISO

А просто, понятно и в двух словах?

В самом простом случае коммутатор служит для связи нескольких устройств локальной сети (LAN). Этими устройствами могут быть, например, отдельные компьютеры или другие коммутаторы.

Именно так работает коммутатор L2 на уровне Ethernet: анализирует аппаратные MAC адреса, заносит их в таблицу коммутации и согласно этой таблице перераспределяет трафик.

Коммутатор L3 тоже может анализировать пакеты по MAC адресам и перенаправлять кадры между подключёнными устройствами, но, помимо пересылки Ethernet кадров, он умеет перенаправлять трафик, основываясь на анализе IP адресов и выполнять функции внутреннего маршрутизатора.

А подробней?

Коммутатор L2 обрабатывает и регистрирует MAC адреса фреймов, осуществляет физическую адресацию и управления потоком данных. Некоторые дополнительные функции: VLAN, QoS поддерживаются только на уровне, необходимом для передачи параметров или для участия в общей схеме сети. Например, на коммутаторе L2 можно прописать несколько VLAN, но нельзя настроить полноценную маршрутизацию между ними, для этого уже нужен коммутатор L3. Проще говоря, коммутатор уровня L2 обеспечивает некоторые дополнительные функции, но не управляет ими в масштабе сети.

В отличие от своих более простых собратьев, коммутаторы L3 могут брать на себя функции маршрутизаторов, в том числе проверку логической адресации и выбор пути (маршрута) доставки данных. Благодаря повсеместному внедрению стека протоколов TCP/IP, коммутаторы уровня L3 являются важной частью сети, так как могут выполнять пересылку пакетов не только на основе анализа MAC адресов, но и поднимаясь на этаж выше, то есть на основе IP адресов и соответствующих протоколов маршрутизации

Разумеется, никому в голову не придёт строить внешнюю разветвлённую сеть с BGP маршрутизацией на базе коммутаторов. Однако для внутренней маршрутизации в пределах локальной сети такой вариант вполне подходит. Мало того, это позволяет экономить на приобретении дополнительных устройств (маршрутизаторов), использовать универсальный подход к организации сети.

Из-за поддержки многих функций коммутатор уровня L3 имеют более сложную внутреннюю конфигурацию и, соответственно, стоят дороже. Иногда пользователь встаёт перед выбором: купить более простой и бюджетный вариант с Layer 2 или более дорогой и продвинутый Layer 3.

А что за дополнительные уровни: доступа, агрегации, ядра?

Помимо уровней модели OSI: Layer 2, Layer 3, в литературе часто упоминаются уровень доступа, уровень агрегации, уровень ядра сети.

Подробней об этом мы писали в статье Построение сетевой инфраструктуры на базе Nebula. Часть 2 пример сети

Если описать кратко:

• Уровень доступа группа коммутаторов, основной задачей которых является подключения пользователей к сети.
• Уровень агрегации (или уровень распределения) следующая группа, которая объединяет коммутаторы уровня доступа, позволяет выполнить настройки управления и маршрутизации и делегирует Uplink на более высокий уровень уровень ядра сети.
• Уровень ядра сети центральный узел, который объединяет все ветви коммутаторов уровня агрегации с подключёнными коммутаторами уровня доступа в единую сеть.

Если сравнивать с древовидной структурой, то ядро сети это ствол, уровень агрегации/распределения это крупные ветви, коммутаторы уровня доступа мелкие веточки, а компьютеры пользователей это листья.

Рисунок 1. Уровни построения локальной сети.

Коммутаторы, которые служат для объединения других коммутаторов в единую сеть, называют коммутаторы уровня агрегации (или коммутаторы уровня распределения).

Если же говорить про уровень ядра сети, то для него существуют свои мощные коммутаторы, основная задача которых максимально быстро передавать трафик. Функции управления при этом довольно часто делегируется на уровень агрегации.

Есть ли связь между понятиями уровней L2 и L3 с уровнем доступа и уровнем агрегации? Традиционно считается, что для уровня доступа лучше подходят коммутаторы L2 (в первую очередь из-за более низкой цены, а для уровня агрегации лучше выбирать L3 ради повышенной функциональности.

Чем хорош такой подход? Устанавливать более функциональные и дорогие коммутаторы уровня L3 на уровне доступа может быть неоправданным шагом, если их функции маршрутизации и контроля не будут востребованы. А этих же функций будет недоставать более простым коммутаторам L2 на уровне агрегации (распределения).

Теория это отлично, но начальник требует побыстрее подобрать подходящий коммутатор...

Если есть сомнения какой уровень коммутатора выбрать: уровня 2 или уровня 3, во главу угла нужно ставить вопрос, где его предполагается использовать. Если в наличии только небольшая сеть, позволяющая всем работать в единственном широковещательном домене, можно остановить свой выбор на одном или двух коммутаторах L2.

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

Если необходим коммутатор для объединения (агрегирования) нескольких простых коммутаторов доступа пользователей для этой роли лучше подходит коммутатор уровня 3. Помимо объединения в сеть, он может выполнять маршрутизацию между VLAN, управлять прохождением трафика при помощи ACL (Access Control List), обеспечивать заданный уровень ширины пропускания (QoS) и так далее.

Ещё одна область, где коммутаторы L3 часто бывают востребованы если необходимо обеспечить повышенные требования к безопасности, например, более гибкое разграничение доступа. Некоторые функции, доступные для этого уровня, например, управление трафиком на уровне IP адресов, будут неосуществимы стандартными средства уровня L2.

Чем отличаются коммутаторы L2 и L2+

L2+ это коммутатор второго уровня с добавленными функциями. Например, может быть добавлена поддержка статической маршрутизации, физического объединения в стек нескольких коммутаторов для отказоустойчивости, дополнительные функции безопасности и так далее.

Примечание. В сравнительной таблице, приводимой в конце статьи, можно видеть, что уровни L2 и L2+ могут различаться на одну-две функции. Однако даже такая небольшая деталь может оказаться критичной, например, для вопросов отказоустойчивости или безопасности.

От слова к делу! Сравним разные коммутаторы на примере

Для наглядности выберем три модели примерно одного уровня. Понятно, что коммутаторы L2, L2+ и L3 здорово отличаются по функциям. Поэтому приходится использовать общие признаки. Например, сравнивать коммутаторы на 5 и 50 портов (включая Uplink) будет некорректно.

В итоге мы выбрали три коммутатора:

• L3 XGS4600-32;
• L2+ XGS2210-28;
• L2 GS2220-28.

Обратите внимание, что внешне устройств довольно похожи, чего не скажешь об их возможностях и предполагаемых ролях. Для наглядности ниже приводим небольшой фрагмент сравнительной таблицы функций.

А функций у этих моделей коммутаторов очень много. Чтобы не пытаться объять необъятное, мы выбрали наиболее очевидные функциональные области: управление трафиком, безопасность и маршрутизация. Другие группы опций тоже отличаются, но не так очевидно.

Zyxel XGS4600-32 коммутатор Layer 3

• Имеет 24 гигабитных порта под витую пару, 4 порта Combo (SFP/RJ45) и четыре интегрированных 10-Gigabit SFP+
• Поддерживает объединение в физический стек с использованием одного или двух слотов 10-Gigabit SFP+.
• Поддерживает и статическую, и динамическую маршрутизацию.
• Имеет два отдельных разъёма подключения питания.

Рисунок 2. Коммутатор Zyxel XGS4600-32 коммутатор Layer 3.

Zyxel XGS2210 коммутатор Layer 2+

Одно из предназначений создание сети для передачи трафика VoIP, видеоконференций, IPTV и IP-камер видеонаблюдения наблюдения и управление трафиком современных конвергентных приложений.

Поддерживает объединение в физический стек с помощью двух портов 10-Gigabit SFP+.

Поддерживает PoE (стандарты IEEE 802.3af PoE и 802.3at PoE Plus) до 30Ватт на порт для питания устройств с большей потребляемой мощностью, например, это могут быть точки доступа 802.11ac и IP-видеотелефоны.

В данной модели присутствуют дополнительные средства поддержки безопасности, например, IP source guard, DHCP snooping и ARP inspection, механизмы фильтрации L2, L3 и L4, функцию MAC freeze, изоляцию портов и создание гостевой VLAN.

Добавлены элементы статической маршрутизации IPv4/v6 и назначение DHCP relay с конкретным IP интерфейсом отправителя.

Рисунок 3. Zyxel XGS2210 коммутатор Layer 2+

Zyxel GS2220 коммутатор Layer 2

Интересно, что серия GS2220 это гибридные коммутаторы с доступными вариантами управления: через облако Zyxel Nebula, через локальное подключение, плюс поддержка SNMP.

Из интересных функций можно выделить L2 multicast, IGMP snooping, Multicast VLAN Registration (MVR).
Данная модель неплохо подходит и для обеспечения сетевой среды VoIP, видеоконференций и IPTV.

Рисунок 4. Zyxel GS2220 коммутатор Layer 2.

Это интересно

Компания Zyxel Networks сообщила о поддержке своих коммутаторов в специализированном режиме Networked AV (созданного совместно с компанией ATEN), позволяющего облегчить внедрение AV-систем на базе коммутаторов и повысить эффективность их использования.

Стоит отметить специальную программу мастер настройки. Она специально разработана для удобного управления функциями, которые часто используются при настройке сетей потоковой передачи аудио/видео.

Также появилась новая консоль Networked AV dashboard для контроля основных параметров: данные о портах, расход электроэнергии, и другая информация, благодаря которой можно сразу проверить текущее состояние сети и настроить коммутатор.

Для гигабитных управляемых коммутаторов второго уровня серии GS2220 режим Networked AV доступен с сентября 2020 года (нужно обновить микропрограмму до версии v4.70 или более поздней). Для коммутаторов серии XGS2210 доступ ожидается до конца 2020 года.

Таблица 2. Сравнение коммутаторов XGS4600-32 (L3), XGS2210-28 (L2+) и GS2220-28 (L2).

* Функции, доступные также в облачном режиме управления.

Небольшие итоги

Каждая вещь хороша на своём месте (спасибо, капитан Очевидность).

Нет смысла переплачивать за более высокий уровень коммутатора только потому, что он кажется круче. В то же время скупой платит дважды, и нехватка критической функции может потребовать дополнительных расходов в виде замены коммутатора.

В некоторых случаях выручают коммутаторы L2+ как компромиссный вариант. Функции, которых нет в L2, но есть в L2+ могут быть весьма полезны и способны вывести сетевую инфраструктуру на новый уровень отказоустойчивости и безопасности

Полезные ссылки

1. Telegram chat Zyxel
2. Форум по оборудованию Zyxel
3. Много полезного видео на канале Youtube
4. Коммутаторы Zyxel L3 серии XGS4600
5. Коммутаторы Zyxel L2+ серии XGS2210
6. Коммутаторы Zyxel L2 серии GS2220
7. Построение сетевой инфраструктуры на базе Nebula. Часть 1 задачи и решения
8. Построение сетевой инфраструктуры на базе Nebula. Часть 2 пример сети

Как решить вопрос с аутентификацией, если инфраструктура совсем небольшая и под рукой нет ничего кроме аппаратного межсетевого экрана? Как обойтись без настройки второго сервера RADIUS и всё равно реализовать отказоустойчивое решение? И как выглядит вариант, когда всё управляется из облака?
В этой статье рассказывается сразу о двух возможностях аутентификации: встроенного сервиса аутентификации на межсетевом экране и аутентификации в Zyxel Nebula.

В статье Настройка WPA2 Enterprise c RADIUS мы описали вариант использования корпоративной схемы аутентификации с внешним сервером RADIUS. Для создания такой системы нужен ни много ни мало сам сервер RADIUS (для этого нам понадобилось развернуть на отдельной машине с Linux пакет Free RADIUS).

Напомню, для чего это нужно. Когда используется простая схема WPA2 Personal c единственным ключом на все беспроводные устройства это годится только для небольших сетей. Основное ограничение в том, что заменить такой ключ весьма непросто придётся вводить заново на всех устройствах всех пользователей, кто подключается к WiFi сети. А менять рано или поздно придётся. Среди причин наиболее частыми называют компрометацию со стороны пользователей и сугубо кадровые процессы: увольнение, перевод на другую работу и так далее.

Примечание. Ситуация осложняется, когда приходится иметь дело с VIP пользователями. Застать их на месте, чтобы заменить ключ, довольно трудно, кроме всего прочего у них обычно целая куча устройств: смартфон, ноутбук, планшет и даже телевизор. И всем нужно обращаться в общую сеть и далее в Интернет.

Но что делать, если такая в виде отдельного сервера RADIUS (пусть даже и виртуального) недоступна. В статье Что останется в серверной прорисовывается вполне понятная картина: по вполне естественным причинам в небольшой серверной в лучшем случае остаётся сетевое оборудование для удалённого доступа и вспомогательные системы вроде NAS для резервных копий рабочих станций.

Для совсем маленьких организаций может встать ещё и такой вопрос: А где размещать виртуальную машину с RADIUS?

Можно арендовать виртуалку на облачном сервисе. Это стоит определённых денег. Мало того, о такой виртуальной машине всё равно нужно заботиться: проводить обновление, аудит безопасности, читать логи, следить за состоянием файловой системы и так далее То есть это вполне себе ощутимые затраты: как финансовые, так и трудовые. И всё только ради RADIUS?

А можно как-то по-другому? Чтобы и сервис авторизации получить, и виртуалку разворачивать не пришлось и сделать всё это бесплатно? Оказывается, у Zyxel есть целых два варианта, как это можно сделать красиво, просто и без лишних затрат.

Вначале рассмотрим способ, близкий к уже знакомому традиционному сервису.

Проверьте может быть RADIUS есть в вашем шлюзе?

В шлюзах от Zyxel уже есть встроенный сервис RADIUS. То есть если используется, например, сетевой экран, то в нём уже есть всё необходимое для аутентификации WPA2 Enterprise.

Достаточно просто приобрести нужное устройство, подключиться к нему удалённо и выполнить настройки.

Практически в любой современной ИТ инфраструктуре можно встретить межсетевой экран для доступа в Интернет. В случае с оборудованием от Zyxel можно получить не только защиту от внешних (и внутренних!) атак, но и систему аутентификации WPA2 Enterprise c реквизитами для отдельных пользователей, и ничего устанавливать не надо, всё работает из коробки.

Однако, любая замечательная функция без конкретного описания так и останется потенциальной возможностью. Чтобы этого не произошло в этот раз, проиллюстрируем на примере как можно всё настроить, используя уже имеющиеся средства.

В качестве шлюза, сервера RADIUS у нас используется облачный межсетевой экран. Помимо основных обязанностей он может выполнять функции контроллера точек доступа.

Мы уже писали ранее об устройствах из этой линейке в статье Убираем старые проблемы защиты крупных и малых сетей.

Для примера такой схемы аутентификации прекрасно подойдёт USG FLEX 200 уже не начальный уровень, но и не топовая модель в линейке. Эта модель хорошо подходит в качестве межсетевого экрана для небольших и средних офисов.

Коротко о межсетевом экране USG FLEX 200:

• поддержка облачных технологий Zyxel Security Cloud (в первую очередь это отличный инструмент для сбора информации об угрозах из различных источников) и Cloud Query Express (облачная база данных для надёжной защиты от вирусов);
• фильтрация URL и IDP для отражения атак извне;
• патруль приложений и Контентная фильтрация для контроля доступа пользователей к приложениям и web-сайтам.

Рисунок 1. Межсетевой экран USG FLEX 200.

В качестве точки для нашей демонстрации выберем ту же самую NWA210AX, уже знакомую нам по статье Настройка WPA2 Enterprise c RADIUS.

Коротко о точке доступа WA210AX устройстве:

• поддержка Wi-Fi 6;
• 6 пространственных потоков (4x4:4 в 5 ГГц, 2x2:2 в 2,4 ГГц);
• поддержка OFDMA и MUMIMO;
• имеется как локальное, так и облачное управление через Zyxel Nebula.

Рисунок 2. Точка доступа NWA210AX.

В итоге мы должны получить тот же самый результат, что и с внешним сервером, но без расходования дополнительных ресурсов на хостинг виртуальной машины и без лишних телодвижений по развёртыванию сервиса RADIUS, настройке firewalll, настройке средств безопасности и так далее.

От слова к делу настраиваем встроенный сервис RADIUS

Начинаем с получения IP адреса. Для этого воспользуемся утилитой ZON Zyxel One Network Utility, которая собирает данные обо всех устройствах Zyxel в доступном сегменте сети.

Примечание. На самом деле у программы ZON есть много других замечательных функций, но описание всех возможностей выходит за рамки данной статьи.

Рисунок 3. Утилита ZON для нашего примера

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

Настройка службы на межсетевом экране

Для начала настроим службу аутентификации на межсетевом экране. Для этого необходимо зайти на веб-интерфейс. Вводим его адрес в браузере, переходим на нужную страницу. Тут у нас спросят логин и пароль. Так как это первый запуск, то используем значения по умолчанию: admin и 1234, нажимаем кнопку Login и попадаем в панель Dashboard.

Рисунок 4. Окно входа на USG FLEX 200.

Рисунок 5. Dashboard на USG FLEX 200.

Далее переходим в раздел Configuration System Auth. Server.

Первое что необходимо включить саму службу сервера аутентификации

Активируем элемент Enable Authentication Server, нажимаем Apply внизу экрана и наш сервис переходит в активное состояние.

Рисунок 6. Enable Authentication Server.

Теперь, действуя по той же схеме, что и с внешним RADIUS, в области Trusted Client необходимо указать сегмент сети, откуда будут поступать запросы и там же записать секретный ключ для аутентификации.

Нажимаем экранную кнопку Add для вызова окна Add Trusted Client.

Рисунок 7. Окно Add Trusted Client.

Соответственно, указываем в поле Profile Name имя сети, в нашем случае inside_network

IP Address и Netmask (адрес и маску подсети) 192.168.1.0 255.255.255.0.

Поле Description заполняется по желанию.

Не забываем про галочку Activate, иначе данная клиентская сеть будет игнорироваться нашим сервером аутентификации.

Нажимаем OK для окна Add Trusted Client и потом кнопку Apply для всего раздела Auth. Server. Всё, наши значения должны примениться.

После этого переходим в раздел Configuration Object User/Group и добавляем учётные записи для нужных пользователей.

Рисунок 8. Учётные записи User/Group в разделе Object (Configuration).

Нажимаем Add появится окно Add A User.

Рисунок 9. Окно ввода пользователя.

В принципе, нам нужно ввести только имя пользователя и пароль, можно ещё добавить описание. Другие настройки лучше оставить без изменений.

Рисунок 10. Новые учётные записи: ivan и rodeon с пометкой WiFi User.

Настройка точки доступа для использования сервиса аутентификации

В принципе, настройка точки доступа для аутентификации со встроенным RADIUS на шлюзе Zyxel производится аналогично, как и было показано в статье Настройка WPA2 Enterprise c RADIUS

Для начала подключаемся к нужному IP через окно браузера, вводим имя пользователя и пароль (по умолчания также admin и 1234).

Рисунок 11. Окно входа на NWA210AX.

Далее переходим в меню Configuration AP management Wlan setting.

Нас интересует область MB SSID setting. Здесь нужно отредактировать профили Wiz_SSD_1 и Wiz_SSD_2.

Рисунок 12. Configuration AP management Wlan setting.

Рисунок 13. Настройка профиля SSID Profile Wiz_SSD_1.

Нажимаем на кнопочку редактировать, напоминающие редакторский блокнот с карандашом. Появляется окно Edit SSID Profile Wiz_SSD_1. В нем нас интересуют настройки Security Profile Wiz_Sec_Profile_1 (такая же кнопочка редактировать в виде блокнота с карандашом). Дальше появляется окно Edit Security Profile Wiz_Sec_Profile_1.

Рисунок 14. Окно Edit Security Profile Wiz_Sec_Profile_1.

В этом окне и выполняем необходимые настройки.

Для основного сервера вводим IP address, UDP Port и секретный ключ.

Для подтверждения нажимаем OK.

Аналогичным образом редактируем второй профиль SSID Profile Wiz_SSD_2.

Нажимаем Apply в разделе Configuration AP management Wlan setting для применения настроек.

Переходим к настройке клиента

В статье Настройка WPA2 Enterprise c RADIUS была иллюстрация на примере Mac OS X. Теперь для разнообразия подключим ноутбук с Windows 10.

Нажимаем внизу в разделе уведомления на Панели задач значок запуска беспроводных сетей. В появившемся списке выбираем пункт Zyxel. Появится окно с запросом имени пользователя и персонального ключа.

Рисунок 15. Настройка клиента.

Вводим необходимые реквизиты и подключаемся к системе.

Мы сейчас прошли весь этап настройки с внешним готовым сервисом RADIUS на межсетевом экране. Даже без стандартных действий для серверной системы: установки пакетов, настройки firewall, тестирования самой сервисной службы всё равно операция заняла достаточно много времени. Можно ли это сделать побыстрее и с меньшими трудозатратами? Можно, если использовать Zyxel Nebula. Но об этом ниже.

Отказоустойчивость и второй RADIUS сервер

Для среды production в компаниях уровня Enterprise нужно отказоустойчивое решение. Для таких целей часто используется второй сервер аутентификации.

Довольно большое распространение получили системы на базе MS Windows, где, благодаря серверной роли Network Policy Server и авторизации в Active Directory, можно настроить два сервера аутентификации для WPA2 Enterprise, и у них будет единая синхронизированная база данных пользователей и ключей.

Что касается схемы с RADIUS сервером на единственном шлюзе, то этот вариант больше подходит для небольших офисов, не имеющих собственной внутренней инфраструктуры. Проще говоря, для тех, у кого нет своих серверов и бизнес-процессы завязаны на использование облачных ресурсов. Электронная почта, файлообмен, резервное копирование и даже бухгалтерия всё это можно получить на внешних ресурсах. По правде говоря, в этом случае при отказе единственного межсетевого экрана офисная сеть становится практически бесполезна, и в принципе уже всё равно что там с сервисом аутентификации.

Обратите внимание. При падении службы аутентификации не происходит немедленного разрыва сетевых связей, установленных благодаря сервису аутентификации. Все уже подключённые клиенты продолжат работать в локальной сети. А вот новые подключения установить будет невозможно. В то же время наличие отказоустойчивой схемы из двух шлюзов позволит избежать подобных неприятностей.

Эту задачу можно решить другим способом реализовать отказоустойчивую схему из двух шлюзов. В этом случае при отказе основного устройства работу подхватит резервное, и все сервисы, размещённые на сетевом шлюзе, в том числе аутентификация, продолжат работать.

Но всё можно решить ещё проще при использовании аутентификации в облачном сервисе Zyxel Nebula. В этом случае за отказоустойчивость самой системы отвечает мощный промышленный программно-аппаратный комплекс. Разумеется, серверы Nebula размещены в ЦОД, выполняются все необходимые процедуры по поддержанию заявленного уровня высокой доступности и так далее. Единственное, что требуется от локального офиса канал в Интернет.

Пользователю остаётся только подключить устройство к облаку Zyxel Nebula и воспользоваться всеми заявленными преимуществами.

Использование Nebula на конкретном примере

Сейчас мы уже не будем настраивать наш межсетевой экран, так как для облачной аутентификации не играет другой роли кроме как шлюз в Интернет. Доступ в беспроводную сеть будет по-прежнему идти через точку доступа NWA210AX, а за остальное, включая аутентификацию пользователей и настройку оборудования, будет отвечать Zyxel Nebula.

В рамках данной статьи не будем детально описывать весь процесс первичной настройки сервиса Zyxel Nebula, так как он касается не только беспроводной сети, но и многих других аспектов сетевой инфраструктуры.

Будем считать, что организация уже зарегистрирована в Zyxel Nebula, уже есть учётная запись администратора и создана хотя бы одна площадка.

А сейчас мы просто переходим на сайт nebula.zyxel.com вводим пароль и попадаем в облачный интерфейс.

Рисунок 16. Вход в Zyxel Nebula.

Вначале нужно зарегистрировать точку доступа. Можно воспользоваться специальным приложением для IOS или Android и просто отсканировать QR-код. Это удобно если устройство находится под рукой. Если нужно зарегистрировать удалённо, это можно сделать, зная MAC адрес и серийный номер, указав их в интерфейсе. Это метод наиболее универсальный, им и воспользуемся.

Обратите внимание. Для настройки устройств с Zyxel Nebula нам нужно только, чтобы точка доступа была подключена к сети, при этом используется исходящее соединение. То есть не нужно открывать входящие порты, пробрасывать трафик через PAT всё выполняется в рамках исходящего подключения к облаку.

Выполняем переход Площадка Конфигурация Добавление устройств и нажимаем кнопку Регистрация.

Рисунок 17. Раздел Площадка Конфигурация Добавление устройства.

Появится окно Регистрация по МАС-адресу и серийному номеру. Вводим необходимые параметры.

После ввода серийного номера и MAC Nebula сразу определяет устройство.

Рисунок 18. Окно Регистрация по МАС-адресу и серийному номеру.

Обратите внимание на важное предупреждение на красный символ со значком i:

Устройства Nebula Flex будут настроены центром управления Nebula, а настройки, используемые в автономном режиме, будут потеряны. После отмены регистрации в центре управления Nebula устройства получат заводские настройки.

В нашем случае это хорошо для аутентификации важно соблюдать принцип единоначалия. Важно помнить, что все настройки, которые были выполнены для RADIUS на шлюзе при переходе в облако отменяются.

Если действия пользователя приводят к изменению лицензии, это также отображается внизу окна.

Ставим галочку Подтверждение и нажимаем OK.

Вновь ведённую точку доступа можно увидеть в разделе Точки доступа Мониторинг Точки доступа.

Рисунок 19. Раздел Точки доступа Мониторинг Точки доступа.

Переходим в раздел Точки доступа Аутентификация. Здесь мы просто выбираем тип аутентификации WPA2 Enterprise.

Рисунок 20. Раздел Точки доступа Мониторинг Точки доступа

Обратите внимание. Так как устройства в Nebula используют исходящее соединение, то для того, чтобы они получили и применили новую конфигурацию, требуется некоторое время. В сообщении интерфейса Nebula указано, что требуется не больше 1-2 минут. На практике это занимает несколько секунд.

Нам осталось ввести учётные записи пользователей.

Нам нужен раздел Площадка Конфигурация Облачная аутентификация и далее раздел Пользователи. Нажимаем кнопку Добавить и появляется окно для создания пользователя. На рисунке ниже у нас уже создан пользователь ivan и открыто окно для редактирования реквизитов.

Рисунок 21. Учётная запись пользователя.

Далее снова берём ноутбук и настраиваем доступ к сети.

Windows выводит уже знакомое приглашение ввести логи и пароль.

Рисунок 22. Подключение к WiFi.

Но после ввода появляется ещё одно интересное сообщение:

Рисунок 23. Сообщение о подключении к сети Nebula.

В данном случае нас всё устраивает, поэтому спокойно подключаемся к WiFi сети.

Как видим, если не считать регистрации устройств, которая выполняется однократно, вся настройка сводится к выбору типа аутентификации и создания учётных записей пользователей. Никаких сторонних сервисов настраивать не нужно.

Подводя итоги

Решить вопросы аутентификации и авторизации можно несколькими способами. Например, полностью взять инициативу на себя и реализовать сервис с нуля, начиная от выбора аппаратного обеспечения для физического сервера (или виртуальной среды), соответствующего приложения, базы данных для хранения учётных записей, интерфейса для настройки.

Можно упростить задачу и использовать встроенные решения, как, например, в межсетевом экране USG FLEX. А может быть лучше максимально упростить задачу и просто использовать облачный сервис со всеми удобными функциями? Выбор, как всегда, за конечным потребителем.

Полезные ссылки

1. Telegram chat Zyxel
2. Форум по оборудованию Zyxel
3. Много полезного видео на канале Youtube
4. Настройка WPA2 Enterprise c RADIUS
5. Особенности защиты беспроводных и проводных сетей. Часть 1 Прямые меры защиты
6. Двухдиапазонная точка доступа 802.11ax (WiFi 6) NWA210AX
7. Межсетевой экран USG FLEX 200
8. Zyxel ONE Network Utility (ZON)
9. Zyxel Nebula

Когда говорят о загородном доме, каждый представляет что-то своё. Для кого-то это лесная избушка на курьих ножках, для кого-то многоэтажный жилой комплекс. Поэтому и связь в этих условиях будет организована по-разному. В статье приводится описание различных нюансов, которые полезно знать при организации загородной сети.

Осторожно! Впереди много текста и упоминаний о различных сетевых устройствах. Будем рассказывать, что и для каких ситуаций можно применить.

Что понимать под словами загородный дом?

Иногда загородный дом находится в прямой видимости с городских улиц, иногда это лесная сторожка. Разумеется, цели и характер пребывания в загородном доме тоже будет различаться (спасибо, Капитан Очевидность).

Помимо чисто физических факторов очень важно определиться: Как именно люди хотят проводить время в загородной резиденции?. Это будет спартанское уединение в отрыве от цивилизации, времяпрепровождение из разряда почти как дома, только лучше или это место для удалённой работы одного или нескольких человек?

Случаи бывают самые разные.

Пример. ИТ специалист, работает в крупном интеграторе. Имеет квартиру в одном из городов Подмосковья и дачу в посёлке недалёко от МКАД. Всю рабочую неделю проводит на работе и даче, а домой в городскую квартиру ездит по выходным исключительно за уютом и благами цивилизации. В общем, всё наоборот.

Давать общие советы из разряда: Я-то лучше знаю!, вещь совершенно неблагодарная. Ниже мы попробуем представить несколько возможных вариантов загородной домашней сети с оглядкой на суровую правду жизни.

Решение для простых ситуаций

Если мобильный сигнал достаточно устойчив и неплохо принимается внутри помещения, при этом не требуется большая площадь покрытия, то можно закрыть большинство сетевых вопросов, разместив внутри дома маршрутизатор WiFi AC2050 LTE5388-M804. Он предназначен для внутренних помещений, выглядит симпатично и с успехом впишется в дачный интерьер. Кстати, есть поддержка резервирования между сотовой сетью и Ethernet WAN, так что позволяет использовать все доступные варианты, в том числе и местного проводного оператора.

Рисунок 1. LTE Cat.12 маршрутизатор резервирования WiFi AC2050 LTE5388-M804

Методы борьбы за качество связи

Как мы уже писали в статье в статье LTE как символ
независимости, работать через местного провайдера в небольшом населённом пункте ещё та заморочка. Часто возникает ситуация как в песне про Остров невезения: Крокодил не ловится, не растёт кокос. Если у вас в загородном посёлке местный интернет-провайдер оказывает приличный уровень сервиса несомненно, удача на вашей стороне.

Во многих местах вне городской инфраструктуры получить доступ в сеть Интернет можно только через мобильного оператора. И тут вступают в дело факторы устойчивой мобильной связи, в том числе:

1. Уровень сигнала на стороне абонента;
2. Ширина канала на стороне оператора;
3. Нагрузка на базовые станции оператора в районе получения услуги.

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

Проще говоря, беспроводное устройство: 3G/LTE/4G роутер необходимо разместить в зоне наиболее уверенного приёма сигнала. В первую очередь это нужно для того, чтобы не тратить время и ресурсы на исправление ошибок, связанных с низким уровнем сигнала. Одно из самых простых решений поднять повыше приёмник (передатчик), антенну или всё вместе, чтобы окружающий ландшафт не загораживал путь для прохождения сигнала.

Если этого не хватает, есть ещё несколько возможностей.

Например, проверить настройки чувствительности при приёме сигнала. В случае с роутером и аналогичным умным устройством это можно сделать через встроенный веб-интерфейс.

Можно попробовать другой вариант подключить внешнюю антенну, чтобы ловить больше энергии от радиоволн. Проще говоря, когда на пути радиоволны встречается электрический проводник, то количество электромагнитной энергии, преобразуемой в электрическую, зависит от размера, формы и материала проводника. Поэтому использование специализированных внешних антенн в принципе может помочь.

Примечание. Если где-то у окна или вне помещения сигнал 3G или 4G (LTE) вполне доступен, а в самом помещении ловится еле-еле или не доступен совсем стоит проверить работу с выносной антенной.

Также стоит критично подходить к выбору оборудования для приёма сигнала от сотового оператора. Большую роль играют возможности устройства анализировать входящий сигнал и вычленять из него рабочую составляющую, отбрасывая помехи, наложения другого сигнала и прочий ненужный фон.

Разумеется, ни один из приведённых выше методов не является панацеей от плохого сигнала, но использование всех доступных возможностей часто даёт неплохие результаты.

Другой щекотливый момент нагрузка на базовые станции. Боротmся с этим путём написания жалоб вряд ли получится. Дело в том, что любой сотовый оператор преследует исключительно свои интересы. Если получается взимать с потребителей деньги за весьма посредственный доступ Интернет, никто не будет ничего менять.

Ещё один нюанс, который приходится учитывать пиковая нагрузка в определённые часы. Например, когда в пятницу все соседи приехали на свои дачи и начинают звонить, писать, пересылать видео о том, как добрались.

Единственное, что можно сделать в такой ситуации подключить второй канал.

Примечание. Резервирование особенно эффективно, если большинство соседей предпочитают одного оператора и его базовая станция закипает от нагрузки тогда есть хорошие шансы, что на резервном канале от другого оператора ситуация будет лучше.

Маршрутизатор для внешнего размещения

Как было сказано выше, первое, что приходит на ум взять и перенести роутер с его антенной в нужное место. Однако для этого нужно выбрать модель, специально предназначенную для работы на улице. Имея защиту от влаги и перепада температур, такое устройство без особых проблем будет работать на высоте вне помещения. Особенно удобно, когда питание подаётся через PoE, и тянуть второй провод для питания не нужно. Даже если нет PoE коммутатора, то единственного кабеля
Ethernet хватит, чтобы получить сигнал от роутера, например, для ноутбука и подать на сам роутер питание через PoE инжектор.

Можно пойти проторенным путём и приобрести модель, уже неплохо показавшую себя в боях за загородный Интернет, например, уличный маршрутизатор 4G LTE-A Zyxel LTE7480-M804 Такой роутер способен обеспечить уверенный приём в труднодоступных местах и пережить капризы погоды при наружном размещении. И это достаточно недорогой вариант.

Рисунок 2. Уличный маршрутизатор LTE7480-M804.

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

Для такого случая подойдёт недавно поступивший в продажу уличный маршрутизатор 5G/4G/LTE-A NR7101, со множеством полезных функций.

Рисунок 3. Уличный маршрутизатор 5G/4G/LTE-A NR7101.

Стоит отметить, что помимо поддержки 5G в нем реализовано много всего нового и интересного, например, более полная реализация набора LTE/4G и другие полезные нововведения.

Внутреннее устройство с возможностью подключения внешней антенны

В качестве такого устройства можно порекомендовать маршрутизатор с функциями межсетевого экрана LTE3301-PLUS Cat.6 WiFi AC1200. Он позволяет использовать два канала связи, например, один встроенный LTE/3G с установкой SIM карты, другой стандартный проводной вход WAN. Если у вас под боком неплохой проводной провайдер можно подключить его как основной или резервный канал (в зависимости от качества сервиса).

И что важно в наличии два внешних разъёма SMA для антенн LTE/3G.

Рисунок 4. Маршрутизатор с функциями межсетевого экрана LTE3301-PLUS Cat.6 WiFi AC1200.

Альтернативный Интернет из кармана

Ещё один вариант использование дополнительных устройств в качестве резерва на крайний случай. При плохом прохождении сигнала можно в качестве запасного варианта просто достать и включить портативный маршрутизатор.

Примечание. Мини-роутер можно использовать как индивидуальное устройство для доступа в Интернет. Например, в рабочие дни подключив к ноутбуку как резервный канал связи, а в выходные совместно с WiFi роутером для раздачи другим потребителям.

В этом случае пользователь избавлен от необходимости вынимать-вставлять устройство в USB порт маршрутизатора для создания резервного канала. Нужно только включить компактный роутер, пользователи подключаются к соответствующей WiFi сети и получают доступ в Интернет. Простое временное решение.

В частности, симпатичное устройство NR2101 WiFi AX1800 с поддержкой 5G/4G/LTE-A и WiFi 6 вполне может решить проблему доступа в часы пик, через подключение к другому оператору. Этот малыш поддерживает все последние стандарты, например, очень неплохо иметь поддержку поздних спецификаций LTE/4G, WiFi 6 и другие полезные возможности.

Рисунок 5. Компактный маршрутизатор NR2101 WiFi AX1800 с поддержкой 5G/4G/LTE-A и WiFi 6.

Но не забудем и про старых знакомых, которые не раз выручали своих хозяев в сложной обстановке, например, в командировках, автомобильных пробках, пропадании основных каналов связи и других непредвиденных ситуациях. Для такого варианта вполне подойдёт Zyxel LTE2566-M634-EUZNV1F. Это портативный LTE Cat.6 WiFi маршрутизатор (используется одна сим-карта), есть поддержка 802.11ac (2,4 и 5 ГГц, скорость до 300+866 Мбит/с). Есть автономная батарея до 10 часов, питание через micro USB, то есть можно подключить PowerBank.

Рисунок 6. Компактный маршрутизатор LTE2566-M634-EUZNV1F с поддержкой 802.11ac.

Организация внутренней локальной сети

Если в маленькие дачные домики приезжают, чтобы на короткое время сбежать от городской жизни, работы и обилия информации, то для коммуникаций в загородных коттеджах предъявляются более серьёзные требования. Люди, живущие в таких домах, хотят иметь надёжную связь, например, для того, чтобы быть в курсе происходящих событий, работать удалённо, в общем, держать руку на пульсе жизни. Здесь нужна более серьёзная инфраструктура, чем сеть из одного-единственного WiFi роутера.

Совет. Чтобы избавиться от большинства проблем, связанных с подбором и согласованием между собой оборудования, используйте комплексное решение одного вендора.

Начнём с проводов

А почему это с проводов? просит пытливый читатель. Казалось бы, всё можно сделать проще поставил WiFi точки доступа и вперёд! Но везде есть свои нюансы.

Разумеется, можно построить всю сеть исключительно на беспроводном оборудовании. Такая организация сети называется Mesh. Но тогда, во-первых, часть ресурсов приём-передачи будет расходоваться на связь точек доступа и маршрутизатора между собой, и не только для передачи данных, но и для обмена служебной информацией.

Например, если в точке доступа два радиомодуля, то при достаточно высокой плотности устройств (приставки, планшеты, смартфоны, телевизоры и так далее) если один из радиомодулей будет использоваться и для Mesh и для клиентов, то в этом диапазоне будет потеря производительности.

Если в точках стоят два радиомодуля (2.4ГГц и 5ГГц), можно, например, радиомодуль 5ГГц отдать только для Mesh, а 2.4 ГГц только для клиентов. Проблем с приёмом на 2.4ГГц не будет, но зато теряется канал 5ГГц. Не проще ли подключить точки доступа и сетевой экран в коммутатор?

Во-вторых, некоторые устройства предпочтительней использовать в проводной локальной сети, например, настольный компьютер, сетевой принтер и так далее.

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

И на закуску если устройства (камеры, точки доступа и так далее) могут питаться через PoE, то гораздо проще приобрести коммутатор с PoE и не морочить себе голову с инжекторами или дополнительными блоками питания.

Например, можно остановиться на небольшом компактном 8-портовом гигабитном PoE коммутаторе GS1008HP.

Для небольшой домашней сети сложные функции вроде ACL не особенно нужны. Поэтому вполне подойдёт коммутатор без функций управления, зато простой и надёжный, главное бесшумный. Вполне себе бюджетное решение.

Рисунок 7. 8-портовый гигабитный PoE коммутатор GS1008HP.

Если же PoE необязательно, но требуется повышенная скорость обмена, можно остановиться на 12-портовом мультигигабитном коммутаторе XGS1010-12 с 2 портами 2.5GB/s, 2 портами 10G SFP+ (остальные 8 портов под витую пару Gigabit Ethernet).

В этом случае и вариантов для применения куда как больше, и возможностей хватает. Например, в мультигигабитные порты можно подключить точки доступа, в один из гигабитных портов минисервер (или NAS) с сетевым портом 10G SFP+, а второй порт 10G SFP+ зарезервировать как UPLINK. Но это всего лишь один из возможных сценариев.

Рисунок 8. 12-портовый мультигигабитный коммутатор XGS1010-12.

Если в доме есть своя сеть для видеонаблюдения из двух IP камер и более, то регистратор и видеокамеры рекомендуют подключить в отдельную сеть с коммутатором PoE (иногда даже со своим доступом Интернет), чтобы видеотрафик не мешал работе домашних или офисных устройств, а те, в свою очередь не забивали канал для передачи видеокартинки. Следовать или нет данной рекомендации дело за проектировщиком сети, но такой вариант следует иметь в виду.

Ещё один из возможных вариантов использование коммутатора, управляемого из облачной среды Zyxel Nebula. Например, 8-портовый гигабитный коммутатор с PoE GS1920-8HP вполне способен стать мини-ядром небольшой сетевой инфраструктуры с управлением из облака.

Рисунок 9. 8-портовый гигабитный смарт-управляемый коммутатор с PoE GS1920-8hp.

А что с внутренней беспроводной сетью

Загородный дом всё-таки это не высокотехнологичный офис с массой наёмных сотрудников. Беспроводная сеть в загородном доме должна обеспечивать приемлемое покрытие, но при этом сеть не должна быть дорогой.

Примечание. Если говорить о покрытии WiFi для совсем небольшого участка (до 6 соток) с маленьким садовым домиком: одна комната, кухня + веранда, то, вероятней всего, речь идёт о площади самого домика и прилегающей территории: веранда, беседка, лавочка у ворот Вряд-ли кто-то будет пытаться ловить WiFi в крапиве возле забора на противоположной стороне участка. Однако для крупных домовладений ситуация может быть совсем иной.

Может показаться интересным подход к построению беспроводной сети на основе недорогих точек доступа. Вопросы покрытия и возможности подключения новых клиентских устройств решаются за счёт добавления недорогих точек в систему. Мы уже писали о таком подходе в статье Особенности защиты беспроводных и проводных сетей. Часть 2 Косвенные меры защиты

Неплохо, чтобы беспроводные устройства поддерживали стандарт 802.11ax (WiFi 6). Нововведения, пришедшие с ним, затронули и скорость передачи данных, и улучшения в сфере безопасности, и возможность подключать больше устройств появилось много изменений к лучшему. Для таких требований можно рекомендовать двухдиапазонную точку доступа NWA110AX со всеми нужными функциями 802.11ax (WiFi 6).

Рисунок 10. Двухдиапазонная точка доступа NWA110AX с поддержкой 802.11ax (WiFi
6).

Если нужен совсем недорогой вариант, при котором функции WiFi 6 не так уж востребованы, но, тем не менее, важна устойчивая связь можно посмотреть в сторону последней модели стандарта 802.11ac точки доступа NWA1123ACv3.

Рисунок 11. Двухдиапазонная точка доступа 802.11aс Wave 2 NWA1123ACv3. (Выглядит очень схоже с NWA110AX).

Совет. Не стоит ограничивать свой выбор только двумя моделями. Zyxel Networks представляет довольно широкий спектр точек доступа с поддержкой облачной системы управления Nebula или без неё. Поэтому стоит рассмотреть весь список предложений.

Во многих случаях хорошим подспорьем при настройке и администрировании может оказаться облачная система Zyxel Nebula. Например, набор из коммутатора GS1920-8HP и точек доступа NWA110AX вполне может стать основой такой облачной системы. Это, конечно, вариант для крупных домов или для ситуаций, когда нужно обеспечить удалённую техподдержку пусть маленькой, но очень важной компьютерной сети, от которой многое зависит.

Подведём итоги

Как уже было сказано в начале статьи загородные дома целиком зависят от индивидуальных предпочтений и возможностей владельцев и располагаются в самых разных местах, каждый со своей спецификой.

Мы попытались крупными мазками нарисовать несколько вариантов построения сети в загородном доме, попутно разбирая возможные проблемы.

Будем рады, если эта статья поможет при решении подобных задач.

Полезные ссылки

1. Telegram chat Zyxel
2. Форум по оборудованиюZyxel
3. Много полезного видео на канале YouTube
4. Двухдиапазонная точка доступа NWA110AX
5. Двухдиапазонная точка доступа 802.11aс Wave 2 NWA1123ACv3
6. 8-портовый гигабитный PoE коммутатор GS1008HP
7. 12-портовый мультигигабитный коммутатор XGS1010-12
8. Мобильный роутер NR2101 WiFi AX1800
9. Мобильный роутер LTE2566-M634-EUZNV1F
10. Уличный маршрутизатор 5G/4G/LTE-A NR7101
11. Уличный маршрутизатор 4G LTE-AZyxel LTE7480-M804
12. LTE маршрутизатор WiFi AC2050 LTE5388-M804
13. LTE как символ независимости
14. Особенности защиты беспроводных и проводных сетей. Часть 1 Прямые меры защиты
15. Особенности защиты беспроводных и проводных сетей. Часть 2 Косвенные меры защиты
16. Zyxel Nebula

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

Инженеры и дизайнеры Zyxel постарались учесть все вопросы при создании удобного интерфейса для облачной среды Nebula. Но люди индивидуальны и зависимость от привычного окружения у каждого своя.

Как быстрее понять основные принципы и адаптироваться к новому стилю работы об этом и пойдёт речь.

В данной статьe мы постарались ответить на следующие вопросы:

• Основные отличия в идеологии управления;
• Зачем нужны Организация и Площадка;
• Как ускорить процесс регистрации устройств в облаке.

Также мы подготовили ответы на вопросы, которые встретились в комментариях.

Вместо предисловия

Облачная среда управления Nebula это новое направление по сравнению с традиционным интерфейсом.

Любое нововведение требует период адаптации, это старо как мир. И всё равно каждый раз это выглядит как в известной фразе Виктора Степановича Черномырдина: Никогда такого не было, и вот опять!

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

Например, дежурный администратор, привыкший к одному виду расположения элементов, может чувствовать себя немного не в своей тарелке.

Обычно локальный интерфейс для управления чем-либо строится по хорошо знакомой схеме: Вот конкретное устройство. Слева список разделов, справа область информации и объектов управления (см. рисунок).

Рисунок 1. Пример локального интерфейса Zyxel (USG FLEX 200). Слева разделы интерфейса, справа рабочая область.

В Nebula всё выглядит примерно также, но немного по-другому. Почему так происходит, давайте разбираться.

https://habrastorage.org/webt/5l/08/jz/5l08jzmrpvallezv7zfgtfv3gn8.png
Рисунок 2. Пример веб-интерфейса Nebula.

Различия в интерфейсе

В отличие от локального интерфейса, где нужно просто хорошо управлять одним-единственным устройством и всё, Zyxel Nebula проектировалась как глобальная система управления распределённой инфраструктурой.

Очень часто компания не монолитная структура, а штаб-квартира с филиалами. Почти всегда присутствует разделение по географическому или какому-либо другому признаку, а то и по всём сразу.

Мало того отдельные департаменты внутри организационной единицы могут иметь свою собственную инфраструктуру. Например, отдел разработки может иметь свой production (для внутренних нужд), свою тестовую среду, свои вспомогательные серверы (например, свой DHCP) и всё это отдельно от основных служб и сервисов.

Наконец, в компании может быть не один ЦОД, не одна серверная, и тем более не единственная стойка с серверами. Что и накладывает отпечаток на управление всем этим хозяйством.

Рисунок 3. Интерфейс Nebula. Показано подменю с выбором раздела

Соответственно, в глобальном интерфейсе управления необходимо создать виртуальную инфраструктуру, адекватную той, что уже существует в реальности.

Ещё один интересный нюанс кроется в идеологии подключения. Когда подключаетесь напрямую нужно учитывать дополнительные условия, например, имеет устройство постоянный адрес, открыты ли порты и так далее. Для работы с Nebula эти вопросы неактуальны, зато могут встретиться другие важные моменты, например, включен ли на самом устройстве параметр Nebula Control Center Discovery, чтобы устройство смогло самостоятельно найти облако.

Организация и Площадка

Начнём с начала и попробуем зарегистрироваться в Nebula c чистого листа.

При регистрации в Zyxel Nebula первое, что предстоит сделать создать корневую структурную единицу Предприятие и одну нижестоящую инфраструктурную единицу Площадку.

Таким образом каждое подразделение, ЦОД, серверная, и всё что мы хотим, как-то отделить можно разместить на отдельных площадках.

Рисунок 4. Создание организации и первой площадки.

Какие это даёт преимущества?

Во-первых, можно делать общие настройки для всех единиц оборудования на одной Площадке. Не надо дублировать одно и то же для каждого устройства.

Во-вторых, можно делегировать управление Площадкой сотрудникам с разными ролями. Например, дежурный администратор может только просматривать информацию, чтобы создать заявку. А сетевой администратор, работающий в филиале вносить необходимые изменения, но в рамках своей Площадки. Это удобно, и никто не мешает друг другу.

Некоторые особенности работы с интерфейсом Nebula

Разумеется, не все настройки можно вынести в общий раздел. Поэтому в интерфейсе Nebula сохраняются специализированные подразделы по типу оборудования: Шлюз безопасности, Коммутаторы, Точки доступа.

При этом наличие группы общих настроек, размещённой в разделе Площадка вносит некоторое разнообразие в привычном алгоритме работы администратора.

Рисунок 5. Настройка портов выбранного коммутатора в разделе Коммутаторы Конфигурация

Совет. Перед началом работы внимательно просмотрите общие настройки в разделе Площадка, отметьте для себя пункты, которые могут понадобиться. После этого будет проще разбираться с настройками для каждого типа оборудования в тематических разделах.

Некоторые вопросы при добавлении устройств

На самом деле вся система Nebula спроектирована так, чтобы не было проблем. Однако существуют ещё внешние факторы, на которые разработчики не могут повлиять при всём желании.

Например, если при подключении устройства используется недостаточно быстрое соединение, то и регистрация устройств в сети будет недостаточно быстрой.

Ещё одним важным фактором является использование исходящих соединений для связи устройств с облачной средой управления. То есть Nebula не разыскивает устройства, например, по белым IP адресам, и не подключается к ним по заранее открытым портам на файерволе, а именно сами устройства связываются с облачной средой управления по протоколу NETCONF.

Это и безопасней (никаких дырок на файрволе) и проще организовать не нужно обзаводиться постоянным белым IP адресом, или возиться с настройкой DDNS (динамического DNS). Гораздо проще подождать, пока устройство само установит соединение.

Выглядит это тривиально: зарегистрировали устройство, допустим, через мобильное приложение, а в интерфейсе Nebula оно появляется само, пусть не сразу, но спустя некоторое время.

Давайте опишем, как происходит регистрация и какие этапы она проходит.

Зарегистрировать устройство можно двумя способами: послав код устройства через приложение Nebula Mobile (IOS, Android) или указав реквизиты: MAC адрес и серийный номер вручную.

Рисунок 6. Регистрация через мобильное приложение.

Рассмотрим мобильную регистрацию.

Вначале пользователь выбирает нужную организацию и площадку. Если доступна только одна организация или площадка одна, этот вопрос автоматически снимается.

После сканирования QR кода автоматически распознаются тип и модель устройства, а также MAC адрес и серийный номер.

Эта информация проходит процедуру анонимизации и шифрования и записывается в базу данных.

Обязательно должен быть включён параметр Nebula Control Center Discovery, который запускает процесс поиска и соединения с облачным центром управления. (Как включить можно посмотреть в документации на конкретную модель).

Если устройство онлайн, и у него задействован описанный выше параметр через некоторое время оно установит связь с облачной средой управления, автоматически подключится к нему, получит идентификатор, и можно будет управлять через облако.

Рисунок 7. Включение параметра Nebula Control Center Discovery.

Схожим образом происходит регистрация вручную с вводом MAC адреса и серийного номера в веб-интерфейсе, но при этом данные сразу вводятся в облако, их не нужно вытаскивать из QR кода и передавать по беспроводной связи.

Рисунок 8. Регистрация устройства через веб-интерфейс.

По идее, если введённая информация верна, ничего делать не нужно, и устройство через какое-то время окажется в сети Nebula (в обычной ситуации это может занять до 2х минут). Но иногда хочется всё получить как можно быстрее.

Рассмотрим такой вариант зарегистрировали устройство в Nebula Mobile, а оно не успело появиться в интерфейсе, и время появления хочется сократить.

Можно попробовать перезагрузить устройство оно сразу после запуска установит соединение. В некоторых случаях это позволит немного ускорить регистрацию (или просто чем-то занять себя во время ожидания).

Ещё один способ ускорить процесс регистрировать устройства вручную через веб-интерфейс. В этом случае не используется этап дешифровки QR кода, и при наличии более скоростного и стабильного проводного соединения данные могут быть переданы быстрее.

Примечание. Если разные люди в одно и то же время попытаются, зарегистрировать устройство, например, и через мобильное приложение, и через веб-интерфейс, то Nebula примет данные источника, который успел первым передать информацию. Опоздавший получит сообщение о том, что устройство уже зарегистрировано.

Ещё один вариант ошибки оборудование зарегистрировано, но в интерфейсе Nebula отображается неактивным. Это говорит о том, что устройство просто не успело соединиться с Nebula для первичного обмена информацией. У пользователя есть выбор: немного подождать или для ускорения перезагрузить устройство.

Ещё одна помеха на пути к быстрой регистрации неторопливый Интернет-браузер, который показывает старую картинку. Помогает обнуление кэша или просто завершить работу браузера (все сессии и процессы) и запустить его, снова подключившись к своему аккаунту в Nebula.

Вопросы и ответы

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

А что если отключат Интернет? Всё, приплыли?

На самом деле ситуация не так трагична, как кажется. Локальные устройства, управляемые через Nebula: точки доступа, коммутаторы, и даже Интернет-шлюз (его локальные функции, такие как DHCP или RADIUS сервер) продолжат функционировать. Возникнут трудности с управлением, но локальная сеть не упадёт, и пользователи смогут выполнять ту часть работы, для которой не нужен выход в Интернет, например, работать в 1С на локальном сервере.

При восстановлении канала восстановится и стандартная функция управления.

Проще говоря, тот же принцип, что и при любом централизованном управлении:

• Что успели настроить до потери связи с центром, то работает.
• Во время отсутствияуправляющего центра изменения внести не получится.
• Канал подняли можно продолжить настройки.

Важно. Для устройств, подключённых к Nebula остаётся возможность управления через CLI (или веб-интерфейс, в зависимости от модели).

Разумеется, для безотказной работы необходимо иметь резервный Интернет-канал, для любого сценария управления: с Nebula или локально. Потому что связь с внешним миром это такой же необходимый ресурс, как и всё остальное, а для бесперебойной работы необходимо резервирование.

А что если данные из облака утекут? Тогда инфраструктурой может управлять кто захочет?

В данном случае стоит рассмотреть сценарий, когда происходит утечка данных, пригодных к использованию посторонними лицами. Данных в таком виде Nebula просто не хранит.

Во-первых, хранятся только данные, которые действительно необходимы для выполнения узкоспециализированных атомарных операций и для построения отчётов, опять же, строго по запросу администратора. Объём СХД, как известно, не резиновый. Поэтому хранить данные на случай вдруг понадобится никто не будет.

Во-вторых, очень важно в каком виде хранятся данные.

1. Все данные при поступлении анонимизируются. Проще говоря, понять где чья запись от какого клиента может только сама Nebula.
2. Все данные хранятся в зашифрованном виде.
3. Используется такая замечательная вещь, как двухфакторная аутентификация. В случае её использования попытки порулить чужой системой останутся безуспешными, если только вы сами не делегируете полномочия.

Примечание. Информацию из первоисточников можно получить по ссылкам в самой Nebula в меню Помощь Политика обработки данных.

Дополнительно публикуем две ссылки на документы в открытом доступе:

• Unlock Networking Possibilities with Cloud Nebula Secure Cloud Networking Solution
• NEBULA CONTROL CENTERGDPR DATA PROCESSING ADDENDUM

С другой стороны, при использовании традиционного необлачного управления с прямым подключением проблем с безопасностью может быть гораздо больше. Например, потерянный служебный ноутбук или принудительное изъятие рабочего ПК сетевого администратора в рамках каких-то там мероприятий увы, не самый невероятный сценарий. И ситуация при этом может оказаться гораздо более печальна, чем та, когда всё управляется удалённо через облако.

Регистрация в Nebula это дорога в один конец? Обратно в автономный режим переключить устройство уже не получится?

Устройства можно перевести в автономный режим работы, просто удалив их из Организации через тот же интерфейс Nebula.

А что если придётся передать устройство в другое подразделение (филиал, дочернюю компанию)?

Если речь идёт о передаче устройств в рамках одной компании можно просто переместить устройство между площадками. Если же для каждого подразделения существует своя организация в Nebula тогда их нужно удалить из Организации и зарегистрировать заново.

Подводя итоги

Zyxel Nebula проектировалась как система управления распределённой инфраструктурой. Для неё всё равно, где находится оборудование, важно, чтобы устройства имели выход в Интернет.

Это накладывает определённый отпечаток на идеологию управления, и, как следствие, на интерфейс пользователя. При работе с любой системой возникают некоторые нюансы, о которых полезно знать перед началом эксплуатации.

Полезные ссылки

1. Регистрация в Zyxel Nebula тут все начинается
2. Telegram chat Zyxel
3. Форум по оборудованию Zyxel
4. Много полезного видео на канале Youtube
5. Unlock Networking Possibilities with Cloud Nebula Secure Cloud Networking Solution
6. NEBULA CONTROL CENTERGDPR DATA PROCESSING ADDENDUM
7. Преимущества USG FLEX
8. Полезная статья в КБ о USG FLEX
9. Перенос лицензий с устройств USG на устройства USG FLEX Series (видео)
10. Служба поддержки Nebula для пользователей проф. версии Nebula (английский язык)
11. Форум Zyxel Nebula (можно создать запрос)
12. Техподдержка Zyxel
13. Nebula или RADIUS на примерах что выбрать для персональной аутентификации для точки доступа
14. Настройка WPA2 Enterprise с RADIUS
15. Сверхновое облако Zyxel Nebula экономичный путь к безопасности?
16. Zyxel Nebula и рост компании
17. Построение сетевой инфраструктуры на базе Nebula. Часть 1 задачи и решения
18. Построение сетевой инфраструктуры на базе Nebula. Часть 2 пример сети
19. Zyxel Nebula простота управления как основа экономии
20. Не боимся облаков
21. Журнал LAN: Знакомство с Zyxel Nebula

О периферийных устройствах написано достаточно много. Это и понятно, потому что большое число задач требует разнообразный парк оборудования: точки доступа, коммутаторы уровня доступа, межсетевые экраны и так далее.

В случае с корпоративной ИТ инфраструктурой все эти компоненты работают на нижних этажах, обеспечивая доступ пользователей и конечных устройств к сети.

А вот про уровень ядра сети сказано довольно мало. Причина вполне понятна больших организаций меньше, чем маленьких, поэтому крупных корпоративных сетей также меньше. Попытаемся восполнить этот пробел. Для начала расскажем об общих чертах и потом перейдём к конкретным моделям (описанию и вариантам использования). Помимо общих принципов, разберём конкретные модели по винтикам, (в том числе и буквально отверткой), чтобы посмотреть, что и как устроено.

Попробуем расколоть этот орешек знаний, чтобы добраться до ядра.

Вступление

Как мы уже писали ранее в статье Коммутаторы L2, L2+ и L3 что, когда, куда, откуда, как, зачем и почему? корпоративную сеть можно условно разделить на три уровня:

• Уровень доступа предназначен для подключения клиентских устройств.
• Уровень агрегации/распределения, который, как следует из названия, является промежуточным и служит для предварительного управление трафиком.
• Уровень ядра сети.

Рисунок 1. Уровни корпоративной сети

Коммутаторы ядра находятся в самом центре корпоративной сети и обеспечивают общую коммутацию (а если необходимо, то и маршрутизацию), связывающие все остальные сегменты.

Разумеется, нельзя каждый уровень рассматривать отдельно от предыдущего.

Общее увеличение трафика на уровне доступа ведёт к дополнительной нагрузке на коммутаторы уровня распределения, что в итоге влияет на загрузку ядра. Разумеется, возможны ситуации, когда всплеск трафика локализован в рамках одного сегмента (в переделах одного коммутатора уровня агрегации или даже уровня доступа). Но если имеется общая тенденция к росту трафика и передаваемых объёмов, это всё равно приводит к повышению нагрузки на ядро сети.

Поэтому важно учитывать не только сиюминутные потребности, но и что ждёт в будущем.

Особенности нагрузки в ядре сильно отличаются от нагрузки на уровне доступа. Если коммутатор уровня доступа привязан к работе пользователей (которых может попросту не быть в офисе), то на коммутаторе ядра будет присутствовать трафик обмена данными между серверами, СХД, облачными системами для резервного копирования и т.д. Поэтому коммутаторы ядра необязательно самые быстрые, но уж точно самые надёжные, рассчитанные на долговременную загрузку

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

Примечание. Учитывая массовый характер закупок, особенно при развёртывании сети с нуля, ошибка при выборе коммутаторов уровня распределения/агрегации и даже уровня доступа тоже может обернуться значительными финансовыми потерями. И хотя масштабы катастрофы принято оценивать по количеству простаивающих узлов за выбранный промежуток времени, к выбору оборудования для младших уровней следует подходить не менее ответственно.

Особенности коммутаторов ядра

Как уже было сказано выше, в ИТ инфраструктуре корпоративной сети коммутаторы уровня ядра являются центральным звеном, который объединяет другие сегменты (обычно уровня агрегации/распределения, реже уровня доступа). Через ядро проходит большая часть от всего трафика между клиентами, серверами, Интернет и так далее.

Поэтому главное умение ядра сети не падать при максимальной загрузке. Этот уровень всегда состоит из высокоскоростных коммутаторов и маршрутизаторов, производительных и отказоустойчивых. Немаловажную роль играет железо, в том числе характеристики коммутирующей матрицы, производительность процессора или контроллер.

Примечание. Универсалы vs узких профи Существует мнение, что для высокоскоростной передачи трафика, коммутаторы ядра не должны выполнять какие-либо манипуляции с пакетами, такие как маршрутизация между VLAN, ACL (Access Control List) и так далее в такой архитектуре все эти функции возложены на коммутаторы уровня агрегации/доступа. Однако построить идеальную инфраструктуру и уложиться в выделенный бюджет удаётся далеко не всегда. Часто на используется некий смешанный вариант, при котором уровень ядра и уровень агрегации/доступа является неким общим уровнем ядра+распределения. Разумеется, с точки зрения классической архитектуры это выглядит как вопиющее отступление от правил, зато с финансовой стороны вполне разумно.

А теперь кратко, просто и понятными словами

Проще говоря, коммутаторы уровня ядра это очень надёжные производительные коммутаторы L3 или L2+, которые могут выполнять те или иные задачи, но главное устойчивая передача трафика. Ниже мы подробно остановимся на некоторых нюансах.

Производительность

Как уже было сказано выше, скорость пересылки пакетов и ёмкость коммутации важные характеристики для коммутатора ядра в корпоративных сетях. Ядро должно обеспечивать требуемую скорость и пропускную способность.

Хорошая новость трафик не берётся из ниоткуда. То есть, зная кого, чего и сколько вы собираетесь подключить к сети и какой толщины будут внешние каналы, можно спрогнозировать верхнюю и нижнюю цифры по загрузке ядра сети. А дальше уже дело за выбором оборудования.

Разумеется, корпоративная жизнь порой подбрасывает сюрпризы вроде рождения новых бизнес-подразделений с нуля или построения новых сегментов вроде приватных облаков. Поэтому резервировать от 20 до 35% запаса производительности на вырост и такой же резерв по количеству портов для ядра сети это совсем неплохая идея. Как было сказано выше, обосновать остановку или временное замедление в работе практический всей корпоративной сети, чтобы заменить коммутатор в ядре та ещё задачка.

Надёжность оборудования

При проектировании ядра уделяют больше внимания избыточности по сравнению с другими уровнями. Вроде всё понятно: зачем и почему, но давайте посмотрим более детально.

Как было сказано выше, нагрузка на коммутаторы уровня ядра имеет другой характер, нежели уровня доступа. Соответственно, температурное воздействие тоже выше, и самое главное держится на одной отметке. И это должно учитываться при проектировании системы охлаждения.

Ещё один важный нюанс электропитание. Наличие двух источников питания не роскошь, а необходимость. Разумеется, можно использовать дополнительные хитрые внешние модули АВР (Автоматический Ввод Резерва) или SmartPDU, которые позволяют переключить подачу энергии на резервную линию, даже если на самом устройстве один блок питания. Но что будет с ядром сети, если единственный блок питания внутри коммутатора выйдет из строя? Нужно ли это проверять?

При наличии второго блока питания, когда один из них выходит из строя, другой немедленно берёт на себя все функции по обеспечению энергоснабжения. То есть стандартная схема: Active-Passive вполне пригодится.

Многое зависит от производителя блока питания и элементной базы. Если внутри всё сделано непонятно из чего и непонятно как наверное, вообще не стоит устанавливать подобное оборудование, а уж в ядро сети тем более.

Устойчивость к атакам и пиковым нагрузкам

Поскольку коммутаторы ядра являются центром сети, они должны уметь не только быстро перебрасывать Ethernet кадры, но и обладать расширенной защитой от DDoS с использованием протоколов уровня 2 и 3. И дело тут не только в злобных хакерах. Криво работающее сетевое приложение может навести шороху не меньше, нежели тёмные рыцари клавиатуры.

Кроме защиты от атак, сама по себе возможность работы при пиковых нагрузках является важной характеристикой. Обычно советуют избегать таких конфигураций, как дотошные списки доступа и фильтрация пакетов, особенно на фоне деградации производительности. Но в любом случае запас по мощности не повредит.

Стек и масштабирование. Агрегирование каналов.

Разумеется, ситуация, когда из-за проблемы с центральным коммутатором не работает крупный сегмент, а то и вся корпоративная сеть мало кого устраивает. Чтобы избежать ситуаций, когда одно-единственное устройство объединяет большое число подключений и в случае выхода из строя ничто не может взять на себя его функции используют резервирование и объединяют сетевое оборудование в стек.

Стек это соединение нескольких физических коммутаторов в один супер-коммутатор, когда при выходе одного из физических устройств отказоустойчивая схема продолжает работать.

Однако на одной только отказоустойчивости свет клином не сошёлся. Рано или поздно сеть разрастётся и возникнет дефицит вычислительных ресурсов и свободных портов. Даже если вначале были закуплены коммутаторы с хорошим запасом по портам и мощности, всё равно рано или поздно придётся проводить модернизацию. Стек коммутаторов даёт нам возможность добавить в ядро новые устройства, не снимая с эксплуатации старые.

Например, серия XGS4600 поддерживает стек до 4 коммутаторов, а XGS3700 до 8. Проще говоря, если у вас в ядре присутствует, допустим два коммутатора XGS4600-52F, вы можете удвоить их количество, доведя их число до 4, не прерывая работу сети.

Также полезным выглядит использование отказоустойчивых протоколов, например, VRRP для построения отказоустойчивой схемы маршрутизации.

Крайне важно, чтобы остальные участники сетевого обмена не теряли связь с ядром. Для этого используется агрегирование каналов, когда несколько физических портов на коммутаторе уровня агрегации/распределения объединяются в общий UPLink и подключаются к двум портам на коммутаторах уровня ядра. Таким образом при обрыве подключения на одном из портов, связь всё равно не теряется.

QoS

Quality of Service (QoS) является важной функцией, позволяющей обеспечить стабильное прохождение определённых типов трафика. Например, на современных предприятиях требуется видеоконференцсвязь. Такой трафик требует непрерывной передачи голоса и видеоданных, в отличие, например, от просмотра текстовых страниц в формате html. Ещё один пример резервное копирование, когда данные идут плотным потоком и необходимо успеть всё передать за короткое окно бэкапа. В таких случаях выручает использование системы приоритетов и ограничение полосы пропускания. То есть QoS.

Благодаря QoS коммутаторы ядра получают возможность предоставлять разную полосу пропускания различным приложениям в соответствии с характеристиками. По сравнению с трафиком, который не так требователен к полосе пропускания и задержкам во времени (например, электронная почта), критический трафик получит более высокий приоритет, и будет передаваться с высокой скоростью и гарантированно низкой потерей пакетов.

Управление

Для описания основных принципов работы с коммутаторы ядра сети очень даже подходит известная пословица: Работает? Не трогай!.

Но бывают ситуации, когда трогать нужно, например, при модернизации всей сети, подключения дополнительных сегментов и так далее.

И, разумеется, необходимо вовремя получать данные о работе сетевого оборудования.

Поэтому коммутаторы ядра сети поддерживают различные методы контроля и управления, начиная от SNMP и заканчивая подключением консоли.

Также полезно иметь выделенный порт управления (не объединяемый с передачей данных), который можно подключить в отдельный VLAN или даже коммутатор. Помимо повышения уровня безопасности, это позволяет упорядочить архитектуру сети и сохранить возможность управления даже при резком возрастании трафика через ядро.

Ниже идут описания и ТТХ конкретных моделей от Zyxel. Если не любите, когда производитель в своём же блоге описывает спецификации и возможности своих же устройств и считаете это сплошной рекламой можно сразу перейти в следующий раздел: Подведение итогов и рекомендации.

Рассмотрим на конкретных моделях

В качестве примера мы выбрали линейку коммутаторов, предназначенных для уровней ядра и агрегации/распределении. Откуда такое двойное назначение? Всё зависит от целей и задач, в первую очередь от архитектуры корпоративной сети. Бывают ситуации, когда на коммутаторы уровня агрегации/распределения ложится нагрузка, сопоставимая с уровнем ядра сети. Например, если активно используется маршрутизация между VLAN, списки доступа (ACL), фильтрация трафика и так далее.

Запас мощности и широкий набор возможностей в любом случае не помешает.

О каких моделях речь?

На сегодняшний день линейка XGS4600 насчитывает 3 коммутатора: XGS4600-32, XGS4600-32F, XGS4600-52F. Основное различие между ними в количестве и конструкции портов. Ниже приводится таблица, в которой указаны основные различия и общие моменты.

Ниже мы кратко опишем, почему эти коммутаторы пригодны для использования в качестве ядра сети.

Стек и High Availability

С помощью одного или двух слотов 10-Gigabit SFP+ можно объединить в физический стек до 4 коммутаторов. Также поддерживается динамическая маршрутизация для упрощения обмена данными между подсетями. Эта функция очень удобна для больших отелей, университетов и других компаний, где используется сложная сетевая инфраструктура. Для коммутаторов серии XGS4600 можно приобрести дополнительную лицензию с поддержкой протоколов OSPFv3 и RIPng для динамической маршрутизации IPv6.

XGS4600 Series оборудован гигабитными портами и четырьмя интегрированными слотами 10-Gigabit SFP+.

Другие меры обеспечения надёжности

Помимо объединения в стек, коммутаторы серии хранят два файла конфигурации и два образа микропрограммы. Это своего рода защита от случайных сбоев. Представьте, что закачанный файл микропрограммы оказался повреждён при передаче по сети. Наличие второго файла позволяет решить эту проблему без лишней крови, просто перезагрузив устройство с рабочей прошивкой.

Примерно такой же алгоритм восстановления, если изменения конфигурации оказались несовместимы с жизнью. Просто подгружаем другой файл и дело в шляпе.

Схема питания два независимых блока

XGS4600 Series поддерживает резервирование питания по схеме Active-Standby. В случае выхода из строя основного источника питания коммутатор будет работать от резервного источника питания.

Сами блоки питания от известного производителя DELTA Electronics.

А что с железом?

• Центральным узлом является процессор (CPU) 1GHz ARM cortex-A9.
• Switch controller BCM56340.
• RAM 1GB.
• Flash 64MB.

Разумеется, лучше один раз увидеть, чем сто раз услышать (а ещё лучше пощупать своими руками). И мы прямо в офисе вскрыли две модели чтобы посмотреть, что внутри.

Ниже прилагаем несколько фотоснимков, сделанных прямо в офисе Zyxel Россия.

Интересная информация. Zyxelне пытается поймать своих клиентов на мелочах. Хитрые пломбы, болтики из мягкой стали (у которых шлицы повреждаются даже при самом аккуратном откручивании), голографические наклейки и прочие уловки с целью лишить потребителя гарантийного обслуживания это всё не нужно.

Рисунок 2. Коммутаторы серии XGS4600, вид спереди: вверху XGS4600-32F, снизу XGS4600-32

Рисунок 3. Коммутаторы серии XGS4600, вид сзади: вверху XGS4600-32F, снизу XGS4600-32.

Во всех моделях, предназначенных для ядра два блока питания.

Рисунок 4. Внутреннее устройство коммутатора XGS4600-32.

Правильная компоновка и аккуратный монтаж плат и разъёмов очень важны. У производителя не должно возникать желания впихать невпихуемое в небольшой корпус.

Присутствуют мощные радиаторы и блок из трёх вентиляторов. Для коммутаторов ядра сети важно иметь хорошее охлаждение.

Рисунок 5. Коммутатор XGS4600-32 блоки питания.

Рисунок 6. Коммутатор XGS4600-32. Фрагмент материнской платы с микросхемами памяти.

Рисунок 7. Крупным планом.

Рисунок 8. Внутреннее устройство коммутатора XGS4600-32F.

Рисунок 9. Блок питания коммутатора XGS4600-32F.

Рисунок 10. В правой части расположены UPLINK, порт MGMT для управления коммутатором и консольный порт.

Обратите внимание на выделенный порт управления (OOB) на панели он показан как MGMT. В отличие от консольного RS-232 (который тоже в наличии) данный порт предназначен для удалённого управления устройством по сети.

Также присутствует индикатор номера коммутатора в стеке Stack ID.

Различные функции

Как уже было сказано выше, несмотря на то, что основная задача ядра стабильная работа под нагрузкой, время от времени возникает необходимость управлять трафиком, и это требует определённых инструментов.

Например, поддержка VLAN, а также QoS и списки доступа довольно полезные функции.

Полный список функций можно посмотреть здесь.

Подведение итогов и рекомендации

Невозможно объять необъятное, поэтому наш рассказ про коммутаторы ядра подходит к концу.

Существует множество факторов, которые определяют, какие коммутаторы ядра наиболее подходят для ядра сети в каждом конкретном случае. Однако существуют некоторые общие рекомендации, которые желательно соблюдать, чтобы избежать длительных простоев сетевой инфраструктуры.

Помимо голой теории мы показали, как эти особенности выглядят на примере конкретной реализации. Описанные принципы подходят при оценке любых других коммутаторов уровня ядра сети. Надеемся, это поможет при разработке новых проектов и модернизации уже существующих.

Полезные ссылки

1. Telegram chat Zyxel
2. Форум по оборудованию Zyxel
3. Много полезного видео на канале Youtube
4. Коммутаторы L2, L2+ и L3 что, когда, куда, откуда, как, зачем и почему?
5. Коммутаторы Zyxel L3 серии XGS4600
6. Построение сетевой инфраструктуры на базе Nebula. Часть 1 задачи и решения
7. Построение сетевой инфраструктуры на базе Nebula. Часть 2 пример сети
8. Особенности применения управляемых и неуправляемых коммутаторов
9. Как SFP, SFP+ и XFP делают нашу жизнь проще