Аудит сетевого периметра при DPI: какие корпоративные протоколы выживают в 2026

Зимой 2026 к нам обратилась торговая компания 28 РМ из СВАО — у них перестал работать удалённый доступ к складскому терминалу через VPN, а 1С-Облако стало регулярно «отваливаться» в обед. Внутренний админ грешил на интернет-провайдера, провайдер кивал на оборудование, оборудование молчало. Мы взялись за аудит периметра. То, что увидели за три рабочих дня, — это типичная картина 2026 года: половина протоколов, которые ещё в 2023-м работали из коробки, сегодня живут на честном слове, и единственный способ держать корпсеть рабочей — знать рейтинг живучести и проектировать схему под него. Дальше — отчёт с цифрами, что выживает, что умирает, и почему.

Что вообще делает DPI и зачем эта тема компании из 28 человек

Мифология DPI у клиентов часто звучит так: «нас никто не трогает, мы маленькие». Это правда и неправда одновременно. DPI на уровне транзитного провайдера или ТСПУ работает не пер-клиент, а пер-протокол: алгоритм один, прилетает в одну сторону всем. Если завтра ТСПУ начинает резать handshake WireGuard — режется и у вас, и у соседей. Маленьким бизнесам это даже хуже, чем большим: у крупного игрока есть бюджет на резерв, а 28 человек просто разойдутся по домам, когда «1С перестала».

В моей практике 2025-2026 годов DPI ломает три класса корпоративных задач. Первый — VPN в офис: классические OpenVPN UDP и WireGuard режутся в 80% мобильных подключений. Второй — звонки и видео: SIP по UDP без шифрования режется по сигнатуре, Zoom и Microsoft Teams живут только за счёт TLS-обёртки. Третий — мелкие SaaS, которые используют экзотические TLS-расширения (например, ESNI или старые ECH): провайдер дропает рукопожатие на этапе client hello.

Перед началом аудита я говорил партнёру клиента: «Раньше мы проектировали сеть от того, что нам нужно. Сейчас — от того, что разрешат через провайдера. Это неприятно, но это новая реальность». Он сначала возразил, что у них же VPN на Cisco стоит — должен работать. Через два часа замеров он принёс кофе и сказал «делайте, как считаете нужным».

Методология аудита: что мы замеряем за три дня

Аудит периметра у меня — это не отчёт ради отчёта, это план действий с конкретными числами. Я провожу его по шагам:

День 1. Топология и точки боли

Начинаю с того, что у клиента вообще есть. Записываю модели и прошивки роутеров, маршруты, таблицу NAT, состав VLAN, какие сервисы где живут, кто куда ходит. У торговой компании оказалось так: пограничный MikroTik RB5009 с RouterOS 7.13, две WAN (Билайн оптика 200/200 + LTE Мегафон как резерв), четыре VLAN (10 — офис, 20 — серверы, 30 — гостевой, 40 — IP-камеры). За периметром — облачный сервер 1С на Yandex.Cloud, банк-клиенты Сбер и Альфа, склад через VPN до партнёрского терминала на Wireguard, IP-телефония SIP на Mango Office.

День 2. Замеры протоколов

Затем я по каждому критичному протоколу прогоняю стандартный набор тестов с офисного канала и с резервного LTE. Замеряю стабильность handshake, jitter, потери, MTU path discovery. Использую mtr, scapy с самописными пакетами, openssl s_client, wg, ipsec verify. Получаю таблицу: какой протокол на каком канале и в какие часы работает.

День 3. Корреляция и план

На третий день я смотрю логи провайдера за две недели (через выгрузку у роутера), сопоставляю с инцидентами клиента, выделяю паттерны. Например, у этого клиента просадка 1С происходила строго с 12:00 до 14:00 — час пиковой нагрузки на ТСПУ их провайдера, который начинал агрессивнее «оптимизировать» TCP-окна. Дальше — отчёт и предложение исправления.

Рейтинг живучести протоколов: что показал замер

TLS 1.3 на 443/TCP — устойчивее всего

