Протоколы
IPSec ESP — Encapsulating Security Payload
Часть IPSec-стека, отвечающая за шифрование и аутентификацию полезной нагрузки IP-пакета. Работает в режимах transport и tunnel. Использует IP protocol number 50, что делает её тривиально детектируемой современными DPI.
Что это
ESP (Encapsulating Security Payload) — компонент IPSec-стека из RFC 4303, обеспечивающий confidentiality (шифрование), authenticity (HMAC или AEAD) и целостность полезной нагрузки IP-пакета. Вместе с IKE/IKEv2 (key exchange) и опциональным AH (Authentication Header) формирует классический IPSec, разработанный IETF в 1990-х как стандарт корпоративных site-to-site VPN.
В 2026 ESP — это legacy: его всё ещё используют Cisco ASA, FortiGate, MikroTik и встроенные iOS/macOS клиенты, но в антицензурных сценариях он мёртв.
Как это работает
IPSec живёт между L3 и L4. ESP добавляет к пакету собственный заголовок и trailer, оборачивая исходную нагрузку:
[ IP header ][ ESP header ][ payload (encrypted) ][ ESP trailer ][ ESP auth ]Два режима:
- Transport mode. Шифруется только payload (TCP/UDP-сегмент), IP-заголовок остаётся открытым. Используется для host-to-host защиты.
- Tunnel mode. Шифруется весь исходный IP-пакет целиком, оборачивается в новый IP-заголовок (часто с публичными адресами VPN-gateway’ев). Это и есть классический «site-to-site VPN».
Шифрование — обычно AES-128/256 в режимах CBC+HMAC или GCM (AEAD). Современный baseline: AES-256-GCM + HMAC-SHA256 для целостности.
Ключевая особенность: ESP — это отдельный L4-протокол с IP protocol number 50 (AH — 51). Не TCP, не UDP. То есть в IP-заголовке поле Protocol = 50, и любой firewall/DPI видит это первым байтом после стандартного 20-байтного IP-header.
NAT и NAT-T
Протокол 50 не имеет портов — а NAT-таблицы у домашних роутеров построены вокруг пары IP+порт. Поэтому классический ESP не работает через NAT. Решение — NAT-T (NAT Traversal, RFC 3948): ESP-пакет заворачивается в UDP с портом 4500. Заголовок становится IP → UDP:4500 → ESP → payload. На 2026 NAT-T включён по умолчанию во всех современных IPSec-стеках, но добавляет 8 байт overhead.
Почему это важно для пользователя VPN
Для российского пользователя в 2026 IPSec/IKEv2 практически непригоден как способ обхода блокировок:
- Тривиальная детекция. ТСПУ видит IP protocol = 50 в первом байте пакета или UDP:4500 в случае NAT-T. Никакого fingerprint-анализа не требуется. Блокировка IPSec — это правило в одну строку, и в 2025–2026 операторы его массово выкатили (МТС, Билайн, МегаФон).
- Active probing. Если протокол всё-таки доходит, IKE handshake начинается с предсказуемого SA proposal — DPI может верифицировать «VPN» с вероятностью 99%.
- Альтернативы лучше во всём. WireGuard даёт ту же криптографию + UDP-only с произвольным портом, проще конфигурируется и быстрее. Для обхода — VLESS Reality, AmneziaWG, Hysteria 2.
Где IPSec ESP всё ещё уместен: внутри корпоративной сети, между офисами на железных Cisco/Fortinet, в условиях зрелого compliance (FIPS 140-2 / 140-3), где WireGuard ещё не сертифицирован. Для домашнего пользователя в РФ — забыть.
Связанные термины
IKEv2 — protocol для обмена ключами в IPSec. WireGuard — современный наследник идеи site-to-site VPN, без legacy-ESP. AEAD — режим шифрования, на котором стоит ESP-GCM. MTU/PMTU — overhead ESP в tunnel-mode съедает ~50–80 байт MTU.
Источники
- RFC 4303 — IP Encapsulating Security Payload — основная спецификация.
- RFC 3948 — UDP Encapsulation of IPsec ESP Packets — NAT-T.
- RFC 7296 — IKEv2 — обмен ключами.
- strongSwan documentation — наиболее популярный open-source IPSec-стек.