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

Если у roadwarrior 0.0.0.0/0 / redirect-gateway / SplitTunneling $false, их Netflix ест офисный аплинк vpn.example.com. RDP по LAN 10.0.10.0/24 начинает деградировать не потому, что «VPN плохой», а потому что очередь WAN общая. Переведите бытовой трафик на split, контроль оставьте там, где он нужен: админский full tunnel, прокси только для корпоративных URL, DNS NRPT, журналы подключений. Не режьте VPN целиком и не ставьте «безлимит» на офисный канал в надежде.

Снимите график WAN vs число Connected и ip route get 1.1.1.1 с типичного ноутбука.

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

  • Вечер, все «на удалёнке», канал 100 Мбит в потолке, iperf внутри LAN локально быстрый.
  • С домашнего ПК Speedtest ≈ офисный тариф, не домашний гигабит.
  • После disconnect VPN скорость дома взлетает.

Не путать с MTU одного клиента, CPU шлюза без AES (тогда WAN офиса может быть свободен). Статья медленно.

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

  1. Шаблон клиента с full tunnel «как безопаснее».
  2. OpenVPN push "redirect-gateway def1" для всех.
  3. Windows default «use default gateway on remote network».
  4. Админский профиль размножили пользователям.
  5. Нет QoS: копия ISO и RDP в одной очереди.
  6. Облачные бэкапы ноутбуков через офисный прокси.

Диагностика

На клиенте:

ip route get 1.1.1.1
wg show
Get-VpnConnection | Format-List Name, SplitTunneling
Find-NetRoute -RemoteIPAddress 1.1.1.1

На шлюзе: утилизация eth0 (WAN), conntrack, iftop/nethogs по 10.8.0.0/24. Топ talkers — стриминг, не RDP.

ss -tn | awk '{print $4}' | grep 10.8.0
# счётчики интерфейса
ip -s link show eth0

Сопоставьте время пика с wg show / числом RAS users.

Решение

Сценарий A. Сотрудники на split

Как в split: только 10.0.10.0/24 + 10.8.0.0/24 (+ нужные VLAN). Выдача нового конфига, старый full отозвать.

Windows:

Set-VpnConnection -Name 'Office' -SplitTunneling $true
Add-VpnConnectionRoute -ConnectionName 'Office' -DestinationPrefix '10.0.10.0/24'

OpenVPN: убрать redirect-gateway из server push или перенести его в CCD только админам.

WireGuard: убрать 0.0.0.0/0 из пользовательских пиров.

Сценарий B. Админам нужен полный выход через офис

Отдельный профиль Office-Admin с full tunnel, MFA, журналирование, узкий круг. Не тот же peer, что у продаж.

Сценарий C. Контроль веб без full tunnel

Корпоративный прокси/SWG только для внутренних URL или PAC-файл. Это не «весь интернет в офис». DNS NRPT на contoso.example. Утечки DNS проверяйте отдельно.

Сценарий D. Пока не можете сменить шаблон

QoS: приоритет DSCP для RDP/3389, полисер bulk. Это костыль ёмкости, не замена split. Канал физически конечен.

Сценарий E. NAT и default на шлюзе

После перехода на split можно убрать MASQUERADE 10.8.0.0/24 → WAN для пользователей, оставить FORWARD только к LAN. Админский full — отдельная цепочка NAT.

Стенд: топ talkers и смена шаблона

На шлюзе в час пик:

ss -tn dst :443
nethogs wg0
ip -s link show eth0

Если топ — SNI стриминга с 10.8.0.0/24, это full tunnel, не бэкап 1С. Снимите ip route get 1.1.1.1 с двух типичных ноутбуков: бухгалтерия и админ. Разные ответы — уже два профиля; одинаковый wg0 для 1.1.1.1 — все на full.

Пилот split: 5 человек, сутки, график WAN, жалобы на 1С/почту. Если почта Exchange в LAN 10.0.10.0/24 — должна жить. Если Microsoft 365 и allowlist по IP офиса — после split сломается; тогда не возвращайте 0.0.0.0/0 всем, а сделайте прокси в офисе только для этих FQDN или явные префиксы (они плавают — прокси надёжнее).

Set-VpnConnection -Name 'Office' -SplitTunneling $true
Get-VpnConnection -Name 'Office' | Select-Object SplitTunneling
Find-NetRoute -RemoteIPAddress 1.1.1.1

Админский full оставьте на Office-Admin, MFA, другой пул 10.8.1.0/24, NAT в WAN только с этого пула. Пользовательский MASQUERADE в WAN можно снять, чтобы даже ошибочный 0.0.0.0/0 на клиенте упирался в отсутствие NAT (интернет не пойдёт через офис). Это защита от «вернули AllowedIPs из старого чата».

QoS на время миграции: приоритет TCP 3389/445, не полисер 1 Мбит всем. Полисер без исключения DNS сломает NRPT и заявки размножатся.

Документ ADR: default = split, full = роль. Иначе через квартал снова «как в старой инструкции OpenVPN».

Не забудьте IPv6 full tunnel: клиент может гонять AAAA через офис при «починенном» IPv4 split. Снимите ip -6 route get 2001:4860:4860::8888 до объявления победы над каналом WAN.

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

  • ip route get 1.1.1.1 не через wg0 у пилота.
  • Speedtest пилота ≈ домашний канал.
  • График WAN офиса в «удалённый час» упал.
  • RDP к 10.0.10.10 стабилен.
  • Админский профиль по-прежнему full, если так задумано.
Get-VpnConnection -Name 'Office' | Select-Object SplitTunneling

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

  • WAN всё ещё полный: бэкапы серверов, не VPN, или кто-то остался на старом full.
  • Инвентарь конфигов: уникальные ключи, кто не обновился.
  • Облако 365 гоняют через «forced tunnel» GPO — ищите второй механизм помимо WireGuard.

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

  • Default шаблон = split.
  • Full tunnel — RBAC, не «галка в инструкции 2018 года».
  • Мониторинг WAN + число сессий + top talkers 10.8.0.0/24.
  • Ёмкость канала в проекте VPN до закупки «ещё OpenVPN».

FAQ

Full tunnel же безопаснее?

Он позволяет фильтровать интернет на периметре. Цена — канал и отказ RDP. Компромисс: split + EDR на клиенте + NRPT. Для админов — отдельный контур.

Как не потерять доступ к облаку только из офисного IP?

Если SaaS allowlist по IP офиса, split сломает доступ с дома. Тогда либо full только к префиксам SaaS (если известны), либо allowlist домашних не взлетит — нужен прокси в офисе для этих FQDN, не весь 0.0.0.0/0.

OpenVPN CCD на одного пользователя

Да: push "redirect-gateway def1" только в CCD админа. Остальным не пушить.

Пользователи сами включат full в GUI

Ограничьте права на правку профиля, выдавайте wg-конфиг без 0.0.0.0/0, GPO для RAS.

Нужно ли увеличивать WAN вместо split?

Иногда для офиса да. Для удалёнки YouTube — нет, это чужой трафик на вашем тарифе.