Стандартный HTTPS с TLS 1.3 на 443/TCP проходит везде и всегда. Это базовый фундамент интернета 2026, на котором ещё держится цифровая экономика. Замеры показали потерю пакетов 0,03%, jitter 4-7 мс на оптике Билайна, до 35 мс на LTE Мегафона. Все банк-клиенты, КонсультантПлюс, Я.360 — работают штатно.

Но есть нюанс. ТСПУ умеет читать SNI в TLS ClientHello. Если SNI попадает в чёрный список — соединение режется. У нашего клиента это никогда не случалось с легитимными доменами банков и 1С, но мы протестировали для информации: запросы к sci-hub.se, telegram.org, instagram.com рвутся через 2-3 секунды после handshake. Логика DPI — пропустить начало рукопожатия, посмотреть SNI, потом дропнуть TCP RST в обе стороны.

# Замер TLS 1.3 — что проходит, что нет
for sni in sberbank.ru consultant.ru 1cfresh.com instagram.com telegram.org; do
  echo "=== $sni ==="
  echo | timeout 5 openssl s_client -connect $sni:443 -servername $sni \
    -tls1_3 2>&1 | grep -E "Verify|subject|TLS|protocol" | head -5
  echo "RTT:"
  for i in 1 2 3; do
    curl -s -o /dev/null -w "%{time_total}\n" https://$sni/
  done
done

QUIC / HTTP/3 — нестабильно

QUIC по UDP на 443 — относительно новая история, и с ней у российских ТСПУ сложные отношения. На оптике Билайна QUIC проходит в 100% случаев, на LTE Мегафона — у нашего клиента QUIC сначала пропускался, потом резался, потом снова пропускался. На замерах за две недели разброс «работает/не работает» по часам составил от 15 до 90% успешных подключений. На моих собственных замерах в апреле-мае 2026 ситуация улучшилась, но я бы не строил критичные сервисы на QUIC.

В корпоративной сети мы поэтому отключили QUIC на уровне Chrome через GPO для рабочих станций — браузер пытается, не дожидается ответа, валится в TCP, теряет 200-400 мс на старте. Лучше сразу TCP.

# GPO: Chrome — отключить QUIC принудительно
HKLM\Software\Policies\Google\Chrome
    QuicAllowed = 0    (REG_DWORD)

# Edge — то же
HKLM\Software\Policies\Microsoft\Edge
    QuicAllowed = 0    (REG_DWORD)

IKEv2/IPSec на 500/4500 UDP — частично

Это наш основной протокол для VPN-туннелей между офисом и удалёнкой. Замеры показали интересное: на оптике провайдеров Билайн и МТС — стабильно. На мобильном Билайн (LTE) — часто отваливается NAT-keepalive на 4500 порту, туннель приходится поднимать заново раз в 20-40 минут. На Мегафоне — без проблем, но с замедлением пропускной способности до 12-15 Мбит/с (при канале 100).

Решение, которое мы используем у этого клиента: IKEv2 с пакетом MOBIKE (RFC 4555) и фрагментацией IKE_AUTH (RFC 7383). MOBIKE спасает при смене IP мобильного оператора, фрагментация — при ограничениях MTU на маршруте.

# strongSwan: конфигурация IKEv2 с MOBIKE и фрагментацией
conn corp-roadwarrior
    keyexchange=ikev2
    ike=aes256gcm16-prfsha384-ecp384!
    esp=aes256gcm16-ecp384!
    ikelifetime=24h
    lifetime=8h
    rekeymargin=3m
    keyingtries=1
    fragmentation=force      # принудительно — без неё DPI режет крупные пакеты
    mobike=yes               # сохранение туннеля при смене IP клиента
    dpdaction=clear
    dpddelay=30s
    auto=add
    left=%any
    leftid=@vpn.company.ru
    leftauth=pubkey
    leftcert=vpnCert.pem
    leftsubnet=192.168.20.0/24,192.168.10.0/24
    right=%any
    rightauth=eap-mschapv2
    rightsendcert=never
    rightsourceip=10.10.10.0/24
    eap_identity=%identity

