VPN под микроскопом: как реально ходят пакеты в туннеле и где теряются байты

Что на самом деле делает VPN с пакетами

Путь IP-пакета без VPN

Начнем с простого. Представьте, что у нас есть обычный IP-пакет от вашего ноутбука к серверу. Он получает локальный MAC-адрес шлюза, попадает на роутер провайдера, делает пару прыжков и спокойно доставляется получателю. Минимум магии, чистая маршрутизация. Никаких лишних оберток, только оригинальный заголовок IPv4 или IPv6, плюс транспортный заголовок TCP или UDP, и полезная нагрузка. Красота.

Теперь посмотрите на это глазами коммутатора: кадр влетает, L2 таблица подсказывает порт, кадр вылетает. На L3 маршрутизатор смотрит в таблицу маршрутизации, обновляет TTL, возможно — фрагментирует, если MTU слишком мала. И все. В таком режиме вы живете, пока не нужен защищенный канал или доступ к удаленной сети. Тогда на сцену выходит VPN и начинает перепаковывать этот самый IP-пакет как матрешку.

Путь IP-пакета через туннель

С VPN все становится веселее. Ваш исходный IP-пакет больше не идет напрямую в интернет. Клиент инкапсулирует его в новый пакет: добавляет внешний IP-заголовок (до сервера VPN), поверх — UDP или ESP, а иногда и дополнительный служебный заголовок самого протокола туннеля. Внутренний пакет становится «полезной нагрузкой». Он зашифрован и спрятан, как письмо в конверте, которое кладут в другой, более непрозрачный конверт.

На выходе сервер VPN снимает внешнюю оболочку, проверяет аутентификацию, расшифровывает и выпускает из тоннеля уже оригинальный внутренний IP-пакет. Тот получает свой второй шанс пройти обычным интернетом, но уже от имени узла на стороне сервера или через маршрутизацию в корпоративную сеть. Дорого? Да. Но безопасно и управляемо, если правильно посчитать оверхед и MTU.

Транспорт против туннеля: где граница

Запомните простое правило. Транспорт — это как мы доставляем пакеты (UDP, TCP, QUIC), а туннель — это как мы их упаковываем и где будем распаковывать. Некоторые VPN используют UDP как транспорт (WireGuard, OpenVPN-UDP), другие — собственный протокол уровня IP (ESP в IPsec). Но и те, и другие по сути делают одно: инкапсулируют ваш исходный IP-пакет во внешний.

Нас интересует техническая граница: между внутренней полезной нагрузкой и внешним транспортом. Здесь рождается overhead. Здесь ломается PMTUD. Здесь появляется задержка из-за шифрования. Мы будем смотреть именно на эту линию разреза, слой за слоем, чтобы понимать, почему пакеты вдруг фрагментируются, а TCP-коннекты замедляются, хотя у вас 1 Гбит/с на тарифе.

Где прячется криптография

Шифрование сидит между внутренним пакетом и внешним транспортом. В IPsec ESP это шифротекст поверх внутреннего пакета плюс служебные поля ESP и ICV. В WireGuard шифруется полезная часть Data Message, а заголовок UDP и внешний IP остаются видимыми. В OpenVPN шифруется содержимое собственного протокола поверх UDP или TCP, часто с HMAC и опциональным TLS-оверлеем на канале управления.

Важный момент: криптография задает выравнивание, добавляет теги аутентичности (обычно 16 байт) и может требовать IV или nonce. Эти байты никуда не деваются. Они увеличивают размер каждого пакета. Значит, нам придется уменьшать MTU на туннельном интерфейсе или зажимать MSS для внутренних TCP-соединений, чтобы пакеты не рвались на куски и не терялись в вечном танце фрагментации.

Инкапсуляция по слоям: вложенные куклы

Внешний и внутренний IP

Минимальная картина такова: внутренний IP-пакет формируется приложением, а затем VPN-клиент кладет его внутрь внешнего контейнера. Этот внешний контейнер — новый IP-заголовок, адресованный к серверу туннеля. И да, у нас теперь два IP: внутренний говорит «куда» внутри защищенной логики, внешний — «как доехать до VPN-концентратора». На Wireshark это видно как два уровня IP, но внутренний обычно скрыт, пока вы не расшифруете трафик на конечной точке.

