Yandex Cloud
Поиск
Связаться с намиПодключиться
  • Документация
  • Блог
  • Все сервисы
  • Статус работы сервисов
    • Популярные
    • Инфраструктура и сеть
    • Платформа данных
    • Контейнеры
    • Инструменты разработчика
    • Бессерверные вычисления
    • Безопасность
    • Мониторинг и управление ресурсами
    • Машинное обучение
    • Бизнес-инструменты
  • Все решения
    • По отраслям
    • По типу задач
    • Экономика платформы
    • Безопасность
    • Техническая поддержка
    • Каталог партнёров
    • Обучение и сертификация
    • Облако для стартапов
    • Облако для крупного бизнеса
    • Центр технологий для общества
    • Облако для интеграторов
    • Поддержка IT-бизнеса
    • Облако для фрилансеров
    • Обучение и сертификация
    • Блог
    • Документация
    • Контент-программа
    • Мероприятия и вебинары
    • Контакты, чаты и сообщества
    • Идеи
    • Истории успеха
    • Тарифы Yandex Cloud
    • Промоакции и free tier
    • Правила тарификации
  • Документация
  • Блог
Проект Яндекса
© 2025 ООО «Яндекс.Облако»
Yandex Cloud Interconnect
    • Все руководства
    • Создать прямое транковое подключение и приватное соединение в нем
    • Создать прямое транковое подключение и публичное соединение в нем
    • Создать транковое подключение через партнера и приватное соединение в нем
    • Создать транковое подключение через партнера и публичное соединение в нем
    • Добавить приватное соединение в транковое подключение
    • Добавить публичное соединение в транковое подключение
    • Изменить емкость транкового подключения
    • Изменить набор IP-префиксов в приватном соединении
    • Удалить приватное соединение
    • Удалить публичное соединение
    • Удалить транковое подключение
    • Интеграция с корпоративным сервисом DNS
    • Организация доступа через Cloud Interconnect к облачным сетям, размещенным за NGFW
    • Настройка сетевой связности между подсетями BareMetal и Virtual Private Cloud
    • Обзор
    • Терминология
    • Точки присутствия
    • Партнеры CIC
    • Трансиверы
    • Транковое подключение
    • Приватное соединение
    • Публичное соединение
    • Маршрутизация
    • Мониторинг
    • Объемы данных и емкости подключений
    • Квоты и лимиты
  • Правила тарификации
  • История изменений

В этой статье:

  • Описание маршрутизации трафика из инфраструктуры клиента к ресурсам в VPC dmz и app
  • Необходимые условия
  • Настройте таблицы маршрутизации в VPC interconnect
  • Создайте приватные соединения Cloud Interconnect
  1. Практические руководства
  2. Организация доступа через Cloud Interconnect к облачным сетям, размещенным за NGFW

Организация доступа через Cloud Interconnect к облачным сетям, размещенным за NGFW

Статья создана
Yandex Cloud
Обновлена 12 февраля 2025 г.
  • Описание маршрутизации трафика из инфраструктуры клиента к ресурсам в VPC dmz и app
  • Необходимые условия
  • Настройте таблицы маршрутизации в VPC interconnect
  • Создайте приватные соединения Cloud Interconnect

В Yandex Cloud можно развернуть защищенную высокодоступную сетевую инфраструктуру на основе Next-Generation Firewall (NGFW) для обеспечения сегментации инфраструктуры на зоны безопасности. Каждый сегмент сети (далее сегмент) содержит ресурсы одного назначения, обособленные от других ресурсов. Например, DMZ сегмент предназначен для размещения общедоступных веб-ресурсов (например, фронтенд-приложений), а сегмент Application содержит бэкенд-приложения. В облаке каждому сегменту соответствует свой каталог и своя облачная сеть VPC. Связь между сегментами организуется через виртуальные машины Next-Generation Firewall, развернутые в двух зонах доступности для отказоустойчивости.

В практических руководствах Yandex Cloud есть варианты реализации отказоустойчивой сетевой инфраструктуры с использованием NGFW:

  • UserGate
  • Check Point

Для организации сетевой IP-связности между ресурсами в собственной инфраструктуре клиента и облачными ресурсами в Yandex Cloud может использоваться услуга Yandex Cloud Interconnect.

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

