SSH работает, но большие передачи временами зависают. Поставьте диагноз по пробам ниже.
Через site-to-site VPN SSH логинится и мелкие вызовы API проходят, но большие загрузки застревают и падают по таймауту. Поставьте диагноз по пробам ниже; назовите причину и дайте одно исправление.
$ ssh user@10.9.0.5 # подключается, появляется приглашение
$ curl -sS https://10.9.0.5/small.json # 200 OK, мгновенно
$ curl -sS https://10.9.0.5/report.csv # зависает, потом таймаут
$ ping -c1 10.9.0.5 # 0% потерь пакетов
$ ping -M do -s 1472 -c1 10.9.0.5
ping: local error: message too long, mtu=1400В чём причина и как её исправить?
Мелкие запросы проходят, а большие передачи зависают, и ping -M do -s 1472 падает с mtu=1400 — это чёрная дыра PMTU. VPN снизил path MTU до 1400; пакеты с DF отбрасываются, но ICMP fragmentation needed отфильтрован, так что отправитель не узнаёт и застревает. Чиним: разрешить этот ICMP или зажать TCP MSS под PMTU.
- ✗Читать чистый мелкий
pingкак доказательство исправности всего пути - ✗Винить случайную потерю, когда роняются лишь большие пакеты с флагом DF
- ✗Упускать, что отфильтрованный ICMP
fragmentation neededи создаёт чёрную дыру
- →Почему мелкие запросы проходят, а зависают только большие передачи?
- →Как зажатие TCP MSS избавляет от зависимости от прохождения ICMP?
The symptom pattern names the fault: small requests succeed, large transfers hang. That asymmetry is the signature of a PMTU black hole. The ping -M do -s 1472 probe (1472 bytes payload + 28 bytes headers = a 1500-byte frame with Don't-Fragment set) fails locally with mtu=1400 — the VPN's encapsulation overhead has lowered the path MTU to 1400.
Here is the mechanism: a full-size TCP segment on an established connection is 1500 bytes with DF set. On the 1400-byte link it is too big to forward, so the router drops it and should return an ICMP fragmentation needed (type 3, code 4) telling the sender to shrink. If a firewall filters that ICMP, the sender never learns — it keeps resending the same oversized segment, which keeps getting dropped. Small packets fit under 1400 and sail through, so logins and tiny responses work while any large transfer stalls.
Two durable fixes:
# 1) Let PMTUD work: permit the ICMP that carries the smaller MTU.
# (allow ICMPv4 type 3 code 4 / ICMPv6 type 2 through the firewall)
# 2) MSS clamping — the robust fix that does not depend on ICMP arriving.
$ sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
-j TCPMSS --clamp-mss-to-pmtuMSS clamping rewrites the TCP MSS in the SYN so both ends agree to send segments that already fit the path — no oversized packet is ever produced. As a last resort, lower the interface MTU to 1400.