Именно этот двойной IP — суть терминов «tunnel mode» и «transport mode» в IPsec. В tunnel mode у нас полноценный новый IP-заголовок и полностью спрятанный внутренний. В transport mode шифруется только полезная нагрузка, а внешний IP — это исходный. Для корпоративных маршрутов и удаленного доступа чаще применяют tunnel mode.

UDP или TCP как конверт для туннеля

Часто туннель используют UDP как транспорт. Почему? Проще и стабильней для прохода NAT, меньше накладных расходов на контроль перегрузки, меньше задержек на потерях. WireGuard идет именно так: UDP поверх внешнего IP, внутри зашифрованный пакет. OpenVPN в UDP-режиме — похожая история. А вот OpenVPN-TCP строит «VPN в TCP», что удобно при строгих прокси, но чревато эффектом TCP-over-TCP meltdown — дублирующиеся механизмы контроля перегрузки конфликтуют и наказывают вас задержками.

Когда используется ESP (протокол 50 на уровне IP), внешнего UDP может и не быть. Но в реальной жизни чаще встречаем NAT-T: ESP прячут в UDP на порту 4500, чтобы обмануть NAT. Это добавляет 12 байт (UDP 8 байт плюс 4 байта Non-ESP Marker), зато стабильно проходит домашние роутеры и провайдеровские устройства.

Маркировка протоколом: ESP, GRE, L2TP

На внешнем уровне ваш туннель узнают по протоколам. ESP — номер 50, AH — 51, GRE — 47, L2TP — UDP порт 1701, WireGuard — обычно UDP 51820 (но часто меняют для маскировки), OpenVPN — UDP 1194 по умолчанию, TCP 443 у консерваторов. Эти числа важны для фильтров tcpdump и Wireshark, да и для сетевых политик на межсетевых экранах.

Сама маркировка помогает понять, что мы видим: если esp — значит IPsec, если gre — значит поверх будет ещё один IP или L3 протокол, если udp.port==51820 — вероятен WireGuard. Любопытный трюк: некоторые провайдеры в 2026 году начали активней DPI на UDP с аномальными паттернами, поэтому QUIC-based VPN набирают силу, а часть решений прячет туннель в HTTP/3-трафик. Но это уже про укрытие на уровне транспорта.

Фрагментация и сборка

Инкапсуляция увеличивает размер пакета. Если итог превышает MTU линка, маршрутизатор либо фрагментирует, либо кидает ICMP «Fragmentation Needed», если выставлен DF. При VPN мы часто видим невидимую глазу фрагментацию внешних пакетов и разрушительные потери производительности. Каждый фрагмент — дополнительная работа, риск перезагрузок и таймаутов для TCP.

Правильная стратегия: заранее рассчитывать итоговый размер и подрезать MTU на туннеле. Или зажимать MSS для TCP-сессий (уменьшая размер сегмента так, чтобы влезал в MTU с запасом на все обертки). В 2026 году большинство провайдерских сетей по-прежнему живут на 1500 байт, так что высчитать 1360–1380 MSS для IPsec NAT-T — не снобизм, а практичная необходимость.

Заголовки и их структура: от битов к смыслу

IPv4 и IPv6: какие поля критичны для VPN

В IPv4 нас волнуют: Total Length, Identification, Flags (DF, MF), Fragment Offset, TTL, Protocol, Header Checksum. DF говорит «не фрагментировать», а ICMP Type 3 Code 4 подскажет, что MTU меньше. В IPv6 другие механизмы: нет контрольной суммы в заголовке, фрагментация сдвинута к отправителю, а маршрутизаторы не фрагментируют. Поэтому PMTUD в IPv6 обязателен для жизни, иначе туннель будет «молчать» на больших пакетах.

Еще один нюанс — Traffic Class и Flow Label. От них зависит QoS и иногда поведение сетей с приоритизацией. В VPN-туннеле внешний IP может нести один QoS, а внутренний — другой, и это повод поговорить о копировании DSCP. Многие админы в 2026-м явно копируют DSCP с внутреннего в внешний IPsec, чтобы сохранить приоритеты голоса и видео.

UDP и TCP: служебные числа и скрытые эффекты

