VPN туннели и IPsec

1) Зачем IPsec и когда он уместен

• Site-to-Site: on-prem ↔ cloud, cloud ↔ cloud, DC ↔ DC.
• Client VPN: админ-доступ, jump-host, break-glass.
• Backhaul/Transit: хабы и spoke-VPC/VNet (hub-and-spoke).
• IPsec уместен, когда нужен стандартный, интероперабельный стек, аппаратное ускорение (AES-NI/DPDK/ASIC), строгие криптополитики и совместимость с сетевым железом.

2) Базовые понятия (быстрый дайджест)

IKEv2 (Phase 1) — согласование параметров/аутентификация (RSA/ECDSA/PSK), создание IKE SA.
IPsec ESP (Phase 2) — шифрование трафика, Child SA (SA для конкретных префиксов/интерфейсов).
PFS — эпhemerality (Diffie-Hellman group) для каждого Child SA.
NAT-T (UDP/4500) — инкапсуляция ESP, если есть NAT по пути.
DPD — Dead Peer Detection, замена сломанной SA.
Rekey/Reauth — обновление ключей до истечения (lifetime/bytes).

• IKE: `AES-256-GCM` или `AES-256-CBC + SHA-256`, DH `group 14/19/20` (2048-бит MODP или ECP).
• ESP: `AES-GCM-256` (AEAD), PFS теми же группами.
• Lifetimes: IKE 8–24 ч, Child 30–60 мин или по объему трафика (например, 1–4 ГБ).

3) Топологии и типы туннелей

3.1 Route-based (предпочтительно)

Виртуальный интерфейс (VTI) на каждой стороне; маршруты/динамические протоколы (BGP/OSPF) несут префиксы. Проще масштабировать и сегментировать, лучше для overlapping CIDR (с NAT-политиками).

3.2 Policy-based (селекторы трафика)

Списки «источник↔назначение» в SA. Подходит для простых S2S без динамической маршрутизации; сложнее при множестве префиксов.

3.3 GRE-over-IPsec / VXLAN-over-IPsec

Инкапсуляция L3/L2 поверх шифрованного канала: мультипротокол, удобно для BGP (несут keepalive) и для случаев, где нужен мультикаст/ECMP в underlay.

4) Сегментация, маршрутизация и отказоустойчивость

BGP поверх VTI/GRE: обмен префиксами, MED/LocalPref/communities для приоритетов, max-prefix защита.
ECMP/Active-Active: пара туннелей параллельно (разные провайдеры/POP).
Active-Passive: резервный туннель с более высоким AD/LocalPref, DPD ускоряет переключение.
Split-tunnel: только корпоративные префиксы через VPN; интернет — локально (снижение задержек/стоимости).
Пересекающиеся CIDR: NAT-политики на краях или прокси-подсети, по возможности — редизайн адресации.

5) MTU, MSS и производительность

IPsec/NAT-T overhead: −~60–80 байт на пакет. Ставьте MTU 1436–1460 для VTI/туннелей.
MSS-clamp: для TCP выставляйте `MSS=1350–1380` (зависит от underlay), чтобы исключить фрагментацию.
Включите PMTUD и логируйте ICMP «Fragmentation Needed».
Аппаратные offload/fast-path (DPDK, AES-NI, ASIC) значительно уменьшают нагрузку на CPU.

6) Надежность и безопасность ключей

PFS обязателен; Rekey до истечения 70–80% lifetime.
Аутентификация: по возможности ECDSA сертификаты от корпоративного CA (или cloud-CA), PSK — только временно и с высокой энтропией.
CRL/OCSP или короткие срок действия сертификатов.
Журналы аутентификации и алерты при повторяющихся неудачных IKE.

7) Облака и особенности провайдеров

AWS: AWS Managed VPN (policy-based/route-based), TGW (Transit Gateway), VGW/CGW. Для перфоманса/масштаба — Direct Connect + IPsec как бэкап.
GCP: Cloud VPN (Classic/HA), Cloud Router (BGP); для throughput — Interconnect.
Azure: VPN Gateway (Policy/Route-based), VNet-to-VNet, ExpressRoute для L2/L3 приватки.
Private Endpoints/Privatelink: трафик к PaaS лучше вести через приватные интерфейсы вместо NAT egress.

8) Kubernetes и сервис-меш

Ноды K8s внутри приватных сетей; Pod CIDR не должен «вылезать» в удаленные площадки — маршрутизируйте Node CIDR и проксируйте сервисы через ingress/egress-шлюзы.
Istio/Linkerd mTLS поверх IPsec — отдельные домены доверия.
Egress-контроль: запрет прямого выхода из pod в интернет (NetworkPolicy), разрешение — на VTI/VPN.

9) Мониторинг и журналы

Туннель-SLA: latency, jitter, packet loss, up/down состояния SA.
BGP: соседства, префиксы, flap-счетчики.
Логи IKE/ESP: аутентика, rekey, DPD события.
Экспорт в Prometheus (через snmp_exporter/telegraf), алерты на churn SA и деградацию RTT/PLR.
Трейсы/логи приложений помечайте `site=onprem|cloud`, `vpn=tunnel-X` для корреляции.

10) Траблшутинг (чек-лист)

1. Файрволы: разрешены UDP/500, UDP/4500, протокол 50 (ESP) по пути (или только 4500 при NAT-T).
2. Часы/NTP синхронны — иначе IKE падает из-за таймингов/сертификатов.
3. Параметры IKE/ESP совпадают: шифры, DH, lifetimes, селекторы.
4. NAT-T включен, если есть NAT.
5. DPD и rekey: не слишком агрессивны, но и не ленивы (DPD 10–15s, rekey ~70% lifetime).
6. MTU/MSS: зажмите MSS, проверьте ICMP «need fragmentation».
7. BGP: фильтры/communities/AS-path, нет ли «blackhole» из-за wrong next-hop.
8. Логи: IKE SA established? Child SA created? SPI меняется? Есть ли replay-ошибки?

