Короткий ответ

Медленный VPN — это три разные ямы: (1) MTU/MSS, когда мелкий ping быстрый, а копии файлов стопорятся; (2) CPU шлюза без AES-NI/ChaCha, когда top показывает 100% на softirq/openvpn/charon; (3) узкий или перегруженный канал офиса, особенно при full tunnel. Измерьте iperf внутри 10.8.0.0/24 и мимо туннеля, снимите CPU и wg show/SA. Не переключайте шифрование в NULL и не отключайте firewall «для скорости».

WireGuard на современном CPU обычно упирается в канал раньше, чем в крипту. OpenVPN 2.6 в userspace — чаще упирается в одно ядро. IPsec с AES-NI — близко к линии.

Симптомы и как отличить

  • RDP рисуется, копирование 10 МБ через VPN — минуты.
  • ping 10.0.10.10 20–40 ms стабильно, скорость 2 Мбит/с при 100 Мбит WAN.
  • Или ping скачет, скорость «пила» — это уже потери/обрывы, не чистый throughput.

Таблица:

КартинаКуда
Мелкий ping ок, крупные сессии виснутMTU/MSS
Все клиенты медленные, WAN офиса 95%full tunnel
Сессии рвутсяразрывы
Один клиент медленный, остальные нетWi-Fi клиента, его CPU, его MTU

Возможные причины

  1. MTU туннеля слишком большой (фрагментация, чёрные дыры PMTUD).
  2. OpenVPN на TCP (proto tcp) — TCP-over-TCP.
  3. Нет AES-NI, OpenVPN без DCO, слабый маршрутизатор «всё в одном».
  4. WAN офиса меньше суммы full-tunnel клиентов.
  5. QoS/полисеры, чужой backup-job в той же LAN.
  6. Антивирус на клиенте, инспекция TLS на всём трафике VPN.
  7. Высокий RTT (другой континент) без окна TCP — выглядит как «медленный VPN».
  8. Wi-Fi клиента, не шлюз.

Диагностика

1. Базовый замер

На сервере в LAN (или сам шлюз 10.8.0.1):

# iperf3 -s   на 10.0.10.10

С клиента:

ping -c 20 10.0.10.10
iperf3 -c 10.0.10.10 -t 20
iperf3 -c 10.0.10.10 -t 20 -R

Сравните с iperf по той же сети без VPN (если клиент в офисе) или с прямым Speedtest WAN офиса.

2. CPU

На шлюзе:

top -H
mpstat 1 10
grep -m1 aes /proc/cpuinfo
wg show

Windows-шлюз RRAS: Task Manager, ядро, RasMan. Рост CPU пропорционально трафику — крипта/NAT. CPU низкий, скорость низкая — канал или MTU.

3. MTU-скрининг (не ломая PMTUD)

ping -M do -s 1372 10.0.10.10
ping -M do -s 1472 10.0.10.10

Подбор размера — в статье MTU. Здесь достаточно понять, виноват ли MTU.

4. Канал и full tunnel

ip route get 1.1.1.1

Если default через VPN — весь бытовой трафик ест аплинк vpn.example.com. Снимите SNMP/интерфейс WAN.

Get-VpnConnection | Select-Object Name, SplitTunneling
Get-NetAdapterStatistics

Решение

Сценарий A. MTU

Подберите MTU/MSS, clamp на шлюзе. Не отключайте PMTUD глобально. Детали — отдельная статья MTU.

Сценарий B. CPU OpenVPN

Обновите до 2.6 с ovpn-dco где поддерживается, или вынесите VPN на машину с AES-NI. Много сотен Мбит на одном openvpn userspace на слабом Atom не получите. Для новой нагрузки рассмотрите WireGuard на том же хосте (другой порт), не «два OpenVPN в failover ради скорости».

Сценарий C. Канал офиса

Включите split: в туннель только 10.0.10.0/24 и 10.8.0.0/24. Бытовой интернет — локальный WAN клиента. См. split/full статьи.

Сценарий D. TCP OpenVPN

Верните proto udp. TCP оставляйте только если UDP реально блокируют.

Сценарий E. RTT

Для 80+ ms не ждите офисной скорости SMB. Другие протоколы (не копирование кучи мелких файлов), WAN-оптимизация не заменяет физику.

Сценарий F. Windows-клиент

Отключите временно инспекцию на одном ПК для проверки, верните обратно. Сверьте, что SplitTunneling соответствует политике. Драйвер WireGuard vs OpenVPN TAP даёт разный CPU на клиенте.

Стенд: iperf через туннель и мимо него

На хосте 10.0.10.10 поднимите iperf3 -s. С домашнего клиента в VPN:

iperf3 -c 10.0.10.10 -t 15 -P 1
iperf3 -c 10.0.10.10 -t 15 -P 4

Один поток низкий, четыре почти линейно растут — окно TCP и RTT, не CPU шлюза. Все потоки упираются в одну цифру, top на шлюзе показывает 100% одного ядра openvpn — userspace crypto. wg при этом на том же железе часто даст больше; не делайте вывод, пока не сравните на этом хосте.

Снимите iperf3 к тому же серверу, если клиент физически в LAN (без VPN). Если LAN 900 Мбит, VPN 40 Мбит, CPU низкий — MTU/потери или WAN. Если LAN тоже 40 — диск/NIC хоста, не туннель.

ss -ti dst 10.0.10.10
mpstat -P ALL 1 5

Windows-клиент: отключите на минуту инспекцию HTTPS в корпоративном агенте на копии политики, верните. Не «выключить Defender навсегда». Замерьте RDP отдельно от iperf: интерактив страдает от джиттера сильнее, чем от средней скорости.

Как проверить, что проблема устранена

Повторите iperf3 -c 10.0.10.10 до/после. Зафиксируйте RTT ping. CPU шлюза не в 100% на одном ядре при целевой скорости. Пользователь копирует тестовый файл ~100 МБ в разумное для канала время. WAN офиса не упирается, если перешли на split.

wg show
ip route get 10.0.10.10

Если не помогло

  • Скорость гуляет вместе с Wi-Fi RSSI — сначала радио, не VPN.
  • Только SMB медленный, iperf быстрый — очередь диска/антивирус на файловом сервере.
  • Только браузер медленный — DNS/DoH, не throughput туннеля.
  • После часов работы деградация — утечка хендлов, DPD, пересоздание SA; смотрите разрывы и логи.

Профилактика

  • Замер baseline iperf после внедрения, сохранить в заявке.
  • Шлюз с AES-NI/ChaCha, не «старый firewall 50 Мбит».
  • Split по умолчанию, full — по заявке.
  • Мониторинг CPU, WAN, handshake.

FAQ

Почему Speedtest «как дома», а 1С тормозит?

Split: Speedtest не идёт через офис. 1С идёт в 10.0.10.0/24. Меряйте путь до сервера 1С.

WireGuard всегда быстрее OpenVPN?

На том же CPU обычно да, но упрётесь в WAN раньше. Выбор ещё про совместимость, см. WireGuard или IPsec.

Помогает ли QoS DSCP?

Может спасти RDP от слона-копии. Не увеличит сумму канала. Маркируйте в шлюзе осознанно.

Нужно ли выключать шифрование LAN?

Нет. VPN как раз про недоверенную среду. Ускорение — AES-NI и MTU, не NULL.

iperf к 10.8.0.1 быстрый, к 10.0.10.10 медленный

Узкое место после шлюза: LAN, диск, CPU маршрутизации FORWARD, не handshake.