UDP заголовок прост: Source Port, Destination Port, Length, Checksum — 8 байт. Минимум накладных расходов. Идеален для туннелей. TCP сложнее: 20 байт базового заголовка плюс опции (MSS, SACK, Timestamps). Внутренний TCP с MSS 1460 прекрасно живет на чистом Ethernet, но в туннеле ему тесно. Вот почему мы вводим MSS Clamping — принудительно уменьшаем MSS в SYN-пакете.

С TCP есть тонкая проблема под названием «TCP-over-TCP meltdown». Внешний TCP (например, OpenVPN поверх TCP) и внутренний TCP одновременно реагируют на потери и задержки. Двойная ретрансляция, двойное управление Congestion Window. Результат — латентность, дрожание, «вязкий» трафик под нагрузкой. Этот эффект не миф. Лучше избегать TCP поверх TCP, если нет железной необходимости.

ESP: SPI, Sequence, IV, Padding, ICV

ESP-пакет состоит из ESP Header (SPI 4 байта, Sequence Number 4 байта), зашифрованных данных (включая внутренний IP и транспорт), ESP Trailer (Padding, Pad Length, Next Header) и ESP Authentication Data (ICV, обычно 16 байт для GCM). При AES-GCM часто видим 8-байтовый explicit IV и 16-байтовый тег аутентичности. Плюс NAT-T добавляет UDP 8 байт и Non-ESP Marker 4 байта, итого ощутимо растет размер.

В туннельном режиме IPsec добавляет еще один внешний IP-заголовок (20 байт для IPv4, 40 для IPv6). Паддинг зависит от выравнивания блочного шифра и может съедать несколько байт на пакет. Вывод прост: у ESP есть стабильные константы и переменная часть. В производственных расчетах закладываем 50–70 байт overhead для IPv4 с NAT-T, и 70–90 байт для IPv6, чтобы не ошибиться.

OpenVPN и WireGuard: в чем отличие на уровне пакета

OpenVPN поверх UDP добавляет свой небольшой заголовок, HMAC и, в зависимости от конфигурации, IV/nonce. Часто суммарный overhead получается в районе 36–60 байт плюс внешний IP и UDP. В TCP-режиме добавляется TCP-заголовок и TLS-обвязка на канале управления, что повышает стабильность в капризных сетях, но бьет по задержкам и пропускной способности при потерях.

WireGuard минималистичен. Data Message включает служебный заголовок (получатель, счетчик) и шифрованную полезную нагрузку с 16-байтным тэгом Poly1305. На практике мы видим около 32 байт собственного заголовка WG поверх 8 байт UDP и 20/40 байт IP. То есть 60–80 байт на пакет — типичная оценка. Не идеально, но предсказуемо и быстро, особенно на железе с ускорением ChaCha20-Poly1305.

Overhead по-простому: во что обходится туннель

Базовая формула и примеры

Overhead — это сумма всех внешних заголовков и криптографических служебных байтов, которые мы добавили к внутреннему пакету. Формула для прикидки: Overhead = Внешний IP + Внешний транспорт (UDP/TCP) + Заголовок туннеля (ESP, WG, OpenVPN, GRE...) + Криптографический тэг + Паддинг/IV/nonce + Выравнивание. Звучит зубодробительно, но это просто арифметика.

Пример. Внутренний TCP-сегмент с полезной нагрузкой 1400 байт. Туннель IPsec NAT-T с AES-GCM: внешний IPv4 20 байт, UDP 8, Non-ESP Marker 4, ESP Header 8, IV 8, ICV 16, плюс паддинг 2–6 байт. Итого ~66–70 байт. Значит, итоговый пакет около 1470 байт. При линке с MTU 1500 должно влезть, но с запасом минимальным. Любая опция TCP или IPv6 может перевесить чашу и привести к фрагментации.

IPsec ESP: транспорт и туннель, NAT-T и расчет

В транспортном режиме IPsec не добавляет внешний IP-заголовок, экономя 20/40 байт. Но для удаленного доступа чаще нужен туннельный режим. В нем добавим внешний IP, и overhead становится заметным: IPv4 ESP без NAT-T обычно 42–60 байт, с NAT-T — 54–74 байта, в зависимости от набора полей и паддинга. Для IPv6 порог уходит вверх еще на 20 байт из-за более длинного IP-заголовка.

