Настройка VPN-туннеля: офис и облачные платформы

Зачем нужен Site-to-Site VPN между офисом и облаком?

Мы регулярно сталкиваемся с задачей организации Site-to-Site VPN между офисом и облачными VPC (AWS, GCP, Azure). Требуется, чтобы сервисы в облаке видели внутренние хосты по приватным адресам — без NAT hairpin и лишних хопов. На практике здесь скапливается множество нюансов: несовпадение MTU на туннеле, разъезжающиеся Phase 2 SA на IKEv1, конфликты подсетей между офисом и дефолтным CIDR в VPC, или ситуация когда BGP-сессия поднялась, маршруты анонсируются, но трафик проходит только в одну сторону из-за асимметричного stateful firewall на корпоративном edge. За многолетний опыт мы выполнили более 50 проектов по интеграции офисов с облачными средами, поэтому знаем типовые подводные камни и способы их обхода. Сертифицированные инженеры гарантируют стабильность и безопасность каждого туннеля. Получите консультацию инженера по вашему проекту.

Какую топологию и протокол выбрать?

Для связки офис–облако используем IPsec IKEv2 как базовый транспорт. IKEv2 устанавливает соединение на 30% быстрее IKEv1 и надежнее восстанавливается после обрыва. GRE поверх IPsec применяем когда нужно гонять multicast или OSPF/BGP внутри туннеля, иначе overhead не оправдан.

Стандартная конфигурация AWS Site-to-Site VPN с BGP выглядит так:

Customer Gateway (CGW): внешний IP офисного маршрутизатора
Virtual Private Gateway (VGW) или Transit Gateway (TGW): на стороне AWS
BGP ASN клиента: 65001 (private range)
BGP ASN AWS: 64512 (дефолтный) или кастомный
Two tunnels: обязательно для HA, каждый с отдельным pre-shared key

AWS автоматически создаёт два туннеля с разными endpoint IP — это не избыточность ради галочки, а реальный failover. Первый туннель падает при обслуживании endpoint на стороне AWS — без второго получаем окно недоступности от 30 секунд до нескольких минут.

На стороне офиса типовая конфигурация для MikroTik (RouterOS 7.x):

/ip ipsec profile add dh-group=modp2048 enc-algorithm=aes-256 hash-algorithm=sha256 name=aws-profile
/ip ipsec proposal add auth-algorithms=sha256 enc-algorithms=aes-256-cbc lifetime=1h name=aws-proposal pfs-group=modp2048
/ip ipsec peer add address=<AWS_TUNNEL1_IP>/32 exchange-mode=ike2 name=aws-tunnel1 profile=aws-profile
/ip ipsec identity add peer=aws-tunnel1 secret=<PSK_TUNNEL1>
/ip ipsec policy add dst-address=10.0.0.0/16 peer=aws-tunnel1 sa-dst-address=<AWS_TUNNEL1_IP> \
    sa-src-address=<OFFICE_PUBLIC_IP> src-address=192.168.1.0/24 tunnel=yes

/ip firewall mangle add action=change-mss chain=forward new-mss=1387 out-interface=<ipsec-tunnel> \
 passthrough=yes protocol=tcp tcp-flags=syn

BGP поверх туннеля

Отметим: когда нужно анонсировать несколько подсетей или настроить failover между двумя туннелями, поднимаем BGP поверх IPsec. AWS Transit Gateway особенно удобен для hub-and-spoke топологий — несколько офисов подключаются к одному TGW, который уже маршрутизирует трафик между ними и VPC.

Пример конфигурации BGP на Cisco IOS для туннеля до AWS:

crypto isakmp policy 10
 encr aes 256
 hash sha256
 authentication pre-share
 group 14
 lifetime 28800
crypto ipsec transform-set AWS-TS esp-aes 256 esp-sha256-hmac
 mode tunnel
interface Tunnel1
 ip address 169.254.10.2 255.255.255.252
 tunnel source GigabitEthernet0/0
 tunnel destination <AWS_TUNNEL1_OUTSIDE_IP>
 ip tcp adjust-mss 1387
router bgp 65001
 neighbor 169.254.10.1 remote-as 64512
 neighbor 169.254.10.1 timers 10 30
 network 192.168.0.0 mask 255.255.0.0

Link-local адреса 169.254.x.x/30 — стандарт для BGP peer-адресов на AWS туннелях. Не пытайтесь использовать свои адреса — VGW их не примет.

Какие проблемы возникают при Site-to-Site VPN?

Конфликт CIDR. Сценарий: офис на 10.0.0.0/8, VPC создали с дефолтным 10.0.0.0/16. Туннель поднялся, BGP установился, но трафик до EC2-инстансов не идёт — локальный маршрут перекрывает туннельный. Решение: при создании VPC использовать 172.16.0.0/12 или 192.168.0.0/16 для облачных сетей, офисам оставить 10.x.x.x.

Dead Peer Detection. По умолчанию DPD на AWS туннелях — 10 секунд интервал, 3 попытки. При нестабильном ISP на офисной стороне туннель переинициализируется каждые 30 секунд. Если Phase 1 и Phase 2 не поднимаются быстро (Cisco IOS с crypto isakmp keepalive 10 periodic), получаем пакетные потери на каждом реконнекте.

Асимметричный маршрутинг. Офис имеет два ISP — failover через второй канал. Ответный трафик возвращается через основной. Stateful firewall на office edge дропает пакеты от «неожиданного» интерфейса. Лечится либо policy-based routing, либо выносом туннельного трафика в отдельную зону firewall без stateful inspection.

Как мы настраиваем Site-to-Site VPN: пошаговый процесс

1. Аудит сети — анализ существующей топологии, подсетей, оборудования и версий ПО.
2. Проектирование — выбор топологии (прямой туннель или Transit Gateway), протокола (BGP или статика), схемы адресации и HA.
3. Конфигурация — настройка IPsec и BGP на обеих сторонах, применение MSS clamping.
4. Тестирование — проверка failover (отключение одного туннеля), измерение времени восстановления, нагрузочное тестирование MTU.
5. Документация — схема сети, конфиги с комментариями, runbook для восстановления после сбоя.

Сравнение IKEv1 и IKEv2

Что входит в результат

После завершения работ вы получаете:

• Документированную схему сети (draw.io или Mermaid)
• Конфигурационные файлы с комментариями
• Runbook для восстановления туннеля после сбоя ISP
• Гарантию стабильности соединения (закреплено в договоре)

Сроки зависят от сложности: от 1 дня для простого туннеля до 2 недель для гибридной сети с AD, DNS и NTP. Стоимость рассчитывается индивидуально, средний чек — от $450–650.

Экономия на облачном трафике за счет оптимизации маршрутизации достигает 40%, а стоимость эксплуатации снижается на 20% благодаря автоматизации failover. Получите консультацию инженера для оценки вашего проекта. Свяжитесь с нами для заказа услуги.

RFC 4301 — стандарт IPsec. Дополнительно: документация AWS по VPN и официальное руководство MikroTik.