Рис. 1. Предпосылки безопасности виртуализованных рабочих нагрузок

Облачные вычисления развиваются стремительными темпами, поэтому ИТ-руководителям и другим заинтересованным лицам приходится изучать массу информации, чтобы понять, какие преимущества этот новый тип сетевой инфраструктуры принесет их организациям. Основная задача — отделить полезную информацию от преувеличений и рекламной шумихи и выявить реальную ценность и потенциальную прибыль от инвестиций. Для этого необходимо учесть все зависимости, существующие в архитектуре облачных вычислений, включая подбор источников и обеспечение безопасности. Однако безопасность — не единственное препятствие для внедрения облачных вычислений. Здесь описаны методы, которые компания Juniper Networks использует для обеспечения надежной комплексной защиты всей инфраструктуры ЦОД.

По сути, облачная среда — это интернет-среда вычислительных ресурсов, в состав которой входят серверы, программное обеспечение и приложения в ЦОД, к которым любой пользователь или организация могут получить доступ посредством интернет-соединения. По оценкам экспертов, к 2015 году рынок облачных услуг вырастет до 35,6 млрд долларов США и технология виртуализации станет практически стандартной для архитектур облачных сред. Ценность облачной среды заключается в следующих преимуществах:
• Быстрая разработка и развертывание услуг
• Высокая масштабируемость вычислительных мощностей
• Распространение модели облачных услуг с оплатой только за использование (т.е. снижение капитальных затрат)

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

Предпосылки виртуализованных рабочих нагрузок


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

Кроме того, Нил Макдональд, вице-президент и научный сотрудник Gartner, отмечает: «В организациях будет продолжаться виртуализация ЦОД и облачных сред. При этом будут виртуализованы более важные рабочие нагрузки, которые сами по себе станут более мобильными. Это приведет к возникновению новых проблем, связанных с традиционной архитектурой системы безопасности ЦОД, которая основывается исключительно на физических устройствах защиты».

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

Динамическая сущность виртуальных машин делает проблему безопасности виртуализованных рабочих нагрузок еще более острой. Например, компания VMware, лидер в области технологий виртуализации и облачных сред, разработала такие средства, как VMotion и Distributed Resource Scheduling (DRS), которые позволяют создавать пулы устройств и мощностей и перемещать виртуальные машины с одного физического хоста на другой в соответствии с требованиями. Также значительно упрощается и ускоряется обеспечение виртуальных машин. ИТ-специалисты и администраторы подразделений могут создавать новые виртуальные машины на основе шаблонов или клонировать существующие. Таким образом, получается, что виртуальные среды можно масштабировать мгновенно в отличие от политик безопасности, используемых для контроля доступа и защиты от вредоносных программ, — если процесс масштабирования политик также не автоматизирован и не поддерживает возможность расширения. Как следствие, содержимое виртуальных машин и размещенные на них приложения подвергаются высокому риску несанкционированного доступа и передачи данных вредоносных программ, а также обладают слабыми (в ряде случаев унаследованными) средствами обеспечения безопасности. После рассмотрения предпосылок виртуализованных рабочих нагрузок в развивающемся ЦОД становится очевидно, что для достижения максимальных преимуществ организациям требуется решение, которое является частью виртуальной среды и масштабируется вместе с ней.

Комплексное решение для обеспечения безопасности виртуализованных ЦОД и облачных сред



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

Решение Juniper. Служебные шлюзы серии SRX — защита физических рабочих нагрузок



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

Зоны серии SRX — сегментирование и изоляция трафика среди физических рабочих нагрузок
Зона безопасности — это группа интерфейсов со сходными требованиями к безопасности, определяющими границу зоны. Внутренние сетевые интерфейсы можно отнести к зоне безопасности «доверенные», а внешние сетевые интерфейсы — к зоне безопасности «недоверенные». Политики безопасности, связанные с зонами, впоследствии используются для контроля транзитного трафика между зонами безопасности. Зона приема пакета, определяемая по интерфейсу, через который был передан пакет, и зона передачи пакета, определяемая проверкой переадресации, совместно определяют выбор политик, используемых для пакетов в этом потоке.
Серия SRX включает в себя межсетевой экран уровня зон и обеспечивает эффективное решение задач в трех ключевых областях:
  • Обработка пакетов
  • Управление политиками безопасности
  • Создание отчетов


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