Практическое правило: если у вас IPsec с NAT-T, ставьте MTU туннеля 1400–1420 и MSS clamp на 1360–1380. Эти числа не взяты с потолка — они отражают типичную сумму заголовков и обеспечивают запас без фрагментации. Всегда тестируйте ping -M do с крупными пакетами, чтобы убедиться, что PMTUD не ломается на очередном странном межсетевом экране.

WireGuard, OpenVPN UDP и TCP: ориентиры по байтам

WireGuard при IPv4 обычно дает около 60 байт накладных расходов, при IPv6 — 80 байт. Отсюда стандартные рекомендации: MTU 1420 на интерфейсе wg0 — золотая середина. Для OpenVPN-UDP в зависимости от шифрования и HMAC числа варьируются: 50–80 байт поверх IP/UDP — частый гость. Поэтому MTU 1400–1450 и MSS clamp на 1360–1420 обычно решают 90 процентов проблем.

OpenVPN-TCP — отдельная песня. Помимо 20 байт TCP (без опций) на внешний транспорт, сверху действуют механизмы перегрузки. В узких и «шумных» каналах TCP поверх TCP начинает мучиться. Где-то поможет TCP Fast Open или аккуратные настройки буферов, но в целом лучше по возможности оставаться на UDP и решать проникновение через прокси другими инструментами, вплоть до QUIC-транспорта.

GRE, L2TP, VXLAN: краткое сравнение

GRE добавляет минимум 4 байта базового заголовка, но часто ещё поле Key и Checksum, итог 8–12 байт плюс внешний IP. С учетом инкапсулируемого IP в GRE легко улетаем за 24–28 байт поверх внешнего IP. L2TPv2 работает поверх UDP (8 байт) и добавляет 6–12 байт заголовка L2TP плюс PPP, в итоге получается 14–24 байта перед шифрованием или поверх IPsec.

VXLAN ориентирован на L2 инкапсуляцию для датацентров: UDP 8 + VXLAN 8 + внешний IP и MAC на уровне канала. В VPN-контексте встречается реже, но принципы одинаковы: каждый байт заголовка отнимает место у полезной нагрузки. И чем больше вложенных «оболочек», тем важнее аккуратная настройка MTU и запрет неожиданных фрагментов по пути.

MTU, MSS и реальная скорость

Как посчитать MTU под ваш туннель

Алгоритм простой. 1) Определите суммарный overhead для вашего стека (например, 68 байт для IPsec NAT-T IPv4). 2) Вычтите его из 1500, если ваш underlay — Ethernet без джамбо. 3) Добавьте запас 10–20 байт на вариации (опции TCP, непредвиденные поля). 4) Установите полученную MTU на туннельном интерфейсе и проверьте ping с флагом DF и постепенным увеличением размера пакета.

Пример: WireGuard на домашнем роутере. Считаем около 60–64 байт overhead для IPv4. 1500−64=1436. Округляем вниз до 1420 (общая рекомендация), чтобы гарантировать простор. Далее настроим MSS clamp на 1360–1380 и проверим скачивание крупных файлов и VoIP. Если исчезли «подвисания» и исчезли потерянные фрагменты — мы дома.

MSS Clamping: быстрый способ приручить TCP

MSS (Maximum Segment Size) — максимум полезных данных TCP внутри одного сегмента. Если туннель режет MTU, нужно уменьшить MSS, чтобы сегменты помещались без фрагментации. Способ — менять MSS в SYN-пакетах проходящих TCP-соединений на границе. Почти все современные шлюзы и даже SOHO-маршрутизаторы в 2026-м это умеют в два клика.

Практически: для MTU 1420 ставим MSS 1360. Для MTU 1400 — MSS 1360 тоже часто «в тему», с учетом непредсказуемости опций TCP. Проверяем через tcpdump, что SYN уходит с нужным MSS. Если видим странные ретрансмиссии и спайки RTT, чуть-чуть опускаем MSS на 10–20 байт и снова тестируем.

Jumbo фреймы, PMTUD и бит DF

Джамбо-фреймы (MTU больше 1500) облегчают жизнь, но не всегда доступны. В датацентрах — да, в интернете — редко. PMTUD в теории должен работать идеально: отправитель подстраивает размер под наименьшее звено. На практике ICMP часто режут, и отправитель так и не узнает, что пакет не пролезает. Отсюда «висящие» соединения и загадочные затыки.

