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

Классика: ping 10.0.10.1 жив, HTTPS/RDP/SMB нет или «залипает». Мелкий ICMP проходит, пакеты с DF близкие к 1500 — нет. Это MTU/PMTUD, не «прокси». Подтвердите пингом с DF, найдите максимальный payload, выставьте MTU/MSS на проблемном участке (часто VPN/PPPoE/GRE), не режьте 1500 на всех серверах LAN.

Не отключайте ICMP «на файрволе навсегда»: вы как раз убиваете PMTUD.

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

  • ping -n 2 1.1.1.1 OK, Test-NetConnection -Port 443 зависает;
  • почта/мессенджеры с короткими пакетами живы, открытие папки SMB нет;
  • после VPN «интернет есть» (DNS/ICMP), сайты нет.

Отличия от пинг идёт, сайт нет: там часто закрыт 443 при любом размере. Здесь размер пакета — ключ. Потери всех размеров — loss, не MTU.

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

  1. VPN/IPsec/GRE без учёта overhead, LAN MTU 1500, туннель требует 1400.
  2. PPPoE 1492, клиент 1500.
  3. Jumbo 9000 на сервере, 1500 на ПК.
  4. ICMP type 3 code 4 фильтруется — PMTUD чёрная дыра.
  5. Кламп MSS на NAT не совпадает с реальным путём.
  6. Wi‑Fi/USB-док с другим MTU.
  7. VXLAN/overlay в гипервизоре.

Диагностика

Ethernet IPv4: MTU 1500 ⇒ ICMP payload для DF-теста 1472 (20 IP + 8 ICMP). На Windows ping -l — размер данных.

1. DF-пинг по лестнице

До шлюза и до проблемной цели:

ping -n 2 -f -l 1472 10.0.10.1
ping -n 2 -f -l 1472 10.0.10.2
ping -n 2 -f -l 1400 1.1.1.1
ping -n 2 -f -l 1372 1.1.1.1
ping -n 2 -f -l 1200 1.1.1.1
ping -c 2 -M do -s 1472 10.0.10.1
ping -c 2 -M do -s 1472 1.1.1.1
ping -c 2 -M do -s 1372 1.1.1.1

Windows: «Packet needs to be fragmented but DF set» — этот размер не проходит. Уменьшайте l, пока не пойдёт. Ubuntu: Frag needed / 100% loss при -M do.

Если 1472 до 10.0.10.1 падает — проблема уже в LAN (jumbo mismatch). Если LAN OK, до интернета 1472 нет — WAN/VPN.

2. TCP MSS

Test-NetConnection example.com -Port 443
# параллельно на Ubuntu-шлюзе:
# sudo tcpdump -n -i eth0 'tcp[tcpflags] & tcp-syn != 0'
ss -ti
# mss, pmtu
ip route get 1.1.1.1

ip route get на Linux показывает mtu/advmss для пути.

3. Где чёрная дыра

Если большой ping просто timeout (нет ICMP frag needed) — фильтр ICMP. Тогда PMTUD не работает: TCP шлёт 1500, тишина. Решение: MSS clamp или снизить MTU на туннеле, плюс разрешить ICMP unreachable на пути хотя бы между своими шлюзами.

4. Сравнить интерфейсы

Get-NetIPInterface -AddressFamily IPv4 | Format-Table InterfaceAlias, NlMtu, ConnectionState
netsh interface ipv4 show subinterfaces
ip -d link show
nmcli connection show

VPN-адаптер 1400, Ethernet 1500 — нормально. Ethernet 9000 при свитче 1500 — поломка.

Решение

Сценарий A. VPN

Выставьте MTU туннеля так, чтобы DF 1372–1400 (пример, измерьте свой максимум) проходил. На Ubuntu WireGuard часто mtu 1420 (зависит от overhead). Не копируйте число с чужого блога — измерьте.

Сценарий B. LAN jumbo

Либо везде 9000 (свитч, NIC, VM), либо везде 1500. Смешение = эта статья. Откат jumbo безопаснее, чем «дожать» всю ферму за час.