WireGuard — режут активно

Это печальный пункт. WireGuard на стандартном handshake режется почти на всех мобильных операторах в России. Сигнатура первого пакета — четыре байта 0x01 0x00 0x00 0x00 — попадает в фильтр практически любого современного DPI. У клиента VPN до партнёрского склада на WireGuard работал на офисной оптике, но переставал работать у курьеров с мобильных телефонов. Решений два: либо менять WireGuard на IKEv2, либо оборачивать его в TLS через wstunnel или udp2raw — оба варианта добавляют сложности и потребляют CPU.

Мы выбрали первое — переехали на IKEv2/IPSec, удалили WireGuard полностью. Минус 600 мс на handshake, но плюс надёжность.

OpenVPN UDP / TCP — почти мёртв

OpenVPN на 1194 UDP режется у всех операторов. OpenVPN на TCP/443 с TLS-Crypt живёт чуть дольше, но через 5-10 минут DPI распознаёт паттерн и начинает добавлять задержку, потом дропает. На замерах ни один сценарий не давал стабильного канала больше часа на LTE.

Zerotier и Tailscale — выживают через relay

Эти системы хитрее: при невозможности прямого UDP-соединения они уходят на relay-сервер по TLS/443. Замеры показали 87% успешных подключений на оптике, 64% на LTE. Мы используем Tailscale у небольших клиентов как резервный канал админа.

Что мы сделали для торговой компании 28 РМ

Замена WireGuard на IKEv2/IPSec

Поднял на сервере склада strongSwan 5.9.13 на Debian 12, выпустил клиентские сертификаты через step-ca, на курьерских смартфонах настроил профили через Apple Configurator (iOS) и Strongswan App (Android). Тестовая нагрузка через две недели — стабильно, нет отваливаний.

Правила MSS-clamping и MTU 1380 на роутере

Чтобы 1С-Облако перестало периодически отваливаться, нашёл root cause: пакеты 1С-RDP крупные, MTU на канале от провайдера падает до 1400, фрагментация рвалась на ТСПУ. На MikroTik включил mss-clamping и понизил MTU на pppoe-интерфейсе:

/ip firewall mangle
add chain=forward protocol=tcp tcp-flags=syn action=change-mss \
    new-mss=1340 passthrough=yes \
    out-interface-list=WAN \
    comment="MSS clamping for DPI-friendly path"

/interface pppoe-client
set [find name=pppoe-bilain] mtu=1380 mru=1380

# Дополнительно — отключаем PMTUD для критичных подсетей
/ip firewall raw
add chain=output dst-address=84.201.0.0/16 action=notrack \
    protocol=icmp icmp-options=3:4
    comment="Yandex Cloud — игнорируем PMTUD ICMP"

Резервный SoftEther TLS-туннель

Поскольку у клиента есть критичный 1С-канал, мы добавили резервный туннель на SoftEther через TLS/443 — на случай, если завтра DPI начнёт активнее резать IPSec. Это страховка: клиент платит 600 рублей в месяц за второй облачный VPS, туннель поднимается автоматически если основной IKEv2 более 5 минут не отвечает.

# SoftEther — конфиг сервера, ключевая часть для DPI-устойчивости
[Listeners]
Port_443=enabled
DisableDeadHubServerAutoCheck=true

[Hub.HUB_CORP]
Online=true
SecureNAT.Enabled=false
RadiusOptions.Enabled=false

# TLS-маскировка под обычный HTTPS
[Listeners.Listener_443]
Active=true
Protocol=tcp
TLSAlpnList=h2,http/1.1
HostnameForCertificate=mailcloud.company.ru

Что не нужно делать, даже если очень хочется

За время аудита партнёр клиента несколько раз спрашивал: «А нельзя просто поднять Reality-сервер и пустить туда всех?». Отвечаю развёрнуто, потому что это типичный соблазн.