Если у вас контроль над обоими концами — включайте PMTUD и не глушите ICMP Type 3 Code 4. Если нет — берите управление в свои руки: консервативная MTU, MSS clamp и явные тесты ping с DF. Это скучно, согласен. Зато работает и экономит часы отладки.

Практические пресеты 2026

Рынок сводит все к короткому списку: WireGuard IPv4 — MTU 1420, MSS 1360; IPsec NAT-T IPv4 — MTU 1400–1420, MSS 1360–1380; OpenVPN-UDP — MTU 1400–1450, MSS 1360–1420; IPv6 на том же стеке — минус еще 20 байт сверху. И не забывайте про джиттер: стабильно низкий джиттер почти всегда важнее абстрактного увеличения MTU на 20–30 байт.

В 2026-м многие провайдеры внедряют QoS Per-Hop Behavior на магистралях, а корпоративные VPN научились копировать DSCP из внутреннего IP во внешний. Если ваш голос стал чище после такого копирования — не удивляйтесь. Пакеты наконец-то получили заслуженный приоритет.

Практика: захваты трафика и разбор в Wireshark

Фильтры для tcpdump и Wireshark

Нужны быстрые фильтры? Для IPsec: esp или udp port 4500 (NAT-T), плюс isakmp на udp 500 для IKEv2. Для WireGuard: udp port 51820 (или ваш кастомный). Для OpenVPN-UDP: udp port 1194. Для L2TP: udp port 1701. Для GRE: ip proto 47. По месту — фильтр host для IP сервера VPN, чтобы не ловить весь город.

Рецепт: на клиенте tcpdump -ni eth0 udp port 51820 и host X.X.X.X — покажет только WireGuard к нужному узлу. На сервере полезно смотреть внешние интерфейсы для оценки потерь и внутренний туннельный интерфейс (wg0, tun0, ipsecX), чтобы сравнить направления. Разница в счетчиках — индикатор боли: где-то мы теряем кадры или сталкиваемся с PMTUD-адом.

Читаем поля пакетов руками

В Wireshark разверните пакет ESP. Видите SPI и Sequence? SPI подсказывает, какому SA принадлежит пакет. Sequence растет на каждый пакет — удобный маркер потерь и повторов. В WireGuard обратите внимание на Counter — монотонный счетчик, который защищает от повторов и упорядочивает пакеты. У OpenVPN заголовок проще, но тоже даёт Key ID и тип сообщения.

Посмотрите на внешний IP: TTL, DF-бит, размер. Внутренний IP обычно скрыт, но на конечных хостах вы увидите конечную распаковку на интерфейсе туннеля. Если внешний видит фрагментацию — ищите, кто ломает MTU. Если счетчики ICV errors растут — проверяйте ключи, desync или повреждения по пути. Простая логика, но каждый шаг экономит часы.

Отладка MTU и фрагментов: быстрые трюки

Команда ping -M do -s 1472 8.8.8.8 (Linux) помогает определить максимальный размер без фрагментации для внешнего пути при MTU 1500 (1472 байта полезной нагрузки плюс 28 байт IP+ICMP). Для туннеля проверяйте внутри, через pings между внутренними адресами. Есть потери на больших пакетах — режем MTU или MSS. Просто. Эффективно.

Еще один прием: включите логирование «Fragmentation needed» на граничном роутере или фаерволе. Если видите всплески — PMTUD не проходит. Временно облегчите жизнь TCP MSS-клампингом и позже разберитесь, где ICMP теряется. Иногда это один злосчастный ACL, который годами копируют из шаблона, а теперь мешает вам жить.

Безопасные дампы и маскировка чувствительных данных

Снимайте дампы на внешнем интерфейсе, если не хотите светить внутренние IP и порты приложений. Внешний трафик шифрован, так что вы не раскрываете содержимое. Но помните: метаданные остаются видимыми — кто, куда и когда. Если нужно делиться дампом с подрядчиком, режьте pcap по адресам и времени и применяйте анонимизацию в Wireshark (Replace MAC/IP).

В 2026-м в компаниях стали нормой политики «privacy by design» для отладки. Храните дампы недолго, шифруйте архивы, удаляйте ключи после закрытия инцидента. И пишите небольшие README к каждому дампу: фильтры, версия клиента, MTU. Через месяц вы сами себе скажете спасибо.

