Аудит сетевого периметра при 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.

Прежде чем приступить к аудиту, я откровенно поговорил с партнёром клиента. Я ему так и сказал: «Послушайте, ещё недавно мы строили сети, ориентируясь на наши собственные потребности. А теперь что? Приходится плясать от того, что вообще пропустит провайдер. Конечно, это неприятно, но это новая реальность». Он сначала сопротивлялся: «Да как так? У нас же Cisco VPN, он просто ОБЯЗАН работать!» Но знаете, что? Уже через пару часов замеров он принёс мне кофе, посмотрел на меня с пониманием и произнёс: «Ладно, делайте, как нужно. Я верю».

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

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

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

Всегда начинаю с инвентаризации того, что уже есть у клиента. Мы скрупулёзно фиксируем каждую модель и прошивку роутеров, досконально разбираем маршруты, таблицу NAT, состав VLAN’ов, выясняем, какие сервисы где «поселились» и кто куда вообще обращается. У той самой торговой компании, о которой мы говорили, картина выглядела вот так: пограничный MikroTik RB5009 с RouterOS 7.13; две WAN — основная на оптике Билайна (200/200) и LTE Мегафона для резерва; четыре VLAN’а: десятый для офиса, двадцатый для серверов, тридцатый — гостевой, и сороковой для 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 мс, а на LTE Мегафона поднимался до 35 мс. В общем, все банк-клиенты, КонсультантПлюс, да и Я.360 — всё это работает абсолютно штатно, без каких-либо неприятных сюрпризов.

Но здесь есть один важнейший нюанс, который нельзя забывать. ТСПУ запросто читает SNI, да ещё и прямо в TLS ClientHello! И что происходит, если этот SNI вдруг попадает в какой-то их «чёрный список»? Увы, соединение просто обрывается. У нашего клиента с абсолютно легитимными доменами банков и 1С, к счастью, такого никогда не случалось. Но мы всё равно решили протестировать этот момент, просто чтобы полностью понимать картину. Результат? Запросы к sci-hub.se, telegram.org, instagram.com «рвутся» буквально через 2-3 секунды после того, как произошло рукопожатие. Логика работы DPI тут такая: сначала он пропускает начало handshake, затем смотрит 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 для всех без исключения рабочих станций. Почему? Всё просто: браузер сначала пытается подключиться по QUIC, не получает ответа, потом переключается на 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. Правда, оба эти решения добавляют приличную долю сложности и, к сожалению, заметно нагружают процессор.

Знаете, мы в итоге остановились на первом варианте: полностью перешли на 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, выпустил все нужные клиентские сертификаты. А на курьерских смартфонах настроил профили: для iOS через Apple Configurator, для Android — через Strongswan App. Две недели тестовой нагрузки прошли, и что я могу сказать? Работает как часы, никаких «отваливаний»! Красота!

Правила 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 перестаёт отвечать дольше пяти минут. Спокойствие того стоит, правда?

# 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 заняла всего полчаса, а развёртывание 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 тысяч рублей. Да, единовременно. Зато они год живут спокойно.