Различное MTU на интерфейсах маршрутизатора

1. С вашего раутера это ICMP-сообщение точно уходит? Не рубится на выходе твоими фильтрами?

2. Если уверен, что не рубится - пиши клиенту что он сам мудак

3. Если клиент важный - то прежде чем обзывать его поиграйся с default ttl, чтобы выяснить, какая зараза рубит ваши frag-need: напиши простенькую программу, которая формирует frag-need и отсылает его с небольшим TTL, постепенно его наращивая [можешь посмотреть исходники пинга, надо делать что-то подобное]. Как только ты перестаешь получать TTL expired, это значит что ты с вероятностью процентов в 90 напоролся на раутер, управляемый криворуким виндузятником. Далее связываешься с админом предыдущего в цепочке хоста, чтобы он дал тебе адрес ублюдка, и разбираешься с ним :-) Иное дело, что ты можешь напороться на state-full файрвол, но тогда именно он наверняка и будет источником проблемы.

4. Если пакеты таки доходят до клиента, то он не имеет права их игнорировать, и тогда все-же он мудак, поскольку криво настроил свой файрвол :-)

ICMP-сообщение уходит и моими фильтрами не рубится.

По поводу мудаковатости... Проблема в том, что интерфейс с бОльшим MTU смотрит в сторону провайдера, а с меньшим - в мою. И именно до меня не могут нормально проходить большие пакеты с некоторых, достаточно известных серверов, к примеру yandex.ru, mail.ru, может быть еще есть какие. При работы с ними я фиксирую отправку с моего маршрутизатора ICMP-сообщения на эти хосты, но похоже они на это не реагируют. Если я просто увеличиваю MTU на своем интерфейсе до размеров MTU на внешнем интерфейсе - проблемы решаются. Но увеличить я могу не везде - на ряде интерфейсов есть специфичные ограничения.

Ваш совет по определению хоста, фильтрующего пакеты frag-need, наверное жизнеспособен, но крайне не хотелось бы повторять эту процедуру для организации доступа к каждому "закрытому" сайту, найденному дотошными пользователями. Хотелось бы найти какое то универсальное решение...

Дык приходит тсп-пакет больше МТУ внутреннего, меньше МТУ внешнего.
И сидит в этом пакете маленький такой битик: DF. Что в переводе
означает: доунт фрагмент. И все -- ж#па, в кернеле прямо так и
написано: "дроп этот пакет нафиг". Как лечить -- фиг знает.
Я спасался внешними проксями. Кстати,
$ telnet www.bad-site.com 80
GET / HTTP/1.0<CR><CR>
с клиента отрабатывал нормально, а ИЕ впадал в нирвану.

> Как лечить -- фиг знает.
А снять его ничем нельзя ?

В последнем patch-o-matic нашел такое, но не знаю, оно это или не оно :-)
This option adds CONFIG_IP_NF_TARGET_IPV4OPTSSTRIP, which supplies a target module that will allow you to strip all the IP options from a packet.

The target doesn't take any option, and therefore is extremly easy to use :

# iptables -t mangle -A PREROUTING -j IPV4OPTSSTRIP

В процессе поиска наткнулся на это: http://www.cisco.com/warp/public/105/56.html Как минимум там описаны варианты борьбы. Пойду пробовать...

Спасибо всем откликнувшимся. Помогло следующее правило на маршрутизаторе:

iptables --insert FORWARD --proto tcp --tcp-flags SYN,RST SYN --jump TCPMSS --set-mss 1200