Криптография и безопасность на пакете

Аутентификация и защита от повторов

Каждый защищенный пакет проходит проверку целостности и подлинности. В IPsec ESP счетчик SeqNum и окно повторов защищают от реигров. В WireGuard моногамная пара ключей и счетчик counter делают то же самое. Любая рассинхронизация счетчиков заставит сбрасывать пакеты, поэтому ловим рост «Replay errors» как индикатор проблем связи или «перезапуска без rekey».

Идентификация Security Association (SPI в IPsec) говорит, каким ключом шифровать и как проверять теги. Переключение ключей (rekey) происходит по времени или по объему трафика. Если rekey задерживается, растет риск выработки nonces. Следите за таймерами. В хорошем логе смены ключей — как смены передач в машине: кратко, мягко, без рывков.

GCM против ChaCha20-Poly1305

AES-GCM стал стандартом де-факто в IPsec и TLS благодаря аппаратным ускорителям (AES-NI, ARMv8 Cryptography Extensions). Он быстр и хорошо параллелится. ChaCha20-Poly1305 сияет там, где нет AES-ускорения и нужна предсказуемая производительность на всех платформах, что и объясняет выбор WireGuard. Оба обеспечивают AEAD: шифрование и аутентификацию за один заход.

По задержкам ChaCha20 часто дает ровную линию без редких спадов даже на бюджетных ARM-маршрутизаторах. AES-GCM бьет рекорды на серверах с аппаратными блоками. В 2026-м гибриды редки, но эксперименты с постквантовыми негодяями уже идут на уровне обмена ключами (IKEv2 и TLS 1.3) — полезно знать, но пока это не про каждый пакет, а про рукопожатия.

PFS, rekey и таймеры жизни ключей

Perfect Forward Secrecy означает, что компрометация долгосрочных ключей не раскроет прошлые сессии. На уровне пакетов это незаметно, но именно PFS заставляет периодически менять сессионные ключи. Жизнь SA ограничена по времени и объему. В логах это выглядит как плановая смена SPI и обновление счетчиков. Если таймеры слишком длинные, повышается риск повторного использования nonces.

Практически: для высоконагруженных туннелей ставят rekey каждые 30–60 минут или по 1–2 ГБ трафика, в зависимости от профилей риска. Короткие таймеры — это больше накладных рукопожатий, но лучшая крипто-гигиена. Найдите свой баланс и держите телеметрию под рукой.

Метаданные и утечки шаблонов

Хотя содержание шифруется, метаданные наружу проглядывают: IP адреса концов, порты, размеры пакетов, интервалы. DPI учится узнавать «почерк» WireGuard или OpenVPN по статистике размеров и частотам keepalive. Борьба — в маскировке трафика: QUIC-транспорт, плавающие порты, заполнители (padding), имитация HTTP/3 профиля.

С точки зрения инженерии, лучшая защита — разнообразие. Регулярный rekey, переменный размер keepalive, отсутствие аномалий вроде идеально фиксированных размеров пакетов. Это похоже на маскарад: чем естественнее вы двигаетесь в толпе, тем меньше шансов, что вас вычленят взглядом охранника DPI.

Оптимизация и кейсы 2026

Домашний роутер и WireGuard: быстрый выигрыш

Кейс: домашний ARM-роутер с провайдером 500 Мбит/с. Поднимаем WireGuard, ставим MTU 1420, включаем flow offload и fq_codel на очередях, MSS clamp 1360. Результат: 400–480 Мбит/с сквозной VPN при задержке плюс 2–4 мс к базовой. Ничего экзотического, просто аккуратная настройка. Даже стриминг в 4К спокойно идет через такой туннель.

Добавьте мониторинг: каждые 5 минут короткий iperf3 на 2–3 секунды, лог RTT на pings к нескольким регионам, счетчики drops на интерфейсе. Через неделю у вас будет живая карта качества канала и понятный baseline. Когда начнутся «вечерние просадки», вы это увидите, а не будете спорить вслепую с провайдером.

Корпоративный IPsec с NAT-T: MTU против реальности

Кейс: филиалы на IPsec (IKEv2, AES-GCM), NAT-T неизбежен. На старте видим жалобы на «медленный RDP и странный Zoom». Первая находка — эпизодическая фрагментация внешних пакетов и отрезанные ICMP. Решение: выставили MTU 1400, MSS clamp 1360, разрешили ICMP Type 3 Code 4 по периметру, включили DSCP copy для EF (голос). Пара часов — и графики стабилизировались, голос перестал хрипеть.

