Со значением MTU по умолчанию, как показано ниже:
hosta$ ifconfig eth0 | grep mtu
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
Я могу пинговать с другого сервера, используя полезную нагрузку 1500
hostb$ ping -s 1500 -c 2 hosta
PING hosta (hosta) 1500(1528) bytes of data.
1508 bytes from hosta: icmp_seq=1 ttl=64 time=0.273 ms
1508 bytes from hosta: icmp_seq=2 ttl=64 time=0.314 ms
--- статистика пинга хоста ---
2 packets transmitted, 2 received, 0% packet loss, time 1025ms
rtt min/avg/max/mdev = 0.273/0.293/0.314/0.020 ms
tcpdump на хосте все хорошо
12:01:40.237047 IP hostb > hosta: ICMP echo request, id 3052, seq 1, length 1480
12:01:40.237048 IP hostb > hosta: icmp
12:01:40.237116 IP hosta > hostb: ICMP echo reply, id 3052, seq 1, length 1480
Я могу снизить MTU на хосте до 1488, и пинг полезной нагрузки в 1500 работает.
Магическое число — MTU=1487.
hosta $ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1487
<snip>
Когда я отправляю пинг размером 1500 байт (не вмешиваясь в флаг фрагментации), ответа нет.
hosb $ ping -s 1500 -c 2 hosta
PING hosta (hosta) 1500(1528) bytes of data.
--- hosta ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1032ms
tcpdump на хосте выглядит так:
12:01:07.421196 IP hostb > hosta: icmp
12:01:08.443698 IP hostb > hosta: icmp
хоста показывает
net.ipv4.ip_forward_use_pmtu = 0
net.ipv4.ip_no_pmtu_disc = 0
net.ipv4.route.min_pmtu = 552
net.ipv4.route.mtu_expires = 600
net.ipv4.tcp_mtu_probe_floor = 48
net.ipv4.tcp_mtu_probing = 0
net.ipv4.icmp_echo_ignore_all = 0
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.icmp_errors_use_inbound_ifaddr = 0
net.ipv4.icmp_ignore_bogus_error_responses = 1
net.ipv4.icmp_msgs_burst = 50
net.ipv4.icmp_msgs_per_sec = 1000
net.ipv4.icmp_ratelimit = 1000
net.ipv4.icmp_ratemask = 6168
Обратите внимание, что я заменил IP-адрес правильным именем хоста, если вывод выглядит немного странно.
Я измотался, пытаясь понять, почему понижение MTU до любого числа ниже определенного порога приводит к тому, что ping не получает никаких ответов. Несмотря на то, что я не вмешивался в фрагментацию.
Если я использую опцию -M для пакета размером 1500 байт, я получаю ответ до тех пор, пока MTU хоста не станет выше 1488, но как только он станет равным 1487 или ниже, все do/want/dont не получат ответа.
Продолжим немного подробнее. При MTU=1487 tcpdump на этом хосте (=10.50.107.129) показывает этот входящий 1 IP-пакет
1 2023-02-15 22:40:24.095129 10.50.107.83 10.50.107.129 IPv4 562 Fragmented IP protocol (proto=ICMP 1, off=1480, ID=1fb9)
Это единственная строка. Говорит, что она фрагментирована, но показывает длину 562 байта, что соответствует длине, показанной ниже в #3 ниже.
Далее я меняю MTU=1500, и вижу, что полезная нагрузка фрагментирована и подтверждена, как показано ниже.
2 2023-02-15 22:40:42.093639 10.50.107.83 10.50.107.129 IPv4 1514 Fragmented IP protocol (proto=ICMP 1, off=0, ID=2c62) [Reassembled in #3]
3 2023-02-15 22:40:42.093639 10.50.107.83 10.50.107.129 ICMP 562 Echo (ping) request id=0x1004, seq=1/256, ttl=64 (reply in 5)
4 2023-02-15 22:40:42.093698 10.50.107.129 10.50.107.83 IPv4 1514 Fragmented IP protocol (proto=ICMP 1, off=0, ID=fe1a) [Reassembled in #5]
5 2023-02-15 22:40:42.093717 10.50.107.129 10.50.107.83 ICMP 562 Echo (ping) reply id=0x1004, seq=1/256, ttl=64 (request in 3)
Я проверил данные в #1 и сравнил с данными в #4, они не +/- 3 байта (ping вставляет шестнадцатеричные 00 в ff в качестве полезной нагрузки). Так что либо отправитель не отправил первый фрагмент, либо получатель не прочитал первый фрагмент, либо происходит что-то еще.
Оба сервера построены идентично, как и виртуальные машины, работающие под управлением Ubuntu. Поэтому устранили одну сторону .
Если я запущу ping со своего ноутбука через VPN/брандмауэр и т. д., я смогу пинговать хост с MTU=1487.
Я в замешательстве и буду признателен, если кто-то что-то подскажет.