Рассмотрим эту функцию на примере простого, не связанного с зонами («традиционного») межсетевого экрана с доверенными/недоверенными и демилитаризованными зонами (DMZ). Для удобства возьмем список из 300 политик. Традиционный межсетевой экран сравнивает каждый входящий пакет интерфейса со всеми 300 политиками до тех пор, пока не обнаружит совпадение с источником, назначением и сервисом, и только после этого выполняет соответствующие действия с пакетом. В противоположность традиционному межсетевому экрану межсетевой экран на уровне зон обрабатывает политики, сгруппированные по структурам зон, включая доверенные, недоверенные и DMZ. В приведенном примере (рис. 2) политики распределены поровну между всеми тремя интерфейсами. Это означает, что существует шесть возможных потоков, в каждом из которых будет обрабатываться по 50 политик.


Рис. 2. Обработка пакетов

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

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

Создание отчетов. Визуальный контроль и доступность сведений о зонах позволяют создавать более информативные отчеты, поэтому зоны становятся незаменимым инструментом для создания отчетов о соответствии нормативным требованиям, таким как стандарт безопасности данных в сфере платежных карт (PCI DSS), закон США о преемственности страхования и отчетности в области здравоохранения (HIPPA), закон Сарбейнса-Оксли (SOX) и др. Например, если межсетевой экран получил http-запрос, направленный из пункта A в пункт B, администратору прежде всего нужно определить, что такое A и B, чтобы принять решение о разрешении или запрете передачи пакета. Но если администратор видит, что такой же запрос был отправлен из недоверенной зоны в зону финансов, ему не придется выяснять, что такое A и B: очевидно, что передача пакетов в этом направлении должна быть запрещена. В то же время администратор может выявить политику, которая разрешает передачу пакета, или создать специальную политику для запрета таких пакетов.

Виртуальный шлюз vGW — защита виртуализованных рабочих нагрузок



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


Рис. 3. Виртуальный шлюз vGW

Вся функциональность vGW доступна в централизованном веб-интерфейсе, состоящем из одного окна. Интерфейс включает в себя редакторы политик безопасности для виртуальных сред с четкими правилами и интуитивно понятными функциями. Кроме того, серия vGW предоставляет функции для автоматического контроля безопасности и соответствия нормативным требованиям в виртуальных сетях и облачных средах. Эта серия тесно интегрируется с существующими технологиями безопасности Juniper, такими как система предупреждения вторжений (IPS) и системы управления безопасностью серии STRM Juniper Networks, предназначенными для ведения журналов и создания отчетов, а также позволяет создавать системы безопасности vGW для управления политиками.

Серии шлюзов SRX и vGW — комплексная организация зон



В Juniper знают, что проверенные технологии и правильная логика имеют ключевое значение для надежной защиты. Исходя из этого, совместная защита физических и виртуализованных рабочих нагрузок гарантирует, что применяемые политики безопасности соответствуют логическому назначению рабочих нагрузок, независимо от платформы, на которой они развернуты (рис. 4). С этой целью компания Juniper объединяет концепцию зон серии SRX с виртуальным механизмом защиты vGW. В результате данные зон синхронизируются с vGW и используются vGW в виртуализованной среде.

Далее приведено краткое описание принципа работы этого комплекса. Серия SRX обеспечивает группировку на уровне зон по периметру ЦОД, а vGW использует сведения о зонах SRX для защиты зон на гипервизоре с помощью таких функций безопасности, как «Интеллектуальные группы» и «Самодиагностика ВМ». Функция «Интеллектуальные группы» позволяет создать группу виртуальных машин, которая будет изменяться в зависимости от критериев, заданных администратором. Виртуальные машины, в которых внезапно произошли изменения конфигурации, соответствующие заданным критериям, можно добавить в группу или удалить из нее за считанные секунды. Например, если администратор виртуальной машины связал интерфейс виртуальной сети машины с корпоративной сетью производственного предприятия, можно немедленно применить набор правил межсетевого экрана для защиты этой системы. Кроме того, функция «Самодиагностика ВМ» предоставляет подробные сведения о приложениях и сервисах, установленных на виртуальной машине, и о ее конфигурации.

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

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


Рис. 4. Комплексная организация зон

Для чего нужна синхронизация зон серии SRX в виртуализованной сети?