Финальный штрих — балансировка туннелей по двум провайдерам и health-check на BFD. На уровне пакетов мы просто удержали стабильность размеров и приоритета, а не пытались «лечить» приложения. Иногда все гениальное — скучно инженерное.

OpenVPN в облаке и TCP meltdown: как пережить

Кейс: OpenVPN поверх TCP в облачном сегменте с прокси. Потери 0.2–0.5 процента, но RTT гуляет на 20–40 мс. Внутренний TCP и внешний TCP одновременно реагируют, создавая стоячие волны. Веб-приложение стонет. Временная мера: увеличить TCP window, включить BBRv2 на внешнем канале, убрать лишний TLS-рефреш. Долгосрочно — перейти на UDP-транспорт или QUIC-обертку, если политика разрешает.

Параллельно задействуйте логический трюк: уменьшите MTU и MSS, чтобы снизить вероятность ретрансляций больших пакетов. Это не панацея, но без нее любое лечение — пустая трата времени. И да, протестируйте альтернативные порты и маскировку под HTTP/3, современные DPI удивительно терпимы к QUIC в 2026-м.

SASE, QUIC VPN и тренды 2026

В 2026 году растет доля SASE и SDP решений: клиент соединяется к ближайшей точке присутствия, а дальше трафик идет по частной магистрали с приоритизацией. На уровне пакетов часто видим QUIC-транспорт, поверх которого катается туннелирование и шифрование. Это позволяет пройти корпоративные прокси и сэкономить на сложных исключениях.

Еще один тренд — аппаратные ускорители на краю: SmartNIC с offload для IPsec, eBPF/XDP для быстрой обработки, ARMv9 с SVE2 дает стабильный ChaCha20 на маршрутизаторах уровня филиала. Постквантовые гибриды для IKEv2 и TLS 1.3 пока в пилотах, но это уже близкая реальность. Мир готовит ключи будущего, и это захватывающе.

Чек-лист диагностики туннеля на уровне пакетов

Симптомы и быстрые тесты

Симптом: страницы грузятся рывками, видео заикается, RDP «резиновый». Тест 1: ping с DF и брутфорс размера — ловим безопасный порог. Тест 2: tcpdump на внешний интерфейс — ищем фрагменты и потери. Тест 3: смотрим MSS в SYN-пакетах и убеждаемся, что кламп применился. Тест 4: проверяем счетчики replays и ICV errors на IPsec/WG.

Если после клампа и корректного MTU ситуация не меняется — ищем джиттер на провайдере или проблемы с QoS. Простой тест — iperf3 в разные порты и DSCP, смотреть стабильность. Иногда достаточно поменять провайдера last mile, и чудеса случаются. Жизнь.

Карта решений по ходу анализа

Решения идут лесенкой: 1) Уточнить оверхед и выставить MTU туннеля ниже на 80–100 байт от 1500 с запасом. 2) Включить MSS clamp. 3) Восстановить ICMP «Fragmentation Needed» по периметру. 4) При необходимости перейти на UDP-транспорт. 5) Настроить приоритизацию для голоса и интерактивных потоков. 6) Следить за rekey и обновлять версии клиентов.

Если ни один шаг не помог — копните в сторону DPI и прокси. Возможно, ваш трафик обрабатывают как «подозрительный» и душат. Тест с QUIC-оберткой или сменой порта на 443/UDP иногда открывает все двери. Это не обход политики, это проверка гипотезы.

Команды для разных ОС

Linux: ip link set dev wg0 mtu 1420; iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu; tcpdump -ni eth0 udp port 51820. Windows: netsh interface ipv4 set subinterface "Ethernet" mtu=1500 store=persistent и настройка MTU на адаптере VPN через GUI или PowerShell; Packet capture — через pktmon или Wireshark.

BSD и pfSense: в интерфейсе WireGuard/OpenVPN есть поля MTU и MSS. Не забудьте включить scrub в pf для нормализации и разрешить нужные типы ICMP. На роутерах с аппаратным offload проверьте, что шифрование не «вываливается» в софт из-за экзотической опции. Лишний флаг — минус сотни мегабит.