Reality-маскированные VPN-протоколы (VLESS+Reality, Trojan-Go, Hysteria) живут под российским DPI стабильно — это правда. Но это инструменты обхода, а не корпоративные протоколы. Юридически — серая зона; технически — рассчитаны на единичных пользователей, плохо масштабируются на 28 параллельных туннелей; организационно — каждый клиент-устройство нужно индивидуально настраивать; диагностически — когда сломается, разбирать будет ад.

Корпоративная инфраструктура должна работать на корпоративных протоколах. Если IKEv2 у вашего провайдера режется — это аргумент сменить провайдера, а не уходить в Reality.

Что в итоге, цифры и личные впечатления

Аудит занял три рабочих дня инженера. Стоимость для клиента — 52 000 ₽ за сам аудит, плюс 14 рабочих часов на исправления (28 000 ₽) — итого 80 000 ₽. Замена WireGuard на IKEv2 заняла 6 часов работы, MSS-clamping и MTU — 30 минут, развёртывание SoftEther как резерва — 4 часа. После исправлений за два месяца — ноль жалоб от пользователей на «1С тормозит» и «не подключается VPN».

Главный вывод аудита, который партнёр клиента записал отдельно: в 2026 году выбор сетевых протоколов в корпсети — это не вопрос «что вкуснее технически», а вопрос «что доходит до целевого сервера через провайдера и ТСПУ». Лучшая архитектура — та, которая опирается на TLS 1.3 над 443/TCP и IKEv2/IPSec над 500/4500 UDP с фрагментацией. Всё остальное — повод для аудита.

FAQ: что чаще всего спрашивают клиенты

Что такое DPI и почему он мешает корпоративной сети?

DPI (Deep Packet Inspection) — это технология глубокой инспекции пакетов на уровне провайдера или государственного шлюза (ТСПУ). DPI читает заголовки и неэкранированные части протокола, может замедлять или дропать соединения по сигнатуре. Корпоративной сети это мешает, когда сотрудники не могут подключиться к 1С-Облаку, банк-клиенту через VPN или к видеоконференциям.

Какие протоколы реально живые в 2026 году?

По нашему аудиту: TLS 1.3 на стандартных портах 443 — живёт стабильно. HTTPS с QUIC (HTTP/3) — работает в 80% случаев. IKEv2/IPSec — частично пропускают, в зависимости от провайдера. WireGuard на UDP — режется по характерному handshake. OpenVPN UDP — почти везде блокируется. Reality-маскированные VLESS — живут, но это не корпоративный сценарий.

Что делать, если 1С-Облако начало тормозить?

Сначала исключаем локальную причину: загруженность диска, СУБД, сеть до роутера. Если всё чисто — идём проверять MTU и фрагментацию. DPI часто срезает крупные пакеты при ретрансмите. Понижаем MTU на интерфейсе до 1380, включаем mss-clamping на роутере. В 70% случаев 1С снова летает.

VPN до офисного сервера через мобильный интернет — что выбрать?

Мы у клиентов используем IKEv2/IPSec на 4500 UDP с включённым NAT-T и фрагментацией внутри туннеля. Это самый стабильный для мобильных операторов сценарий — у Билайн, МТС, Мегафон проходит почти всегда. Для удалёнки сотрудников также рассматриваем SoftEther с TLS-маскировкой через 443/TCP, если IPSec режется.

Сколько стоит аудит сетевого периметра у вас?

Полный аудит для офиса до 50 РМ — 3 рабочих дня инженера, 45-60 тысяч рублей. Включает: анализ топологии, замер пропускной способности, тестирование критичных протоколов, отчёт со списком рекомендаций и ориентировочным бюджетом на исправление. По итогам аудита вы решаете, делать ли исправления у нас или у себя.

Итог

Аудит периметра под условиями DPI — это не разовая работа, а скорее регулярный медосмотр. Раз в полгода ситуация меняется: ТСПУ обновляет правила, операторы тюнят оборудование, появляются новые блокировки. У клиентов, где мы держим сопровождение, такой аудит входит в годовой пакет — это страховка от внезапных «у нас ничего не работает» в понедельник утром. Для торговой компании 28 РМ цена вопроса оказалась 80 тысяч единовременно, а спокойствия — на год вперёд.