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

Если ICMP 32–64 байт до 10.0.10.10 жив, а TLS/RDP/SMB «виснут», почти всегда MTU туннеля и чёрная дыра PMTUD: большие пакеты с DF не проходят, ICMP too big режется. Подберите MTU интерфейса (wg0/tun0/IPsec) и clamp MSS на шлюзе. Не отключайте PMTUD и не снимайте DF глобально «чтобы заработало»: сломаете нормальный path MTU в LAN 10.0.10.0/24.

Ориентиры (не догма): Ethernet 1500, WireGuard часто 1420, IPsec ESP ещё меньше, OpenVPN зависит от tun-mtu/mssfix. Точный размер меряется ping с DF.

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

  • ping -c 3 10.0.10.10 ок, curl https://intranet.contoso.example висит.
  • RDP сессия есть, при перетаскивании окна — чёрные квадраты / disconnect.
  • SSH команды проходят, scp большого файла нет.
  • tcpdump видит повторные TCP без ACK после определённого размера.

Не это:

  • Всё медленное, но доходит — медленно (CPU/канал).
  • Сессия падает по таймеру без крупных пакетов — разрывы.
  • Нет даже мелкого ping — маршруты/handshake, не MTU.

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

  1. MTU VPN-интерфейса 1500 при overhead UDP+крипта — фрагментация/дроп.
  2. Промежуточный PPPoE 1492, VPN сверху — ещё теснее.
  3. ICMP type 3 code 4 режется файрволом — PMTUD не работает.
  4. OpenVPN без mssfix / слишком большой tun-mtu.
  5. Windows NIC VM с Jumbo 9000 vs туннель 1420 без clamp.
  6. IPsec NAT-T UDP encapsulation съедает лишние байты относительно «голого» ESP.

Диагностика

1. DF ping

Linux к хосту LAN:

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

Найдите максимальный s, который отвечает. IP+ICMP overhead 28 байт на IPv4: MTU ≈ s+28 для ping-теста до целевого хоста (это MTU пути, не обязательно MTU wg0).

Windows:

ping -f -l 1372 10.0.10.10
ping -f -l 1200 10.0.10.10

2. MTU интерфейсов

ip link show wg0
ip link show tun0
ip route get 10.0.10.10
Get-NetIPInterface -AddressFamily IPv4 | Format-Table ifIndex, InterfaceAlias, NlMtu
Get-VpnConnection

3. Режется ли too big

На шлюзе:

tcpdump -n icmp

Во время неудачного большого ping должны мелькать fragmentation needed. Тишина при дропе больших пакетов — фильтр ICMP или чёрная дыра дальше.

Решение

Сценарий A. WireGuard

Задайте MTU в конфиге клиента и сервера одинаково разумно (часто 1420, на PPPoE ниже):

[Interface]
MTU = 1420
Address = 10.8.0.10/24

Переподнимите wg-quick. Повторите DF ping. Если 1372 проходит, 1420 на интерфейсе согласован — проверьте ещё MSS для TCP.

Сценарий B. Clamp MSS на шлюзе

Фиксированный clamp безопаснее слепого отключения PMTUD. Пример (MSS подберите: типично 1360–1380 для WG/IPsec, не копируйте число без замера):

iptables -t mangle -A FORWARD -i wg0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360
iptables -t mangle -A FORWARD -o wg0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1360

nftables: tcp flags syn / syn,rst tcp option maxseg size set 1360 на форварде в/из wg0. Сохраните правила штатно. Слишком маленький MSS режет скорость — не ставьте 512 «на всякий».

Сценарий C. OpenVPN 2.6

tun-mtu 1420
mssfix 1360

Либо fragment только если понимаете CPU на фрагментации. Предпочтительнее корректный MTU + mssfix, не фрагментировать всё.

Сценарий D. IPsec

Учитывайте ESP+NAT-T. Часто clamp на FORWARD между LAN и ipsec0/xfrm. Не поднимайте MTU LAN выше, чем туннель «прожуёт».

Сценарий E. Разрешить ICMP too big

На файрволе разрешите ICMP fragmentation needed между VPN и LAN, не весь ICMP с WAN. PMTUD должен жить.

Стенд: DF ping матрица и один TCP-поток

Составьте таблицу size 1200, 1300, 1372, 1400, 1472 с ping -M do / ping -f -l до 10.0.10.10 и до 10.8.0.1. Если до туннельного IP большой ping проходит, до LAN — нет, overhead на FORWARD/другом hop (PPPoE офиса, VLAN). Clamp на wg0 тогда недостаточен: нужен clamp на пути LAN или ниже MTU.

tracepath 10.0.10.10
ip -d link show wg0

tracepath показывает pmtu, если ICMP too big жив. Если пишет «pmtu 1500» при живом VPN — PMTUD не видит туннель, клиент будет слать слишком крупные кадры в wg0. Снизьте MTU интерфейса явно.

Проверка TCP: curl -o /dev/null http://10.0.10.10/1mb.bin или копирование файла. Параллельно tcpdump -n -i wg0 'tcp[13] & 2 != 0' на SYN — смотрите MSS в опциях. После clamp SYN должен нести уменьшенный MSS. Если MSS в SYN всё ещё 1460 — правило mangle не бьёт этот интерфейс/направление.

Не включайте jumbo на vSwitch гипервизора «для VM с VPN»: внутренняя VM начнёт слать 9000 в туннель 1420.

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

ping -M do -s 1372 10.0.10.10
curl -sI https://intranet.contoso.example | head -n 5
Test-NetConnection 10.0.10.10 -Port 3389
# скопировать файл >1 МБ по SMB/RDP clipboard

HTTPS открывается, RDP не рвётся на перерисовке, iperf не «пилит» нулями. tcpdump без бесконечных ретрансмитов.

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

  • Только одно приложение — его собственный UDP/MTU (VoIP), не системный TCP MSS.
  • Jumbo в LAN и туннель 1420: clamp обязателен, иначе сервер шлёт 9000.
  • После clamp стало медленнее, но стабильно — уменьшили MSS слишком сильно; поднимите шаг 40 байт.
  • Пропадает интернет целиком — не MTU, default route.

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

  • В шаблоне WG/OpenVPN сразу MTU < 1500.
  • Не включать Jumbo на VPN-шлюзе «для красоты».
  • Разрешённый path для ICMP too big на внутренней политике.
  • Замер DF ping в чеклисте ввода VPN.

FAQ

Почему ping работает, а сайт нет?

Ping по умолчанию маленький. Сайт — полноразмерные TCP сегменты.

Нужно ли MTU 1280 «навсегда»?

Это IPv6 минимум, для IPv4 VPN часто избыточно низко. Подберите по DF ping.

Clamp vs уменьшение MTU интерфейса

Оба. MTU режет IP, clamp помогает TCP, который иначе упирается, если PMTUD сломан. UDP (WireGuard payload уже внутри) выигрывает от MTU интерфейса.

Можно ли включить fragmentation everywhere?

OpenVPN fragment грузит CPU и лечит симптом. Сначала MTU/MSS.

Windows NlMtu 1400, Linux 1420 — плохо?

Да, рассинхрон. Выровняйте или clamp на меньшем.