Функция синхронизации зон в серии SRX представляет собой автоматизированный механизм связи между виртуальным уровнем безопасности vGW и физическими уровнем безопасности серии SRX. Это означает, что политики изоляции трафика передаются на уровень виртуализации и применяются к нему так же, как и ко всем сегментам сети (например, от периметра ЦОД до виртуальной машины). Импорт зон, созданных на устройствах серии SRX, упрощает назначение зон виртуальным машинам. Назначенные зоны можно использовать для применения политик, регулирующих взаимодействие виртуальных машин. Также эти зоны можно включать в проверку соответствия, которая позволяет подтвердить, что виртуальным машинам назначены только авторизованные зоны.

Синхронизация зон серии SRX и виртуальных шлюзов vGW проста как «раз-два-три».
1. Виртуальный шлюз vGW получает определения зон от устройства серии SRX и сопоставляет зоны с интерфейсом SRX, соответствующими сетями VLAN и сетевыми диапазонами для каждой зоны. Выберите зоны серии SRX в разделе «Security Settings» (Параметры безопасности) модуля «Settings» (Настройки) (рис. 5). Выберите «Add» (Добавить), чтобы создать новый экземпляр серии SRX. Параметры конфигурации: Name (Имя), Host (Хост) и Port (Порт).


Рис. 5. Конфигурация серии SRX

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

Host (Хост): Введите управляющий IP-адрес для серии SRX, с помощью которого vGW Security Design (то есть сервер управления vGW) будет подключаться к шлюзу SRX.

Port (Порт). Порт TCP, используемый для подключения шлюза серии SRX с помощью интерфейса Junoscript.

2. Используя полученные сведения о сетях VLAN и других сетях, связанных с каждой зоной, виртуальный шлюз vGW определяет зоны как группу политик. После сохранения объекта серии SRX выберите «Load Zones» (Загрузить зоны), чтобы запустить синхронизацию зон. На экране отобразится список всех полученных зон, в котором можно выбрать зоны для импорта в vGW в качестве групп зон виртуальных машин. В диалоговом окне «Load Zones» (Загрузить зоны) можно настроить функцию автоматического опроса шлюзов серии SRX на предмет обновления зон. Для запланированных обновлений можно настроить следующие параметры.

Update Frequency (Периодичность обновлений). Периодичность опроса шлюзов серии SRX на предмет обновлений.

Relevant Interfaces (Релевантные интерфейсы). Если для защиты виртуальной сети используется только определенная подгруппа интерфейсов серии SRX, эти интерфейсы можно выбрать здесь, чтобы обновлялись только зоны, связанные с виртуальной сетью.


Рис. 6. Выбор зоны

3. Группы политик vGW автоматически связывают каждую виртуальную машину с определенной зоной, что позволяет применять политики, регулирующие взаимодействие виртуальных машин, и проводить проверку соответствия зон. Зоны SRX создаются как группы политик виртуальных машин vGW. На основе сведений о зонах, полученных от устройств серии SRX, создается группа политик со следующими параметрами.

VLANs (Сети VLAN): Сети VLAN, связанные с интерфейсом серии SRX.

IP Ranges (Диапазоны IP-адресов). Подсеть, определяемая интерфейсом серии SRX, и маршруты, заданные в зоне.

VM Scope (Объем виртуальной машины). Если при настройке синхронизации зон выбран параметр «VMs associated» (Связанные виртуальные машины), выбранная группа будет включена в группу политик.

Функция синхронизации зон vGW также использует сведения виртуальной машины для заполнения адресной книги зоны, к которой относится эта виртуальная машина. Это позволяет проводить проверку соответствий между виртуальными машинами и зонами в контексте управления устройствами серии SRX.

Когда на устройстве серии SRX регистрируются сведения виртуальной машины, создается запись с именем виртуальной машины, заданным в vCenter. Чтобы подчеркнуть, что эти записи виртуальных машин созданы автоматически, в начало имени виртуальной машины в адресной книге добавляется соответствующая строка. По умолчанию добавляется строка «VM-», но это значение можно изменить в диалоговом окне синхронизации.


Рис. 7. Группы политик

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

Сценарии использования.

Соответствие требованиям к многопользовательским инфраструктурам и нормативным требованиям

Внедрение шлюзов серии SRX/vGW для управления многопользовательской инфраструктурой и организация изоляции