11) Конфиги (референсы, укороченные)

11.1 strongSwan (route-based VTI + IKEv2)

ini
/etc/ipsec. conf conn s2s keyexchange=ikev2 auto=start left=%defaultroute leftid=@onprem. example leftsubnet=0. 0. 0. 0/0 leftauth=pubkey leftcert=onprem. crt right=203. 0. 113. 10 rightid=@cloud. example rightsubnet=0. 0. 0. 0/0 rightauth=pubkey ike=aes256gcm16-prfsha256-ecp256!
esp=aes256gcm16-ecp256!
dpdaction=restart dpddelay=15s ikelifetime=12h lifetime=45m installpolicy=no      # route-based через VTI

bash ip tunnel add vti0 local 198. 51. 100. 10 remote 203. 0. 113. 10 mode vti ip link set vti0 up mtu 1436 ip addr add 169. 254. 10. 1/30 dev vti0 ip route add 10. 20. 0. 0/16 dev vti0

11.2 VyOS (BGP поверх VTI, MSS clamp)

bash set interfaces vti vti0 address '169. 254. 10. 1/30'
set interfaces vti vti0 mtu '1436'
set protocols bgp 65010 neighbor 169. 254. 10. 2 remote-as '65020'
set protocols bgp 65010 neighbor 169. 254. 10. 2 timers holdtime '9'
set firewall options mss-clamp interface-type 'all'
set firewall options mss-clamp mss '1360'

11.3 Cisco IOS (IKEv2/IPsec profile)

cisco crypto ikev2 proposal P1 encryption aes-gcm-256 integrity null group 19
!
crypto ikev2 policy P1 proposal P1
!
crypto ikev2 keyring KR peer CLOUD address 203. 0. 113. 10 pre-shared-key very-long-psk
!
crypto ikev2 profile IKEV2-PROF match address local 198. 51. 100. 10 authentication local pre-share authentication remote pre-share keyring local KR
!
crypto ipsec transform-set ESP-GCM esp-gcm 256 mode transport
!
crypto ipsec profile IPSEC-PROF set transform-set ESP-GCM set ikev2-profile IKEV2-PROF
!
interface Tunnel10 ip address 169. 254. 10. 1 255. 255. 255. 252 tunnel source 198. 51. 100. 10 tunnel destination 203. 0. 113. 10 tunnel protection ipsec profile IPSEC-PROF ip tcp adjust-mss 1360

12) Политики и комплаенс

Криптопрофили и списки разрешенных шифров централизованы (security baseline).
Ротация ключей/сертов с напоминаниями и автоматизацией.
Аудит-логи IKE/IPsec в неизменяемом хранилище (WORM/Object Lock).
Сегментация: VRF/VR-домены для prod/stage/dev и карточного контура (PCI DSS).

13) Специфика iGaming/финансов

Data residency: трафик с PII/платежными событиями идет по IPsec только в рамках разрешенных юрисдикций (маршрутизация по VRF/меткам).
PSP/KYC: если доступ дают private connectivity — используйте; иначе — egress-прокси с mTLS/HMAC, allowlist FQDN.
Журналы транзакций: параллельная запись (на on-prem и в облаке) через IPsec/Privatelink; неизменяемые логи.
SLO «пути денег»: отдельные туннели/маршруты с приоритетом и повышенным мониторингом.

14) Антипаттерны

PSK навсегда, одна «общая» секретная фраза.
Policy-based со множеством префиксов — «ад админов» (лучше VTI+BGP).
Игнорирование MTU/MSS → фрагментация, скрытые таймауты, 3xx/5xx «без причин».
Один туннель без резерва; один провайдер.
Отсутствие NTP/clock-sync → спонтанные падения IKE.
Шифры «по умолчанию» (устаревшие группы/MD5/SHA1).
Нет алертов на flap SA/BGP и рост RTT/PLR.

15) Чек-лист prod-готовности

• IKEv2 + AES-GCM + PFS (группа 14/19/20), согласованные lifetimes, rekey ~70%.
• VTI/GRE, BGP с фильтрами/communities, ECMP или hot-standby.
• NAT-T включен (при необходимости), открыты UDP/500/4500, ESP по пути.
• MTU 1436–1460, MSS clamp 1350–1380, PMTUD активен.
• DPD 10–15s, Dead Peer реакция и быстрая переустановка SA.
• Мониторинг SA/BGP/RTT/PLR; логи IKE/ESP в централизованном сборе.
• Авто-ротация сертов/ключей, короткие TTL, OCSP/CRL, алерты.
• Сегментация (VRF), split-tunnel, политика egress «deny-by-default».
• Облачные гейтвеи (AWS/GCP/Azure) протестированы на реальной нагрузке.
• Документированные runbook’и фейловера и расширения канала.

16) TL;DR

Стройте route-based IPsec (VTI/GRE) с IKEv2 + AES-GCM + PFS, динамической маршрутизацией BGP, резервом по двум независимым линкам и корректной MTU/MSS. Включите NAT-T, DPD и регулярный rekey, мониторьте SA/BGP/RTT/PLR, храните логи аутентификации. В облаках используйте managed-шлюзы и PrivateLink; в Kubernetes — не «таскайте» Pod CIDR через VPN. Для iGaming держите юрисдикции и платежной контур изолированными, с ужесточенными SLO и аудитом.