IPsec

AWS, Azure, GCP - все облака предлагают managed IPsec VPN для подключения on-premise. Это стандарт де-факто для enterprise VPN уже 30 лет. Понимание IPsec открывает двери в мир корпоративных сетей и multi-cloud архитектур.

• **Cloud connectivity:** AWS Site-to-Site VPN, Azure VPN Gateway, GCP Cloud VPN - всё это IPsec под капотом
• **IKEv2 на мобильных:** iOS и Android имеют встроенный IKEv2 клиент. Многие корпоративные VPN используют его вместо OpenVPN
• **Сетевое оборудование:** Cisco, Juniper, Fortinet - IPsec является lingua franca для site-to-site между разными вендорами

Предварительные знания

• VPN: Virtual Networks

Режимы IPsec

**IPsec** - набор протоколов для защиты IP-трафика. Работает на сетевом уровне (Layer 3), защищая любые протоколы выше: TCP, UDP, ICMP. Два режима работы: **Transport** и **Tunnel**.

**Tunnel Mode по умолчанию:** В большинстве VPN-конфигураций используется Tunnel Mode. Transport Mode - для специфичных сценариев (L2TP/IPsec, host-to-host).

Компоненты IPsec:

ESP - Encapsulating Security Payload

**ESP (Protocol 50)** - основной протокол IPsec. Обеспечивает шифрование (конфиденциальность), аутентификацию (целостность) и защиту от replay-атак.

**SPI (Security Parameter Index):** 32-битный идентификатор, связывающий пакет с конкретной SA (Security Association). Получатель по SPI находит ключи для расшифровки.

Алгоритмы шифрования в ESP:

**Replay Protection:** Sequence Number увеличивается с каждым пакетом. Получатель ведёт sliding window (~32-64 пакета). Пакеты с уже виденным или слишком старым номером отбрасываются.

AH - Authentication Header

**AH (Protocol 51)** обеспечивает только аутентификацию и целостность - **без шифрования**. Защищает также неизменяемые поля IP-заголовка. Сегодня почти не используется.

**Почему AH умер:** NAT меняет IP-адреса, что ломает ICV в AH. ESP с NAT-T (UDP encapsulation) проходит через NAT. ESP также даёт шифрование, которое AH не имеет.

Единственное преимущество AH - защита внешнего IP-заголовка. Но это редко нужно:

IKE - Internet Key Exchange

**IKE** - протокол согласования параметров и обмена ключами для IPsec. Работает по UDP порт 500 (или 4500 при NAT-T). Две версии: **IKEv1** (сложный) и **IKEv2** (рекомендуемый).

**IKEv1 vs IKEv2:** IKEv1 требовал 6-9 сообщений (Main Mode + Quick Mode). IKEv2 - всего 4 сообщения. Плюс IKEv2 имеет встроенный NAT-T, MOBIKE, и лучшую криптографию.

Методы аутентификации в IKE:

Security Associations (SA)

**Security Association (SA)** - контракт между двумя устройствами: какие алгоритмы использовать, какие ключи, какой трафик защищать. SA идентифицируется по **SPI** (Security Parameter Index).

**SA всегда в паре:** Для двустороннего трафика нужны две SA: одна для исходящего (outbound), другая для входящего (inbound). Каждая со своим SPI и ключами.

**SAD (Security Association Database)** и **SPD (Security Policy Database)**:

Итоги

• **Transport Mode** защищает payload, **Tunnel Mode** инкапсулирует весь пакет. Для VPN обычно Tunnel
• **ESP** (Protocol 50) - шифрование + аутентификация. AES-GCM рекомендован. **AH** (Protocol 51) - только auth, почти не используется
• **IKEv2** согласовывает параметры за 4 сообщения (2 RTT). Поддерживает PSK, сертификаты, EAP
• **SA** - контракт с ключами и параметрами. Всегда в паре (inbound/outbound). Хранится в SAD, политики в SPD

Связанные темы

IPsec - основа многих VPN-решений:

• VPN концепции — IPsec реализует Site-to-Site и Remote Access VPN на Layer 3
• WireGuard — Современная альтернатива IPsec с упрощённой криптографией

Вопросы для размышления

• Почему ESP победил AH, несмотря на то, что AH защищает больше (включая IP-заголовок)?
• Как Perfect Forward Secrecy (PFS) влияет на безопасность долгоживущих VPN?
• Почему облачные провайдеры используют IPsec, а не WireGuard для managed VPN?

Связанные уроки

• crypto-32-tls