MTU и обрывы на длинных соединениях

Ловлю обрывы на длинных выгрузках, и картина у них странная. Соединение поднимается мгновенно, короткие запросы летают, статус отдаётся без задержки. Как только ответ переваливает за пару килобайт, всё встаёт колом и минуты через полторы падает по таймауту.

Падает при этом через раз: половина файлов доезжает целиком. Прогон идёт через туннель на арендованном сервере, посредник по сокетной схеме. Думал на посредника, снял дамп, а там ровные повторы одного и того же кадра: отправил, тишина, отправил снова, тишина, обрыв.

Что это за зверь и куда смотреть дальше?

Зверь известный, зовут его чёрной дырой по размеру кадра.

Туннель дописывает свою шапку к каждому пакету, и полезного места внутри остаётся меньше привычных полутора тысяч байт. Узел по дороге обязан крикнуть отправителю, что кадр великоват, и назвать посильный размер. Когда этот крик где-то режут, ваша сторона про уменьшение так и не узнаёт и продолжает слать кадры прежней длины. Мелкие пролезают, крупные упираются в стенку. Отсюда и повторы в дампе.

Меряется всё за минуту: гоняем пробный кадр с запретом дробить и убавляем длину, пока не пройдёт.

а на винде это как померить, там ключа -M нет

На Windows пишется ping -f -l 1472 example.org, буква -f держит тот же запрет дробления. В ответ прилетит строчка про необходимость фрагментации, по ней и ловится потолок.

Чинится в двух местах на выбор. Либо руками опускаете размер на интерфейсе туннеля, либо подрезаете заявку в рукопожатии, и тогда обе стороны сами сойдутся на посильной длине.

sudo ip link set dev tun0 mtu 1400
sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Второй способ мне нравится больше: он работает для всего, что идёт через машину, и не требует угадывать число вручную.

Один в один моя картина. Опустил размер на туннеле до 1400, выгрузки бегут третьи сутки, обрывов ноль. Спасибо обоим.