Ошибки новичков и как их избежать

Классика: оставить MTU 1500 в туннеле, не клампить MSS и потом удивляться фрагментации. Вторая ошибка — выключить ICMP «чтобы безопасно», а потом месяц лечить «медленный интернет». Третья — TCP поверх TCP без крайней необходимости. Четвертая — игнорировать счетчики ошибок ESP и WireGuard, где черным по белому написано, что идет повтор или брак.

Пятая — не тестировать на маленьких пакетах и интерактивных сервисах. Пропускная способность — это половина картины. Дрожание и задержка — другая половина. Когда обе половины в порядке, вы чувствуете это сразу. Все клики — живые, видео не мажет, а файлы летят как пули.

FAQ: коротко и по делу

Как быстро прикинуть MTU для моего VPN, если я не знаю точный overhead

Возьмите 1500 и вычтите 100 байт для консервативной оценки. Поставьте MTU 1400 на туннель и MSS 1360. Проверьте ping с DF с полезной нагрузкой от 1300 до 1472, чтобы найти потолок. Если все проходит — смело поднимайте MTU ступенями по 10 байт до первого отказа и отступите на 20–30 байт. Это грубый, но рабочий метод, который спасает в незнакомых сетях, где ICMP режут и документа нет ни у кого.

Почему WireGuard часто быстрее OpenVPN на тех же серверах

Две причины. Во-первых, меньший и стабильный overhead с предсказуемой криптографией ChaCha20-Poly1305. Во-вторых, дизайн ядра протокола: меньше копирований, меньше контекстных переключений, проще реализация. На бюджетных ARM и x86 без AES-NI WireGuard обычно обгоняет OpenVPN в 1.5–2 раза по пропускной способности и держит более ровный RTT под нагрузкой. Исключения бывают, но редко.

Насколько вреден TCP-over-TCP и когда он допустим

Вреден там, где есть потери и джиттер. Два уровня контроля перегрузки начинают мешать друг другу, и латентность улетает. Допустим, когда политику не обойти и нужен трафик только по TCP 443 через прокси или DPI. В таком случае спасают грамотные буферы, BBR на внешнем TCP и хороший кэш. Но если есть шанс уйти на UDP или QUIC — уходите. Это не вопрос вкуса, это вопрос физики сети.

Почему у меня обрывается IPsec при больших файлах, хотя пинг маленький

Скорее всего, MTU/PMTUD. Маленький пинг — это пакеты по 64 байта, а большие файлы толкают сегменты под потолок. Если ICMP «Fragmentation Needed» блокируется, отправитель не знает, что нужно уменьшиться, и вы видите таймауты, ретрансмиссии и «обрывы». Лекарство — правильная MTU на туннеле, MSS clamping и разрешение нужного ICMP. Проверить легко: ping с DF на крупных размерах и tcpdump покажут истину.

Есть ли смысл копировать DSCP из внутреннего IP во внешний при VPN

Да, если у вас есть QoS по пути и вы хотите, чтобы голос, видео и интерактив получали приоритет не только внутри вашей сети, но и в канале до точки выхода. Многие операторы в 2026-м учитывают DSCP в транспортных ядрах. Главное — согласовать значения и не злоупотреблять EF/CS5, иначе попадете под агрессивный полисинг. Сначала пилот, потом тираж — золотое правило.

Стоит ли уже переходить на постквантовые алгоритмы в VPN

Для повседневного трафика — пока рано. Реальные постквантовые схемы появляются в IKEv2/TLS как гибриды на этапе рукопожатия. На уровне пакетов вы разницы почти не заметите сегодня, а накладные расходы и совместимость могут подвести. Но для чувствительных данных с долгим сроком жизни — пилоты уже осмысленны. Следите за обновлениями в ваших реализациях и держите план миграции.

Как понять, что моя сеть «узкая» именно из-за VPN, а не провайдера

Сравните бенчмарки на том же канале: iperf3 напрямую и через туннель, плюс замер RTT и джиттера на коротких пакетах. Если падение скорости более 30–40 процентов и растет CPU на шифровании, виноват VPN-стек или настройки MTU/MSS. Если падение такое же без VPN и растет задержка без нагрузки — проблема на линии провайдера. Включите короткий постоянный мониторинг, и картина проявится буквально за сутки.