lan-viper Опубликовано 8 января, 2012 · Жалоба Приветствую. Искал на этом форуме, искал на гугле, там только списки рассылок, в которых сам чёрт ногу сломит. Итак: в kern.log сыпят сообщения от ядра, что мол xt_TCPMSS: bad length (N bytes) где N - число, чаще всего в моём случае за сутки попадает (41 bytes), до 1000 записей в логе. Сообщения ядра начинают появляться соотв. после добавления в iptables след. нужного правила iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu , т.к. сервак является NAS для vpn-щиков. Интересует, откуда ноги растут у данной проблемы, т.с. истинная причина? Есть подозрения на торрент-качальщиков. Видел советы, что надо отключить warn тип сообщений от ядра и тогда логи будут "чистые", но это равносильно закрыть глаза на проблему. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alexaaa Опубликовано 8 января, 2012 (изменено) · Жалоба Приветствую. Искал на этом форуме, искал на гугле, там только списки рассылок, в которых сам чёрт ногу сломит. Итак: в kern.log сыпят сообщения от ядра, что мол xt_TCPMSS: bad length (N bytes) где N - число, чаще всего в моём случае за сутки попадает (41 bytes), до 1000 записей в логе. Сообщения ядра начинают появляться соотв. после добавления в iptables след. нужного правила iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu , т.к. сервак является NAS для vpn-щиков. Интересует, откуда ноги растут у данной проблемы, т.с. истинная причина? Есть подозрения на торрент-качальщиков. Видел советы, что надо отключить warn тип сообщений от ядра и тогда логи будут "чистые", но это равносильно закрыть глаза на проблему. сталкивался с таким, это проблема mtu, для l2tp mtu составляет 1472, для pptp составляет 1460, при форсаже у нас тоже сыпятся такие логи, дело в том что это зависит от шейпера и от полосы пропускания, чем больше полоса пропускания тем больше mtu, вот от этого ругань и идёт, но пока все сервера работают, и особых проблем с этим нет, попробуйте указать iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1460 iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1472 Изменено 8 января, 2012 пользователем alexaaa Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lan-viper Опубликовано 8 января, 2012 (изменено) · Жалоба Спасибо, обязательно поэкспериментирую. Шейпер - встроенный в accel-ppp на tbf. Когда-то было всё на скриптах и htb, тогда этих сообщений кстати небыло. PS В теме про accel-ppp проскакивал точно такой-же вопрос, но я слежу за темой и там этот вопрос остался без ответа xeb-a, возможно шейпер как-то влияет на это. Изменено 8 января, 2012 пользователем lan-viper Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alexaaa Опубликовано 8 января, 2012 (изменено) · Жалоба Спасибо, обязательно поэкспериментирую. Шейпер - встроенный в accel-ppp на tbf. Когда-то было всё на скриптах и htb, тогда этих сообщений кстати небыло. PS В теме про accel-ppp проскакивал точно такой-же вопрос, но я слежу за темой и там этот вопрос остался без ответа xeb-a, возможно шейпер как-то влияет на это. Кстати мы тоже используем accel-ppp только без встроеного шейпера, а на внешних скриптах, вопрос решили так как я вам написал, хотя интересно, какую версию accel-ppp используете, какой биллинг используете и есть ли у вас форсаж, а вообще значение mtu 1460 используется в Mikrotik для любого типа vpn. Изменено 8 января, 2012 пользователем alexaaa Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lan-viper Опубликовано 8 января, 2012 (изменено) · Жалоба какую версию accel-ppp используете, какой биллинг используете и есть ли у вас форсаж1.4.0 release (пока, обычно держу последнюю из git), многострадальный UTM5, а "форсаж" у нас в виде троекратного увеличения скорости с 01:00 до 13:00 опять же средствами accel-ppp. У меня от значения скорости интенсивность появления данных сообщений не зависит.Да, в accel-ppp.conf: [ppp] ... min-mtu=1280 mtu=1400 mru=1400 ... Может это всё как-то привести к общему знаменателю с правилами iptables? Изменено 8 января, 2012 пользователем lan-viper Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alexaaa Опубликовано 8 января, 2012 (изменено) · Жалоба У нас тоже UTM5, версия accel-ppp 1.3.4 настройки дефолтовые [ppp] verbose=1 min-mtu=1000 mtu=1400 mru=1400 ccp=0 шейпер на tс, только добавли в iptables настройки которые я вам писал, как вы делаете настройки встроенного шейпера для форсажа Изменено 8 января, 2012 пользователем alexaaa Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 8 января, 2012 · Жалоба iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu , т.к. сервак является NAS для vpn-щиков. если хотите использовать --clamp-mss-to-pmtu, то вставляйте правило в цепочку POSTROUTING. При прохождении FORWARD система еще не знает через какой интерфейс пакет должен будет уйти, поэтому однозначно определить pmtu не может. либо применяйте --set-mss как это посоветовали выше. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lan-viper Опубликовано 8 января, 2012 (изменено) · Жалоба iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1460 iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1472 IMHO, первое правило переопределяется вторым. И в мане в разделе TCPMSS цитирую This target allows to alter the MSS value of TCP SYN packets, to control the maximum size for that connection (usually limiting it to your outgoing interface's MTU minus 40). Of course, it can only be used in conjunction with -p tcp. It is only valid in the mangle table.Судя по последнему предложению, правило имеет силу только в таблице mangle taf_321, тогда почему разработчики в своём мане приводят следующий пример: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \ -j TCPMSS --clamp-mss-to-pmtu лажанулись? PS Перенос правила iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu в цепочку POSTROUTING не повлиял на появление сообщений, так и валят в лог... Пробую жёстко задавать 1460. PPS Сообщения продолжают появляться по 2-3 в минуту при любых вариантах расположения правила. Пробовал и так и сяк. Без данного правила сообщения не появляются, но появляется матюки от некоторых абонентов. Изменено 8 января, 2012 пользователем lan-viper Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alexaaa Опубликовано 8 января, 2012 (изменено) · Жалоба iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1460 iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1472 IMHO, первое правило переопределяется вторым. И в мане в разделе TCPMSS цитирую This target allows to alter the MSS value of TCP SYN packets, to control the maximum size for that connection (usually limiting it to your outgoing interface's MTU minus 40). Of course, it can only be used in conjunction with -p tcp. It is only valid in the mangle table.Судя по последнему предложению, правило имеет силу только в таблице mangle taf_321, тогда почему разработчики в своём мане приводят следующий пример: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \ -j TCPMSS --clamp-mss-to-pmtu лажанулись? PS Перенос правила iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu в цепочку POSTROUTING не повлиял на появление сообщений, так и валят в лог... Пробую жёстко задавать 1460. PPS Сообщения продолжают появляться по 2-3 в минуту при любых вариантах расположения правила. Пробовал и так и сяк. Без данного правила сообщения не появляются, но появляется матюки от некоторых абонентов. это исправиться только полным ребутом сервера, так как правила iptables,sysctrl,tc, жестко задёствуются после полного ребута ядра Изменено 8 января, 2012 пользователем alexaaa Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lan-viper Опубликовано 8 января, 2012 (изменено) · Жалоба Надеюсь, это была шутка с вашей стороны. Упустил важную деталь, в сети разрешено mppe по требованию клиента. Изменено 8 января, 2012 пользователем lan-viper Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alexaaa Опубликовано 8 января, 2012 (изменено) · Жалоба Надеюсь, это была шутка с вашей стороны. Упустил важную деталь, в сети разрешено mppe по требованию клиента. Так что mss у таких клиентов будет меньше заявленных 1460 с шифрование у нас тоже работало. но мы его отключили чтобы снизить нагрузку на сервера, отключить его можно функцией [ppp] ccp=0 Изменено 8 января, 2012 пользователем alexaaa Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mmv980 Опубликовано 8 января, 2012 · Жалоба [ppp]verbose=1 min-mtu=1000 mtu=1400 mru=1400 iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1460 iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1472 Не кажется ли Вам что выделенные циферки конфликтуют друг с другом и в правилах iptables надобы написать 1360??? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lan-viper Опубликовано 8 января, 2012 (изменено) · Жалоба mmv980, всё верно. На домашнем роутере когда поднимается тунель, то MTU у него именно 1400 (исходя из настроек accel-ppp), на сервере туннель так же с MTU 1400. Для l2tp значением mss будет 1372, а для pptp - 1360. Подтверждается хотя-бы пингом с клиентского ПК: ping -f -l 1373 ya.ru у меня уже требует фрагментации, а 1372 проходит нормально. Но отошли от темы - сообщение в логах всё равно присутствует!? # cat /var/log/kern.log | tail Jan 8 19:29:18 nas kernel: [885279.117250] xt_TCPMSS: bad length (41 bytes) Jan 8 19:29:32 nas kernel: [885293.031603] xt_TCPMSS: bad length (41 bytes) Jan 8 19:30:28 nas kernel: [885349.331528] xt_TCPMSS: bad length (41 bytes) Jan 8 19:30:42 nas kernel: [885363.630631] xt_TCPMSS: bad length (41 bytes) Jan 8 19:44:02 nas kernel: [886162.846974] xt_TCPMSS: bad length (41 bytes) Jan 8 19:53:56 nas kernel: [886757.149446] xt_TCPMSS: bad length (41 bytes) Jan 8 19:57:19 nas kernel: [886960.027561] xt_TCPMSS: bad length (41 bytes) Jan 8 19:58:25 nas kernel: [887026.164193] xt_TCPMSS: bad length (41 bytes) Jan 8 20:00:31 nas kernel: [887152.751347] xt_TCPMSS: bad length (41 bytes) Jan 8 20:01:22 nas kernel: [887203.126974] xt_TCPMSS: bad length (41 bytes) Изменено 8 января, 2012 пользователем lan-viper Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lan-viper Опубликовано 9 января, 2012 · Жалоба При прохождении FORWARD система еще не знает через какой интерфейс пакет должен будет уйти, поэтому однозначно определить pmtu не может. Решение о маршрутизации пакета принимается до таблицы FORWARD, так что интерфейс уже известен. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mmv980 Опубликовано 9 января, 2012 · Жалоба Может перед правилом с TCPMSS поставить правило логирования пакетов с размером в 41 байт? что нибудь типа: iptables -t mangle -A FORWARD -p tcp -m limit --limit=1/minute --limit-burst=10 -m length --length 41 -j LOG --log-prefix="TCPMSS 41 log:" Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alexaaa Опубликовано 9 января, 2012 (изменено) · Жалоба Не знаю как у Вас, но у нас пропала эта проблема и решилась прописанием правила iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1460 а как это расчитывается, стандартный mtu=1500 -40 для pptp(l2tp)тунеля получается 1460, посмотрите например даже в описание Mikrotik значение mtu и mru, http://www.mikrotik.com/documentation/manual_2.7/Interface/L2TP.html есть даже на иностранном сайте таблица стандартных mtu значений для разных типов соединений, сайт правда уже не помню. Изменено 9 января, 2012 пользователем alexaaa Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lan-viper Опубликовано 9 января, 2012 · Жалоба стандартный mtu=1500"стандартный" в прикладном случае (моём, Вашем и любом другом) - это такой mtu, который задан на интерфейсе => на туннелях у меня MTU=1400.Проблему так и не локализовал, буду отслеживать, как советовал mmv980, иначе никак. Логи ядра не информативны, но по ним ясно, что гадит один или пару абонентов, т.к. бывают промежутки времени и даже дни, когда этих сообщений в логе нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mmv980 Опубликовано 9 января, 2012 · Жалоба а какая версия ядра? и может логировать не только пакеты в 41 байт а весь диаппазон от 1 до 40? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lan-viper Опубликовано 9 января, 2012 (изменено) · Жалоба # uname -a Linux nas 2.6.32-custom #1 SMP Wed Apr 20 08:56:37 MSD 2011 i686 GNU/Linux debian squeeze К сожалению логгирование пакетов длины 41 не дало результата. Изменено 9 января, 2012 пользователем lan-viper Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
mmv980 Опубликовано 9 января, 2012 · Жалоба В коде ядра версии 2.6.32 в файле xt_TCPMSS.c есть такие строчки: /* Since it passed flags test in tcp match, we know it is is not a fragment, and has data >= tcp header length. SYN packets should not contain data: if they did, then we risk running over MTU, sending Frag Needed and breaking things badly. --RR */ if (tcplen != tcph->doff*4) { if (net_ratelimit()) printk(KERN_ERR "xt_TCPMSS: bad length (%u bytes)\n", skb->len); return -1; } а в версии например 2.6.37 проверка все еще есть а вывода в лог уже нет. /* Header cannot be larger than the packet */ if (tcplen < tcph->doff*4) return -1; так что предлагаю варианты: 1. обновить ядро 2. забить и оставить как есть :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lan-viper Опубликовано 10 января, 2012 · Жалоба а в версии например 2.6.37 проверка все еще есть а вывода в лог уже нет. Вот за эту информацию спасибо (для моей версии в сети есть патч, который делает тоже самое). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alexaaa Опубликовано 10 января, 2012 (изменено) · Жалоба У меня тоже debian sqeeze 2.6.32 и accel-ppp, и решилась эта проблема, и даже ядро менять не пришлось. Изменено 10 января, 2012 пользователем alexaaa Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 10 января, 2012 · Жалоба К сожалению логгирование пакетов длины 41 не дало результата. Длинны чего? - с ethernet - с IP - данных в TCP Потому, скорее всего, и не дало. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
lan-viper Опубликовано 11 января, 2012 · Жалоба Мы вообщето говорим в контексте netfilter, где ниже IP ничего нет, а сама проблема касается только TCP протокола => всё это мной учитывалось при составлении правила логгирования на интерфейсах туннелей. Неполучилось по другим причинам. Вообще, как я понял, смысл этой ошибки в том, что TCP SYN пакет должен состоять только из заголовка (без данных) и в случае, если прилетает какой-то левый пакет (сверяется его длина), то ядро шлёт ошибку типа KERN_ERR в логи. В современных ядрах решили убрать такое поведение ядра, теперь оно молча игнорирует невалидные пакетики. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
bos9 Опубликовано 30 марта, 2012 · Жалоба Была таже проблема, в rsyslogd решается одной строкой в конфиге: :msg, contains, "xt_TCPMSS: bad length" ~ Можно накатить syslog-ng там тоже есть фильтрация сообщений. Ковырять из-за этого сорцы ядра на рабочей машине как-то лениво, тем более, что суть одна - не писать в лог эти сообщения. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...