Налаштування 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.

Отримайте консультацію інженера для оцінки вашого проєкту. Зв'яжіться з нами для замовлення послуги.

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