Windows:

Set-NetAdapterAdvancedProperty -Name 'Ethernet' -DisplayName 'Jumbo Packet' -DisplayValue '1514'

Имена свойств зависят от драйвера — смотрите Get-NetAdapterAdvancedProperty. Ubuntu netplan: не задавайте mtu: 9000 точечно на одном хосте.

Сценарий C. MSS clamp на NAT-шлюзе Ubuntu

Если нельзя починить ICMP:

sudo nft add rule inet nat postrouting tcp flags syn tcp option maxseg size set 1360

Значение из вашего замера, не 1360 «магией». Это костыль; предпочтительнее MTU на туннеле + ICMP.

Сценарий D. PPPoE

MTU 1492 (или меньше) на WAN. Клиентам LAN можно оставить 1500, если clamp/PMTUD работают.

5. Практическая лестница размеров и где её остановить

Не подбирайте MTU «с потолка 1400». На проблемном пути (часто VPN, не LAN до 10.0.10.1) пройдите DF-лестницу: 1472 → 1452 → 1400 → 1372 → 1300. Первый прошедший payload + 28 даёт рабочий IPv4 MTU. Для туннеля возьмите чуть меньше (запас на options). Проверьте HTTPS файлом >1 МБ: мелкий GET мог пройти и при чёрной дыре PMTUD.

На Windows netsh interface ipv4 show subinterfaces после изменения: не забудьте, что VPN-адаптер и Ethernet — разные MTU, это нормально. Ломать 1500 на всех серверах 10.0.10.0/24 из-за одного филиального туннеля — типичный вред. ICMP type 3 code 4 должен доходить хотя бы между шлюзами; если корпоративный фильтр «deny icmp any» стоит на WAN, PMTUD умрёт у всех, не у одного сайта. Тогда MSS clamp — осознанный костыль с числом из замера, не из блога. IPv6 проверяйте отдельно: там свой MTU и отдельные RA.

Повторите тест с клиентского Wi‑Fi и кабеля: док-станция иногда ставит другой MTU. После смены туннеля сохраните команду замера в runbook, иначе через квартал снова «пинг есть, RDP нет».

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

ping -n 2 -f -l 1472 10.0.10.1
ping -n 2 -f -l 1372 1.1.1.1
Test-NetConnection example.com -Port 443
ping -c 2 -M do -s 1472 10.0.10.1
curl -I https://example.com/

Рабочий сценарий: HTTPS, RDP, SMB-копирование файла >10 МБ (мелкий HTTP мог проходить и до фикса). Повторите через VPN.

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

  • Только один сайт — его путь/CDN другой MTU; всё равно ваш clamp должен покрывать минимум.
  • IPv6 отдельный MTU; проверяйте AAAA отдельно.
  • Hairpin NAT плюс MTU — два слоя, чините по очереди.
  • QUIC/UDP не использует TCP MSS: нужен правильный MTU интерфейса.

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

  • Стандарт 1500 в LAN, исключения только на overlay с документированным MTU.
  • Не фильтровать ICMP unreachable между своими маршрутизаторами.
  • После внедрения VPN — обязательный DF-тест.
  • Не включать jumbo «для скорости гигабита» без проекта.

FAQ

Почему ping по умолчанию работает?

Потому что payload маленький. Это не тест MTU.

Какой MTU «безопасный универсальный»?

Нет одного числа. LAN Ethernet — 1500. VPN — измерить. 1400 часто живёт, но это не замена замеру.

Отключить DF на сервере?

Не надо. Сломаете фрагментацию и получите другие глюки. Чините MTU/PMTUD.

Windows -l 1472, Linux -s 1472 — одно и то же?

Да, оба задают ICMP payload. IP+ICMP overhead одинаков. Не путайте с -l без -f.

Нужно ли менять MTU DNS 10.0.10.2?

Только если сами серверы в jumbo-несогласованности. DNS-пакеты обычно мелкие; SRV крупные могут резаться — тогда это DNS+MTU, см. нестабильный DNS.