При планировании миграции сервисов компании в Yandex Cloud (в прошлом, Яндекс.Облако) у ИТ-специалистов резонно возникает вопрос каким образом предоставить доступ к этим сервисам для сотрудников компании, и каким образом организовать взаимодействие между сервисами в Yandex Cloud и сервисами, расположенными в локальной сетевой инфраструктуре.
Может прийти идея о доступе к сервисам в Yandex Cloud по публичным адресам, при первоначальном анализе она кажется наиболее простой в реализации, однако при более детальном рассмотрении возникает ряд вопросов:
?
Риски информационной безопасности увеличиваются из-за попыток взлома, несанкционированного доступа к сервисам и DDoS-атак. Это требует постоянного контроля уязвимостей и защиты сервисов от атак, что увеличивает затраты.
?
Некоторые сервисы компании могут быть запрещены для публикации в сети Интернет.
?
С увеличением количества публикуемых сервисов растут расходы на публичные адреса, поскольку первоначальная квота составляет 2 статических и до 8 публичных адресов в одном облаке.
?
Для двухстороннего доступа между сервисами в Yandex Cloud и локальной инфраструктурой требуется предоставление публичных адресов локальным сервисам, что может привести к дополнительным расходам.
Альтернативным решением является использование приватных адресов для взаимодействия с сервисами в Yandex Cloud. Это можно реализовать, организовав VPN-соединение между Yandex Cloud и сетевой инфраструктурой компании или установив выделенное соединение, называемое Cloud Interconnect.
Интеграция с помощью IPSec:
Наиболее простым способом является построение IPSec туннеля между облаком и сетевой инфраструктурой компании. Схематично такое соединение можно представить так:
Yandex Cloud предлагает несколько готовых решений для организации IPSec-туннелей:
Можно использовать любой другой образ роутера или фаервола (CheckPoint, Palo Alto, Huawei и т.д.). Однако стоит отметить, что с запуском таких образов могут возникнуть проблемы, и может потребоваться доработка нативного образа для работы с Yandex Cloud.
IPSec-инстанс
IPSec-инстанс (IPSec instance) позволяет строить IPSec-туннели типа точка-точка (site-to-site) между облаком и VPN-шлюзом компании.
Преимуществами данного решения являются низкая стоимость владения и отсутствие необходимости в дополнительном лицензировании.
К недостаткам можно отнести отсутствие поддержки динамической маршрутизации и необходимость наличия статических публичных адресов на каждом VPN-шлюзе.
Cisco CSR 1000v
Cisco CSR 1000v позволяет реализовывать более сложные схемы построения VPN между облаком и сетью компании. Один из сценариев — построение DMVPN с организацией динамических многоточечных IPSec-туннелей между облаком и офисами компании.
Другой сценарий — построение IPSec-туннелей с динамическими публичными адресами, где статический публичный адрес требуется только на HUB-маршрутизаторе. Cisco CSR 1000v поддерживает различные протоколы динамической маршрутизации и политики QoS.
Недостатками по сравнению с IPSec-инстансом являются более высокая стоимость владения и необходимость лицензирования — пропускная способность маршрутизатора при использовании образа Cisco CSR 1000v без лицензии ограничена 100 Кбит/с. Для снятия ограничения требуется покупка и установка лицензии.
Mikrotik CHR
Достоинством Mikrotik CHR является более низкая стоимость владения и лицензий по сравнению с Cisco CSR 1000v, а также поддержка динамической маршрутизации, в отличие от IPSec-инстанса.
Основной недостаток — плохая совместимость с гипервизорами на базе архитектуры x86, что может вызывать проблемы в высоконагруженных системах. Пропускная способность Mikrotik CHR без лицензии ограничена 1 Мбит/с.
Cisco ASA
Cisco ASA предоставляет широкие возможности для организации высокопроизводительных VPN-соединений и клиентского доступа к ресурсам в облаке через защищенные соединения.
Достоинствами являются удобство управления политиками доступа между облаком и инфраструктурой компании, а также интеграция с решениями Cisco для создания высокозащищенной и гибкой инфраструктуры компании.
Если скорости в 1 Гб/с окажется недостаточно, потребуется организовать Cloud Interconnect. Cloud Interconnect позволяет установить выделенное соединение между локальной сетевой инфраструктурой компании и Yandex Cloud.
Заказать его можно у вашего оператора связи (Ростелеком, Эквант, Наука-Связь, Эр-Телеком, ТТК и др.) Точка стыка с Yandex Cloud происходит на ММТС-9, где присутствуют, вероятно, все операторы России и не только.
Рядом представлена схема такого соединения:
Основой решения Cloud Interconnect является магистральный канал с пропускной способностью от 100 Мбит/с до 10 Гбит/с и более. Для организации магистрального канала используется оптический стык стандарта 10Ge LR-LC с оборудованием Yandex Cloud;
Поверх магистрального канала создается выделенное соединение. Для обеспечения резервирования можно подключить несколько выделенных соединений к одной виртуальной сети (разграничение двух выделенных соединений в одном магистральном канале осуществляется с помощью VLAN);
Для обмена маршрутной информацией и передачи трафика необходимо настроить BGP-сессию между сетевым оборудованием компании и Yandex Cloud. Количество принимаемых префиксов ограничено: можно анонсировать не более 500 маршрутов. В случае превышения этого порога BGP-сессия будет сброшена и инициализирована заново.
Получение услуги Cloud Interconnect возможно через подачу заявки в техническую поддержку Yandex Cloud.
В этой статье мы рассмотрели способы организации взаимодействия с сервисами, расположенными в Yandex Cloud.
Если после прочтения статьи у вас остались вопросы, пожалуйста, используйте форму обратной связи. Наши инженеры свяжутся с вами и с радостью ответят на все ваши вопросы.