Я наблюдаю странную проблему с проводным подключением к маршрутизатору в локальной сети, когда TCP-трафик отбрасывается и регистрируется как фрагментированный пакет.
В сценарии установлено значение MTU 1500 на сетевых клиентах и на сетевом адаптере маршрутизатора (согласно IP-адрес показать).
Пример сообщения о потерянном пакете (разбит на несколько строк для удобочитаемости):
12 мая 09:44:05 ядро: DROP IN=eth0 OUT=tun11 MAC=<удалено>
SRC=<IP-адрес рабочего стола> DST=<внешний IP-адрес назначения>
LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=54356 DF PROTO=TCP SPT=53370 DPT=443 SEQ=3216568911 ACK=0
WINDOW=64240 RES=0x00 SYN URGP=0 OPT (020405B40402080A002E76880000000001030307) MARK=0x8000000
Из небольшого чтения по TCP/IP я вижу, что opt 0204 относится к MSS и размер, кажется, 1460, хотя я изо всех сил пытаюсь понять, к чему относятся оставшиеся байты (0402 080А 002Е 7688 0000 0000 0103 0307). Я не вижу правил брандмауэра на маршрутизаторе, который вообще применяет метку, но у меня есть ограниченные подробные сведения о сетевом фильтре.
Когда я пытаюсь вычислить максимальный размер MTU через ping -M do <IP-адрес маршрутизатора> -c 2 -s 1500 ответ клиента локальная ошибка: сообщение слишком длинное, mtu=1500 или когда пинг cmd использует меньший размер MTU для тестирования, отсутствие ответа / все неудачные пакеты.
В первом я уменьшаю MTU на 28, а затем получаю второй сценарий. Я предполагаю, что это означает, что MTU подходит, но пакет все еще отбрасывается. Пример записи в журнале маршрутизатора об этом удалении:
12 мая 13:01:01 ядро: DROP IN=eth0 OUT= MAC=<удалено>
SRC=<IP-адрес рабочего стола> DST=<IP-адрес маршрутизатора>
LEN=1378 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF
PROTO=ICMP TYPE=8 CODE=0 ID=5 SEQ=1 MARK=0x8000000
Когда я определяю более подходящий MTU, используя пинг проверьте и перезагрузите рабочий стол, пакеты продолжают фрагментироваться и пинг Затем test возвращает меньшее значение MTU (на 28 байт каждый раз меньше).
Рабочий стол работает Кубунту 20.04.4.
После некоторого значительного времени, пытаясь понять больше об этом сценарии, я попытался добавить следуя правилам iptables на роутере:
-A ВВОД -m conntrack --ctstate СВЯЗАННО, УСТАНОВЛЕНО -j ПРИНЯТЬ
-A FORWARD -m conntrack --ctstate DNAT -j ПРИНЯТЬ
Но это не решило проблему.
Это делает нет происходит на устройствах Android, подключенных к тому же маршрутизатору через WiFi. Маршрутизатор перезапускается на ночь по расписанию, и Xbox сталкиваются с одним и тем же сценарием фрагментации/отбрасывания пакетов до тех пор, пока они не будут перезапущены хотя бы один раз. Один XBox подключается через Wi-Fi, другой подключается к маршрутизатору, подключенному к проблемному маршрутизатору.
Трафик между WiFi-маршрутизатором и граничным маршрутизатором, по-видимому, не пострадал — никаких признаков потери пакетов из-за фрагментации на этом уровне.
Обходной путь
Я обнаружил, что запуск трассировка от бить на рабочем столе как-то устраняет проблему
До и после этого «исправления» адаптер локальной сети для настольных ПК указан с одним и тем же MTU, тогда как если бы MTU нужно было настроить, я бы ожидал, что это значение будет изменено (и я мог бы установить его по умолчанию):
eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
Однако я не понимаю Почему в трассировка видимо решает проблему. Любые предложения будут с благодарностью получены в этот момент.