Схема решения представлена ниже.

Название Описание
FW-A Основной NGFW в зоне A
FW-B Резервный NGFW в зоне B
VPC interconnect VPC для подключения собственной инфраструктуры клиента с помощью Cloud Interconnect
VPC dmz VPC для размещения фронтенд-приложений, доступных из интернет
VPC app VPC для размещения бэкенд-приложений
A.A.A.0/24 подсеть для сетевого интерфейса FW-A в VPC interconnect
B.B.B.0/24 подсеть для сетевого интерфейса FW-B в VPC interconnect
C.C.0.0/16 агрегированный префикс подсетей в VPC dmz, к которым необходимо обеспечить доступ из собственной инфраструктуры клиента
D.D.0.0/16 агрегированный префикс подсетей в VPC app, к которым необходимо обеспечить доступ из собственной инфраструктуры клиента

Описание маршрутизации трафика из инфраструктуры клиента к ресурсам в VPC dmz и appОписание маршрутизации трафика из инфраструктуры клиента к ресурсам в VPC dmz и app

При выполнении необходимых условий и приведенных ниже настроек для облачных таблиц маршрутизации и Cloud Interconnect:

  • Трафик из инфраструктуры клиента будет приходить в зону с основным NGFW и на нём маршрутизироваться в соответствующий VPC dmz или app.
  • В случае отказа основного NGFW трафик продолжит приходить в зону с основным NGFW и из нее уже маршрутизироваться к резервному NGFW в соседнюю зону (при условии использования модуля route-switcher).
  • При отказе зоны с основным NGFW трафик будет приходить в зону с резервным NGFW (при условии использования модуля route-switcher) и на нём маршрутизироваться в соответствующий VPC dmz или app.

Необходимые условияНеобходимые условия

  1. Используйте модуль route-switcher для переключения трафика в VPC interconnect, dmz, app в случае отказа основного NGFW на резервный. Модуль route-switcher используется в практических руководствах на основе UserGate NGFW или Check Point NGFW.
  2. В настроенных таблицах маршрутизации не должно быть пересекающихся префиксов с сетями, используемыми в собственной инфраструктуре клиента.
  3. Маршруты, анонсируемые из собственной инфраструктуры клиента через Cloud Interconnect, не должны пересекаться с адресным пространством подсетей в VPC interconnect, dmz и app.
  4. Префиксы в анонсах приватных соединений Cloud Interconnect (в примере это A.A.A.0/24, B.B.B.0/24, C.C.0.0/16 и D.D.0.0/16) не должны пересекаться.
  5. На NGFW должны быть настроены политики безопасности, разрешающие доступ из VPC interconnect в VPC dmz и app с учетом требований службы информационной безопасности клиента.
  6. Таблицы маршрутизации для подсетей в VPC dmz и app должны содержать маршруты к сетям, используемым в on-premise инфраструктуре клиента. Обычно используется маршрут по умолчанию 0.0.0.0/0. В качестве Next hop для этих маршрутов должен использоваться IP-адрес основного NGFW в соответствующем VPC dmz или app.
  7. На NGFW должны быть настроены статические маршруты к сетям, используемым в собственной инфраструктуре клиента. В качестве Next hop для этих маршрутов нужно использовать адрес шлюза (первый адрес из диапазона подсети, например, x.x.x.1 для подсети x.x.x.0/24) из облачной подсети интерфейса NGFW в VPC interconnect.
  8. Рекомендуется планировать адресные планы в VPC dmz и app таким образом, чтобы можно было использовать агрегированные префиксы (агрегаты). Использование агрегатов (в примере это С.С.0.0/16 и D.D.0.0/16) позволяет один раз настроить таблицы маршрутизации в VPC interconnect и анонсы префиксов в приватных соединениях Cloud Interconnect. В дальнейшем при добавлении новых подсетей в VPC dmz и app не потребуется изменять таблицы маршрутизации в VPC interconnect и открывать обращения в техническую поддержку по добавлению анонсов в Cloud Interconnect.

Настройте таблицы маршрутизации в VPC interconnectНастройте таблицы маршрутизации в VPC interconnect

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

