Интеграция локальной инфраструктуры с публичными облаками в единое сетевое пространство перестала быть прерогативой крупных корпораций. Сегодня это необходимое условие для гибкости, отказоустойчивости и экономической эффективности IT-среды. Статическая маршрутизация, требующая ручного обновления таблиц при каждом изменении, становится узким местом и источником инцидентов. Динамическая маршрутизация BGP решает эту проблему, автоматически распространяя информацию о сетевых путях между вашим оборудованием и облачными маршрутизаторами.
Это руководство предоставляет конкретные, проверенные на практике инструкции. Вы настроите безопасные туннели (IPsec или WireGuard), поднимете сессии BGP между оборудованием разных вендоров и облачными сервисами, а также автоматизируете всю конфигурацию с помощью Terraform. Результат - отказоустойчивая гибридная сеть, где изменения в одной части инфраструктуры автоматически отражаются во всей системе.
Зачем объединять локальную сеть с облаками в единое целое
Гибридная архитектура, где часть сервисов работает в локальном дата-центре, а часть - в публичных облаках, стала стандартом. Она лежит в основе сценариев плавной миграции без простоя, аварийного восстановления (Disaster Recovery) и распределенных приложений, требующих низких задержок для части компонентов. Статическая маршрутизация в таких условиях создает операционные риски: добавление новой подсети в облаке требует ручного обновления таблиц на каждом локальном маршрутизаторе, что ведет к человеческим ошибкам и долгому времени восстановления при сбоях.
Динамическая маршрутизация BGP устраняет эти проблемы. Протокол автоматически обменивается информацией о доступных сетях между всеми участниками. При добавлении нового VPC в AWS его префикс автоматически анонсируется в вашу локальную сеть. При обрыве одного из VPN-туннелей BGP мгновенно убирает нерабочий путь из таблицы маршрутизации, перенаправляя трафик через резервный канал. Это обеспечивает высокую доступность и сокращает время реакции на инциденты с часов до секунд.
Типичные проблемы, которые решает динамическая маршрутизация BGP
Представьте ситуацию: после расширения облачной инфраструктуры в Azure добавили новую подсеть для тестового стенда. Статический маршрут на корпоративном маршрутизаторе забыли обновить. В результате часть пользователей теряет доступ к критическим внутренним ресурсам, что приводит к простою. BGP предотвращает такие инциденты, автоматически распространяя новые маршруты.
Другая частая проблема - балансировка нагрузки между двумя каналами связи с облаком (например, через двух разных провайдеров). Вручную распределять трафик сложно и неэффективно. BGP позволяет использовать оба канала одновременно (multipath), увеличивая общую пропускную способность и обеспечивая мгновенный failover при падении одного из них.
Для более глубокого понимания принципов работы протоколов в корпоративных сетях, рекомендуем наше руководство по динамической маршрутизации OSPF, BGP и EIGRP для отказоустойчивых сетей.
Выбор технологии подключения: от VPN до выделенных каналов
Первый шаг к созданию единого сетевого пространства - выбор способа физического или логического соединения. Решение зависит от требований к пропускной способности, задержкам, безопасности и бюджету.
IPsec VPN остается стандартом де-факто для корпоративных сред благодаря широкой поддержке оборудования и сильной криптографии. WireGuard предлагает более высокую производительность и простоту конфигурации, что делает его идеальным для быстрого старта и сценариев с балансировкой трафика. Для продакшн-нагрузок с высокими требованиями к предсказуемости производительности и низким задержкам существуют выделенные каналы: AWS Direct Connect, Azure ExpressRoute и Google Cloud Interconnect. Они предоставляют прямое физическое соединение с SLA, но требуют больше времени и бюджета на настройку.
Быстрый старт: настраиваем безопасный туннель WireGuard между локальным маршрутизатором и облаком
WireGuard - отличный выбор для быстрого развертывания защищенного туннеля. Начнем с генерации ключей на локальном хосте с Linux.
# Генерация приватного и публичного ключей
wg genkey | tee privatekey | wg pubkey > publickey
Далее создаем Cloud VPN Gateway в выбранном облаке. Например, в Google Cloud это можно сделать через консоль или gcloud CLI, указав тип "WireGuard" и прикрепив к целевой VPC. После создания шлюза вы получите его публичный IP-адрес и настройки для пиринга.
Пример конфигурационного файла WireGuard для облачной виртуальной машины (например, в GCP):
[Interface]
PrivateKey = <ВАШ_ПРИВАТНЫЙ_КЛЮЧ_ОБЛАЧНОЙ_ВМ>
Address = 10.0.100.1/32
ListenPort = 51820
[Peer]
PublicKey = <ПУБЛИЧНЫЙ_КЛЮЧ_ВАШЕГО_ЛОКАЛЬНОГО_МАРШРУТИЗАТОРА>
AllowedIPs = 192.168.100.0/24, 10.0.0.0/16
Endpoint = <ПУБЛИЧНЫЙ_IP_АДРЕС_ВАШЕГО_ЛОКАЛЬНОГО_РОУТЕРА>:51820
PersistentKeepalive = III
Аналогичная конфигурация для маршрутизатора MikroTik (в терминале или WinBox):
/interface wireguard add name=wg-cloud1 private-key="<ВАШ_ПРИВАТНЫЙ_КЛЮЧ>" listen-port=51820
/interface wireguard peers add interface=wg-cloud1 public-key="<ПУБЛИЧНЫЙ_КЛЮЧ_ОБЛАЧНОЙ_ВМ>" allowed-address=10.0.100.1/32 endpoint-address=<IP_ОБЛАЧНОГО_ШЛЮЗА> endpoint-port=51820
/ip address add address=192.168.100.1/24 interface=wg-cloud1
После применения конфигураций проверьте связность командой ping 10.0.100.1 с локальной стороны и ping 192.168.100.1 с облачной.
Когда нужна максимальная надежность: настройка IPsec VPN с резервированием
Для сред, где критична совместимость с существующей инфраструктурой и корпоративными стандартами, подойдет IPsec. Рассмотрим настройку двух туннелей для резервирования между Cisco ASA и Azure VPN Gateway.
На стороне Azure создайте Virtual Network Gateway типа "VPN" с PolicyBased или RouteBased VPN. Запишите предварительный общий ключ (Pre-shared Key) и публичный IP-адрес шлюза.
Конфигурация на Cisco ASA (версия IOS 9.x+):
crypto ikev2 policy 10
encryption aes-gcm-256
integrity sha512
group 24
prf sha512
lifetime seconds 86400
!
crypto ipsec ikev2 ipsec-proposal AZURE
protocol esp encryption aes-gcm-256
protocol esp integrity sha-512
!
crypto map AZURE_MAP 10 match address AZURE_ACL
crypto map AZURE_MAP 10 set pfs group24
crypto map AZURE_MAP 10 set peer <AZURE_VPN_GW_IP_1> <AZURE_VPN_GW_IP_2>
crypto map AZURE_MAP 10 set ikev2 ipsec-proposal AZURE
crypto map AZURE_MAP 10 set transform-set AZURE_TSET
crypto map AZURE_MAP interface outside
!
tunnel-group <AZURE_VPN_GW_IP_1> type ipsec-l2l
tunnel-group <AZURE_VPN_GW_IP_1> ipsec-attributes
ikev2 remote-authentication pre-shared-key <YOUR_KEY>
ikev2 local-authentication pre-shared-key <YOUR_KEY>
!
access-list AZURE_ACL extended permit ip 192.168.100.0 255.255.255.0 10.0.0.0 255.255.0.0
Ключевые параметры: использование IKEv2, сильных алгоритмов шифрования (AES-GCM-256) и групп Диффи-Хеллмана 24 (2048-bit). Настройка двух пиров (peer) с разными IP-адресами Azure шлюза создает резервирование на уровне туннелей.
Сердце гибридной сети: настройка динамической маршрутизации BGP
После установки соединения наступает этап настройки динамического обмена маршрутами. BGP работает поверх установленного туннеля (VPN или выделенного канала). В гибридном контексте вы будете настраивать eBGP (External BGP) между вашей автономной системой (AS) и AS облачного провайдера. Ключевые понятия: ASN (Autonomous System Number), атрибуты AS_PATH и NEXT_HOP.
Облачные провайдеры используют управляемые BGP-сессии. Вам не нужно настраивать демон BGP на их стороне - достаточно указать параметры сессии при создании VPN-подключения или Cloud Router.
Пример конфигурации BGP для связки Cisco IOS и AWS Transit Gateway
AWS Transit Gateway - центральный хаб для маршрутизации между VPC и локальными сетями. Настройка состоит из двух частей.
1. Конфигурация на маршрутизаторе Cisco:
router bgp 65001
bgp router-id 192.168.100.1
bgp log-neighbor-changes
neighbor 169.254.100.2 remote-as 64512
neighbor 169.254.100.2 ebgp-multihop 255
neighbor 169.254.100.2 update-source Tunnel100
!
address-family ipv4
network 192.168.100.0 mask 255.255.255.0
neighbor 169.254.100.2 activate
neighbor 169.254.100.2 soft-reconfiguration inbound
neighbor 169.254.100.2 route-map FILTER_IN in
neighbor 169.254.100.2 route-map ANNOUNCE_OUT out
exit-address-family
!
ip prefix-list LOCAL_NETS seq 5 permit 192.168.100.0/24
!
route-map ANNOUNCE_OUT permit 10
match ip address prefix-list LOCAL_NETS
Здесь 65001 - ваш приватный ASN (из диапазона 64512-65534), а 64512 - ASN, который AWS назначает для сессии с Transit Gateway. Адрес 169.254.100.2 - IP-адрес BGP-пира на стороне AWS, назначенный внутри туннеля.
2. Настройка в AWS Console: при создании VPN Attachment к Transit Gateway в разделе "BGP Configuration" укажите ваш локальный IP-адрес туннеля (например, 169.254.100.1) и ваш ASN (65001). AWS автоматически установит сессию.
Проверить состояние можно командой на Cisco: show ip bgp summary. Вы должны увидеть сессию в состоянии Established.
Настройка BGP между MikroTik RouterOS и Google Cloud Router
Для интеграции с Google Cloud используется ресурс Cloud Router. Настройка на MikroTik:
/routing bgp instance set default as=65001 router-id=192.168.200.1
/routing bgp peer add name=gcp-peer1 remote-address=169.254.200.2 remote-as=64513 tcp-md5-key="your_md5_key" instance=default
/routing bgp network add network=192.168.200.0/24
В Google Cloud Console создайте Cloud Router в нужной VPC. При создании VPN-туннеля выберите опцию "Dynamic (BGP)" и укажите параметры: ваш локальный IP туннеля (169.254.200.1), ваш ASN (65001) и анонсируемые префиксы (192.168.200.0/24). Google Cloud автоматически назначит свой ASN (обычно 64513) и IP-адрес пира (169.254.200.2). Важно: для приватных ASN в облачных конфигурациях часто требуется активировать опцию "Allow ASN override" или аналогичную.
Для комплексного понимания маршрутизации в multi-cloud средах, изучите наше руководство по настройке маршрутизации между AWS, GCP и Azure.
Критические моменты: атрибуты сообществ (BGP Communities) и фильтрация маршрутов
BGP Communities - это метки, которые можно присваивать маршрутам для управления политиками на удаленной стороне. Например, облачные провайдеры используют специальные значения communities для управления распространением маршрутов между регионами.
Фильтрация маршрутов - важнейший элемент безопасности. Вы должны явно разрешать только те префиксы, которые ожидаете получить. Пример фильтра на маршрутизаторе Juniper (JunOS), который принимает только маршруты из облака Azure (ASN 12076) и отклоняет все остальные:
policy-statement ACCEPT-AZURE {
term azure-routes {
from {
protocol bgp;
as-path "12076";
}
then accept;
}
term reject-all {
then reject;
}
}
Аналогично, на анонсирование следует накладывать строгий prefix-list, разрешающий только ваши внутренние сети. Это предотвращает случайную или злонамеренную утечку маршрутов в интернет.
Автоматизация и отказоустойчивость: от конфигураций к инфраструктуре как коду
Ручное управление конфигурациями маршрутизаторов и облачных ресурсов не масштабируется. Инфраструктура как код (IaC) с использованием Terraform обеспечивает повторяемость, контроль версий и быстрое восстановление после сбоев.
Модуль Terraform для развертывания гибридного подключения к Azure с BGP
Приведенный ниже код HCL создает в Azure необходимые ресурсы для подключения по VPN с динамической маршрутизацией.
# variables.tf
variable "local_gateway_ip" {
description = "Public IP address of your on-premises VPN device"
type = string
}
variable "on_premises_cidr" {
description = "CIDR of your on-premises network"
type = string
default = "192.168.0.0/16"
}
variable "bgp_asn" {
description = "Your on-premises BGP ASN"
type = number
default = 65001
}
# main.tf
resource "azurerm_local_network_gateway" "onprem" {
name = "lgw-onprem"
location = azurerm_resource_group.main.location
resource_group_name = azurerm_resource_group.main.name
gateway_address = var.local_gateway_ip
address_space = [var.on_premises_cidr]
bgp_settings {
asn = var.bgp_asn
bgp_peering_address = "169.254.100.1" # IP inside the tunnel
}
}
resource "azurerm_virtual_network_gateway_connection" "vpn" {
name = "conn-to-onprem"
location = azurerm_resource_group.main.location
resource_group_name = azurerm_resource_group.main.name
type = "IPsec"
virtual_network_gateway_id = azurerm_virtual_network_gateway.main.id
local_network_gateway_id = azurerm_local_network_gateway.onprem.id
shared_key = "YourSecretKeyHere"
enable_bgp = true
}
После применения этой конфигурации (terraform apply) Azure подготовит VPN-шлюз и установит BGP-сессию с указанными параметрами. Добавление новой подсети в Azure VNet автоматически приведет к анонсированию ее префикса в вашу локальную сеть через BGP.
Для автоматизации развертывания и управления облачной инфраструктурой вы можете рассмотреть предложение от Timeweb Cloud, которое предоставляет гибкие инструменты для размещения и масштабирования IT-продуктов.
Схема резервирования: два облачных региона и два локальных канала
Высокодоступная архитектура предполагает устранение единых точек отказа. Рассмотрим схему, где локальный дата-центр подключен через двух разных интернет-провайдеров к двум разным регионам AWS (us-east-1 и eu-west-1).
На локальных маршрутизаторах настраиваются два отдельных VPN-туннеля (или выделенных канала) к двум разным Transit Gateway в разных регионах AWS. BGP-сессии поднимаются по обоим каналам. В конфигурации BGP на локальной стороне активируется функция multipath, позволяющая загружать балансировать трафик между обоими путями при условии одинаковой длины AS_PATH.
Механизм failover работает автоматически: если туннель в us-east-1 обрывается, BGP-сессия падает. Маршрутизатор немедленно удаляет все маршруты, полученные через этот пир, из таблицы маршрутизации. Весь трафик автоматически перенаправляется через оставшийся канал в eu-west-1. Время конвергенции составляет обычно несколько секунд. Для тонкого управления предпочтением путей можно использовать атрибут MED (Multi-Exit Discriminator), указывая более низкое значение для предпочтительного канала (например, с более низкой задержкой).
Подробное сравнение архитектур и управляемых сервисов маршрутизации в разных облаках вы найдете в статье Динамическая маршрутизация в облаках 2026: практическое сравнение AWS Transit Gateway, Azure VNet Peering и Google Cloud VPC.
Безопасность гибридной сети: не только шифрование туннеля
Шифрование данных в туннеле - лишь первый уровень защиты. Управляющая плоскость сети, особенно протокол BGP, также требует защиты. Основные угрозы включают утечку маршрутов (когда ваши внутренние префиксы ошибочно анонсируются в интернет), перехват BGP-сессии и DoS-атаки на управляющие порты маршрутизаторов.
Меры защиты:
- Аутентификация BGP-сессий: Используйте MD5-пароли или, предпочтительнее, TCP-AO (Authentication Option) для подтверждения легитимности пира.
- Строгая фильтрация маршрутов: Как уже упоминалось, настраивайте prefix-list и route-map для явного разрешения только ожидаемых префиксов на прием (inbound) и анонса (outbound).
- Сегментация с помощью VRF (Virtual Routing and Forwarding): Изолируйте управляющий трафик и сессии BGP в отдельном VRF, ограничив его доступность из рабочих подсетей.
- Мониторинг: Внедрите мониторинг изменений в таблице маршрутизации (RIB) с помощью таких инструментов, как BGPStream или ExaBGP. Немедленно реагируйте на появление неожиданных маршрутов.
Для дополнительной защиты периметра и управления доступом на уровне приложений в гибридной среде может потребоваться настройка продвинутых правил маршрутизации и фильтрации на хостах. В этом поможет руководство по VPN-маршрутизации на Linux с iptables, nftables и eBPF.
Чек-лист и типичные ошибки при настройке
Следуйте этому чек-листу для последовательной настройки:
- Проверка базовой связности: Убедитесь, что между внутренними интерфейсами туннеля (например, между 169.254.100.1 и 169.254.100.2) есть IP-связность (
ping). - Проверка ASN: Убедитесь, что локальный ASN не конфликтует с ASN облачного провайдера и является приватным (64512-65534) или официально полученным.
- Открытие портов на фаерволе: Разрешите TCP-порт 179 (BGP) между IP-адресами пиров на всех промежуточных фаерволах.
- Корректный Next Hop: В облачных конфигурациях часто требуется, чтобы Next Hop для анонсируемых маршрутов был установлен в IP-адрес туннеля на локальной стороне. Проверьте этот параметр в настройках Cloud Router или VPN-подключения.
- Согласование MTU: Установите корректный MTU на интерфейсах туннеля (обычно 1400-1420 для VPN поверх интернета), чтобы избежать фрагментации пакетов, которая может ломать BGP-сессии.
Типичные ошибки и их решение:
- "BGP сессия в состоянии Active (OpenSent)": Означает, что TCP-соединение установлено, но BGP Open message не был получен или отклонен. Проверьте совпадение ASN, аутентификацию и доступность порта 179.
- "Маршруты анонсируются, но не появляются в таблице маршрутизации (RIB)": Проверьте политики фильтрации (route-map, prefix-list) на стороне приемника. Убедитесь, что маршрут не отфильтрован и имеет валидный Next Hop.
- Асимметричная маршрутизация: Трафик идет в облако по одному пути, а возвращается по другому, что может сломать stateful фаерволы. Решение: используйте одинаковые политики маршрутизации для исходящего и входящего трафика или настройте фаерволы в stateless режиме.
Для диагностики используйте команды: show ip bgp summary (Cisco), /routing bgp peer print (MikroTik), show route receive-protocol bgp <peer-ip> (Juniper). В облачных консолях используйте встроенные логи и инструменты диагностики подключений (например, AWS VPN Connection Diagnostics, Azure Network Watcher Connection Troubleshoot).
Интеграция Windows Server в гибридную среду имеет свои нюансы. Подробные шаги описаны в статье о сетевой интеграции Windows Server с Azure и AWS.
Для автоматизации работы с AI-моделями в рамках ваших гибридных приложений может пригодиться сервис AiTunnel, предоставляющий единый API-доступ к более чем 200 нейросетям.