Проблема ICMP unreachable - need to frag

[Sanito 129]

Всем привет.

 

Сегодня появилась одна очень непонятная проблема. Резко вырос трафик на одном чистом web-сервере (nginx+apache).

Обычно было не более 4-5 мегабит перманентно (там баннерка OpenX), а тут вдруг резкие пики:

 

 

Поймал пик, глянул trafshow на какой хост и вот что сказал мне tcpdump:

 

18:53:13.660718 IP MY_IP.80 > UNKNOWN_IP.2378: Flags [.], ack 1, win 65535, length 1460

18:53:13.661959 IP UNKNOWN_IP > MY_IP: ICMP UNKNOWN_IP unreachable - need to frag (mtu 1396), length 48

18:53:13.661965 IP MY_IP.80 > UNKNOWN_IP.2378: Flags [.], ack 1, win 65535, length 1460

18:53:13.663454 IP UNKNOWN_IP > MY_IP: ICMP UNKNOWN_IP unreachable - need to frag (mtu 1396), length 48

18:53:13.663459 IP MY_IP.80 > UNKNOWN_IP.2378: Flags [.], ack 1, win 65535, length 1460

18:53:13.664705 IP UNKNOWN_IP > MY_IP: ICMP UNKNOWN_IP unreachable - need to frag (mtu 1396), length 48

18:53:13.664715 IP MY_IP.80 > UNKNOWN_IP.2378: Flags [.], ack 1, win 65535, length 1460

18:53:13.666079 IP UNKNOWN_IP > MY_IP: ICMP UNKNOWN_IP unreachable - need to frag (mtu 1396), length 48

18:53:13.666086 IP MY_IP.80 > UNKNOWN_IP.2378: Flags [.], ack 1, win 65535, length 1460

18:53:13.667324 IP UNKNOWN_IP > MY_IP: ICMP UNKNOWN_IP unreachable - need to frag (mtu 1396), length 48

18:53:13.667331 IP MY_IP.80 > UNKNOWN_IP.2378: Flags [.], ack 1, win 65535, length 1460

18:53:13.668574 IP UNKNOWN_IP > MY_IP: ICMP UNKNOWN_IP unreachable - need to frag (mtu 1396), length 48

18:53:13.668586 IP MY_IP.80 > UNKNOWN_IP.2378: Flags [.], ack 1, win 65535, length 1460

 

Трафик при этом был порядка 15 мегабит с 80-го порта, лог nginx-а при на этот хост ничего нетривиального не содержит, так, пару php, пяток картинок и всё.

 

Система FreeBSD 8.0-RELEASE.

 

Вопрос - почему _вдруг_ требуется фрагментация для icmp?

Никто не сталкивался?

[muff 115]

Сталкивался.

 

Клиент, который к тебе коннектится - работает через ВПН-подключение. Размер MTU в таком случае 1396 (а не 1500 как при езернет-включении). Далее, при установке TCP-сесии они обмениваются своими MMS (Maximum Message Size - максимальный размер сообщения) - этот момент в выводе tcpdump уже упущен. Соответственно дальше сессия должна работать с пакетами, размером равным меньшему MSS. Но вот твой сервер почему-то не уменьшил размер пакетов, и продолжил отправку сообщений размером 1460 байт. Эти пакеты не "пролазят" в ВПН-тунель (данные не могут корректно инкапсулироваться). Твой сервер не получает АСК и начинает повторно отправлять пакеты, надеясь что они дойдут до адресата.

 

Решение проблемы: похоже твой сервер игнорирует пакеты ICMP типа 4 (код 4 — Необходима фрагментация, но установлен флаг ее запрета). Или еще какая-то бяка.

Еще вариант - коряво настроенный ВПН-сервер, через который ломится клиент.

[Sanito 129]

Увы, проблема в том, что проблема появилась буквально позавчера.

IP с которыми проблема, всё время разные.

До этого больше месяца всё было в порядке.

Что делать, грешить на ДЦ, где сервер?? На чей-то vpn? На "шелезяку"?

Как думаете?

[japh 0]

Увы, проблема в том, что проблема появилась буквально позавчера.

IP с которыми проблема, всё время разные.

До этого больше месяца всё было в порядке.

Что делать, грешить на ДЦ, где сервер?? На чей-то vpn? На "шелезяку"?

Как думаете?

чем все закончилось? та же проблема имеется...

[roger 12]

http://www.speedguide.net/downloads.php - вот тут качаем TCP/IP Optimizer. Там есть закладочка "Определить MTU" и начинаете пускать трасы до посинения, и смотреть мту по всей трасе.

 

 

Большинство провайдеров просто ложат БОЛТ на это понятие и надеются, что оно _само_ будет работать. В результате появляются хопы в которых свичи имеют меньшее мту ( это вообще жесть ), и есть хопы в которых роутеры между собой имеют меньшее мту ( тонели и всякое похожее ) . Так вот тспдамп в принципе ругается именно на МТУ ( типа говорит что установлен бит не фрагментировать а пакет не пролазит в канал).

 

Попробуйте принудительно снимать этот бит =) ( в полиси роутинге = Iptables/ipfw точно такое есть).

[japh 0]

Попробуйте принудительно снимать этот бит =) ( в полиси роутинге = Iptables/ipfw точно такое есть).

 

видимо так и придется. хотя накладно это, файервол держать на загруженной машине... ну там потянет. вообще странное дело - при выключенном PMTU - DF выставляться не должен =\\

[roger 12]

Ещё варинат - мту на карточке поставить 1400 и нет проблем.

[japh 0]

Ещё варинат - мту на карточке поставить 1400 и нет проблем.

не выход. есть подозрение, что это хитрый такой DDoS, при помощи особенностей TCP. рассказывать долго, еще будет играть с IDS и анализировать трафик, но пока - выглядит именно так.

сейчас просто отрубил PMTU