К подсети в зоне с основным NGFW (подсеть A.A.A.0/24 в зоне A) примените таблицу маршрутизации, содержащую более специфичные маршруты (с префиксами /17 в примере) к подсетям в VPC dmz и app. Префиксы из этой таблицы должны быть добавлены в настройки анонсов для приватных соединений зоны доступности с основным NGFW.

Префикс назначения Next hop
С.С.0.0/17 IP-адрес FW-A в VPC interconnect
С.С.128.0/17 IP-адрес FW-A в VPC interconnect
D.D.0.0/17 IP-адрес FW-A в VPC interconnect
D.D.128.0/17 IP-адрес FW-A в VPC interconnect

К подсети в зоне с резервным NGFW (подсеть B.B.B.0/24 в зоне B) примените другую таблицу маршрутизации, содержащую менее специфичные маршруты (с префиксами /16 в примере) к подсетям в VPC dmz и app. Префиксы из этой таблицы должны быть добавлены в настройки анонсов для приватных соединений зоны доступности с резервным NGFW.

Префикс назначения Next hop
С.С.0.0/16 IP-адрес FW-A в VPC interconnect
D.D.0.0/16 IP-адрес FW-A в VPC interconnect

Благодаря этим настройкам трафик к подсетям в VPC dmz и app будет направляться на основной NGFW. При условии использования модуля route-switcher в случае отказа основного NGFW трафик будет направляться на резервный NGFW.

Использование более специфичных и менее специфичных префиксов в таблицах маршрутизации позволяет настроить анонсы приватных соединений Cloud Interconnect таким образом, чтобы трафик из инфраструктуры клиента к подсетям в VPC dmz и app направлялся в зону с основным NGFW, а в случае отказа этой зоны перенаправлялся в зону с резервным NGFW.

Создайте приватные соединения Cloud InterconnectСоздайте приватные соединения Cloud Interconnect

Познакомьтесь с вариантами организации услуги Cloud Interconnect в документации. Для обеспечения отказоустойчивости подключения к услуге рекомендуется организация нескольких транков — по одному в каждой точке присутствия.

Воспользуйтесь инструкцией для организации приватного соединения в зависимости от Вашего сценария подключения к услуге Cloud Interconnect.

При оформлении обращения в поддержку Yandex Cloud для каждого приватного соединения в анонсах подсетей по зонам доступности необходимо указать:

  1. Для зоны доступности с основным NGFW:
    • Префиксы из таблицы маршрутизации, примененной к подсети основного NGFW в VPC interconnect. В примере для зоны ru-central1-a это более специфичные префиксы /17. Благодаря этим анонсам трафик из инфраструктуры клиента к подсетям в VPC dmz и app будет приходить в зону с основным NGFW.
    • Префикс подсети для сетевого интерфейса основного NGFW в VPC interconnect и другие префиксы подсетей из VPC interconnect в этой зоне, которые необходимо анонсировать в собственную инфраструктуру клиента.
  2. Для зоны доступности с резервным NGFW:
    • Префиксы из таблицы маршрутизации, примененной к подсети резервного NGFW в VPC interconnect. В примере для зоны ru-central1-b это менее специфичные префиксы /16. Благодаря этим анонсам в случае отказа зоны с основным NGFW трафик из инфраструктуры клиента к подсетям в VPC dmz и app будет приходить в зону с резервным NGFW.
    • Префикс подсети для сетевого интерфейса резервного NGFW в VPC interconnect и другие префиксы подсетей из VPC interconnect в этой зоне, которые необходимо анонсировать в собственную инфраструктуру клиента.

Для приведенного в этом документе примера укажите следующую информацию в разделе vpc:

vpc: 
  vpc_net_id: <идентификатор_для_VPC_interconnect> 
    vpc_subnets:
      ru-central1-a: [A.A.A.0/24, C.C.0.0/17, C.C.128.0/17, D.D.0.0/17, D.D.128.0/17]
      ru-central1-b: [B.B.B.0/24, C.C.0.0/16, D.D.0.0/16]

Была ли статья полезна?

Предыдущая
Интеграция с корпоративным сервисом DNS
Следующая
Настройка сетевой связности между подсетями BareMetal и Virtual Private Cloud
Проект Яндекса
© 2025 ООО «Яндекс.Облако»