Многопользовательская инфраструктура, в которой ресурсы совместно используются несколькими клиентами, является фундаментальной концепцией облачных вычислений. Поставщики облачных услуг могут создавать сетевые инфраструктуры и ЦОД, которые характеризуются очень большой вычислительной мощностью, высокой масштабируемостью и удобством внедрения дополнительных компонентов для обслуживания всех клиентов, совместно использующих эти инфраструктуры. Ключевым условием выполнения поставщиком облачных услуг требований соглашения об уровне обслуживания (SLA) по безопасности является достаточная изоляция ресурсов клиента и виртуализованных рабочих нагрузок (например, виртуальные машины Coca-Cola отделены от виртуальных машин Pepsi). Клиентам или арендаторам общедоступных облачных сред и услуг хостинга виртуальных машин требуется официальное подтверждение того, что их виртуальные машины, размещенные в облаке, будут доступны только для уполномоченных организаций и лиц, а не для всех пользователей того же общедоступного облака.

Juniper предлагает комплексное решение для обеспечения безопасности, которое включает в себя шлюзы серии SRX и виртуальные шлюзы vGW и отвечает всем требованиям клиентов. Это решение изолирует потоки трафика клиента в определенных сегментах физической сети или зонах, связывает виртуальные машины клиента с этими зонами и ограничивает к ним доступ с помощью индивидуальных политик безопасности. На диаграмме общедоступного облака (рис. 8) поток трафика клиента A направляется через граничный маршрутизатор ЦОД на устройство серии SRX, где применяется политика зоны клиента A, ограничивающая доступ клиента A к сети VLAN 110. Виртуальный шлюз vGW в свою очередь определяет зеленые виртуальные машины, принадлежащие зоне/клиенту A, и проверяет, чтобы этим виртуальным машинам по ошибке не присваивалась сеть VLAN 210. Также политики зон серии SRX и vGW будут блокировать любые попытки передачи данных в направлении от клиента A к клиенту B.

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


Рис. 8. Управление многопользовательской инфраструктурой и организация изоляции

Внедрение шлюзов серии SRX/vGW для обеспечения соответствия политикам
Частные облачные среды — это среды облачных вычислений, которые находятся в полном владении определенной организации, контролируются и используются ею в служебных целях. Частное облако организации или государственного учреждения может обслуживать множество организационных подразделений и в этом смысле функционирует так же, как общедоступное облако, предоставленное поставщиком облачных услуг. Это означает, что в частном облаке ведущую роль играет изоляция виртуальных машин и групп виртуальных машин в зависимости от подразделения и функции. Это необходимо как с точки зрения соответствия нормативным требованиям, так и с точки зрения безопасности, так как рискованные операции с данными, выполняемые в одном подразделении, не ставят под угрозу виртуальные машины других подразделений. Представьте себе такую ситуацию: технологическое подразделение университета проводит исследования компьютерного вируса и использует облако совместно с медицинским институтом, который хранит данные пациентов на виртуальных машинах. Другой пример — организация работает в системах управления взаимодействием с клиентами (CRM) на виртуальных машинах, размещенных на одном хосте с веб-серверами.

Такие смешанные инфраструктуры довольно обычны, поскольку из соображений экономии организации стараются разместить как можно больше виртуальных машин на одном хосте. Однако в соответствии с передовыми практиками безопасности требуется, чтобы виртуальные машины были изолированы друг от друга. В этом случае вирус с веб-сервера не сможет подключиться к клиентской базе организации. Этот механизм защиты показан на приведенной ниже диаграмме (рис. 9). Политики зон на устройствах серии SRX гарантируют, что физические серверы в настроенных зонах не смогут подключаться к веб-серверам, и наоборот. Любой двусторонний трафик между этими зонами будет блокирован шлюзом серии SRX. В случаях, когда на физических серверах в этих зонах установлены виртуальные машины, работает виртуальный шлюз vGW, применяющий те же политики. Таким образом, виртуальные машины в настроенных зонах не смогут связываться с виртуальными машинами на веб-сервере. Если администратор по ошибке добавит новую виртуальную машину не в ту зону (VLAN) —а это вполне возможно при управлении крупными сетями — виртуальный шлюз vGW добавит эту виртуальную машину в карантин и сообщит администратору о нарушении политики.


Рис. 9. Применение политик безопасности

Заключение


Облачные вычисления и виртуализация — два основных катализатора преобразований в архитектуре ЦОД.

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

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


Дистрибуция решений Juniper Networks в Украине, Беларуси, Молдове, Армении, Грузии, Таджикистане, Казахстане, других странах СНГ.

Курсы по обучению Juniper Networks

Комментарии (1)


  1. Karroplan
    09.07.2015 13:58

    можно ли ставить ваш vGW на гипервизор совместно с продуктами других компаний? Уживется ли vem от Cisco Nexus1000v и vem от juniper vGW на одной платформе?