исправлено Странная работа tcp adjust-mss pmtu

Dale · 20 февраля, 2017

Обратил внимание, что для моего L2TP/IPSec соединения (конфиг ниже прилагаю) очень странно работает tcp adjust-mss pmtu с некоторыми сайтами, например forum.keenetic.net, сервисы google (например, получение почты через мобильный клиент, hangouts через web-интерфейс и пр.) - для пользователя это выглядит как очень медленное, с таймаутами, соединение. Но если проявить настойчивость, то после нескольких таймаутов соединение с сайтом устанавливается и все начинает работать как положено, до отключения L2TP/IPSec соединения. При соединении через PPTP такого не наблюдается. Как можно исправить эту проблему понятно, поставить в ip tcp adjust-mss значение поменьше, но хотелось бы, чтобы заработало и tcp adjust-mss pmtu. Версия прошивки v2.09(AAUX.5)A3

Spoiler


interface L2TP0
    description "Private Internet Access"
    peer 178.162.211.216
    no ipv6cp
    lcp echo 30 3
    ipcp default-route
    ipcp name-servers
    ipcp dns-routes
    no ccp
    security-level public
    authentication identity ***
    authentication password ns3 ***
    ip dhcp client dns-routes
    ip dhcp client name-servers
    ip mtu 1400
    ip global 1000
    ip tcp adjust-mss pmtu
    ipsec preshared-key ns3 ***
    connect
    up

Le ecureuil · 20 февраля, 2017

5 минут назад, Dale сказал:
Обратил внимание, что для моего L2TP/IPSec соединения (конфиг ниже прилагаю) очень странно работает tcp adjust-mss pmtu с некоторыми сайтами, например forum.keenetic.net, сервисы google (например, получение почты через мобильный клиент, hangouts через web-интерфейс и пр.) - для пользователя это выглядит как очень медленное, с таймаутами, соединение. Но если проявить настойчивость, то после нескольких таймаутов соединение с сайтом устанавливается и все начинает работать как положено, до отключения L2TP/IPSec соединения. При соединении через PPTP такого не наблюдается. Как можно исправить эту проблему понятно, поставить в ip tcp adjust-mss значение поменьше, но хотелось бы, чтобы заработало и tcp adjust-mss pmtu. Версия прошивки v2.09(AAUX.5)A3
Скрыть содержимое
interface L2TP0
    description "Private Internet Access"
    peer 178.162.211.216
    no ipv6cp
    lcp echo 30 3
    ipcp default-route
    ipcp name-servers
    ipcp dns-routes
    no ccp
    security-level public
    authentication identity ***
    authentication password ns3 ***
    ip dhcp client dns-routes
    ip dhcp client name-servers
    ip mtu 1400
    ip global 1000
    ip tcp adjust-mss pmtu
    ipsec preshared-key ns3 ***
    connect
    up

Попробуйте выполнить
> interface L2TP0 ip mtu 1300

Dale · 20 февраля, 2017

9 hours ago, Le ecureuil said:

Попробуйте выполнить
> interface L2TP0 ip mtu 1300

Создал заново соединение, установил MTU для него по Вашей рекомендации и подключился. Подтверждаю, проблема исчезла. Может, стоит изменить дефолтные настройки при создании L2TP/IPSec соединения?

Le ecureuil · 21 февраля, 2017

13 часа назад, Dale сказал:

Создал заново соединение, установил MTU для него по Вашей рекомендации и подключился. Подтверждаю, проблема исчезла. Может, стоит изменить дефолтные настройки при создании L2TP/IPSec соединения?

Да, сделаем, спасибо за репорт.

Sfut · 21 февраля, 2017

14 часа назад, Dale сказал:

Может, стоит изменить дефолтные настройки при создании L2TP/IPSec соединения?

14 минуты назад, Le ecureuil сказал:

Да, сделаем, спасибо за репорт.

Может быть это проблемы конкретного провайдера и не стоит уменьшать размер MTU по дефолту? У меня провайдер на PPPoE аргументируя такими же проблемами уменьшил MTU до 1200 и планирует уменьшить еще до 1000. Хотя у других провайдеров в городе прекрасно работает на 1492.

Dale · 21 февраля, 2017

4 hours ago, Sfut said:

Может быть это проблемы конкретного провайдера и не стоит уменьшать размер MTU по дефолту? У меня провайдер на PPPoE аргументируя такими же проблемами уменьшил MTU до 1200 и планирует уменьшить еще до 1000. Хотя у других провайдеров в городе прекрасно работает на 1492.

Я это понимаю так: тут дело не в размере MTU, допустимом у конкретного VPN провайдера, а в том, что при соединении с некоторыми сайтами алгоритм автоматического регулирования MSS по каким-то причинам работает криво (например, админы запретили ICMP пакеты на каком-то промежуточном узле и не приходит ответ fragmentation needed), если изначально установлено слишком большое значение MTU. И именно поэтому я предлагаю изменить дефолтное значение MTU при создании соединения L2TP/IPSec, чтобы алгоритм автоматического изменения MSS работал более корректно.

PS Кстати, по поводу MSS на L2TP/IPSec соединении. Прочитал тут один занятный документ, называется "IPSec Bandwidth Overhead Using AES". Там расчитывается полный overhead для разных MSS и показывается, что максимизация MSS вовсе не ускоряет скорость инкапсулированного соединения, а оптимальное значение равно 1328.

Изменено 21 февраля, 2017 пользователем Dale

Le ecureuil · 21 февраля, 2017

9 часов назад, Sfut сказал:

Может быть это проблемы конкретного провайдера и не стоит уменьшать размер MTU по дефолту? У меня провайдер на PPPoE аргументируя такими же проблемами уменьшил MTU до 1200 и планирует уменьшить еще до 1000. Хотя у других провайдеров в городе прекрасно работает на 1492.

Будет сделан автоматический расчет на основе MTU интерфейса, через который пойдет соединение. Если у вас все пойдет через IPoE с 1500, то значение будет одно, если через PPTP с VLAN, то другое.

r13 · 21 февраля, 2017

Только что, Le ecureuil сказал:

Будет сделан автоматический расчет на основе MTU интерфейса, через который пойдет соединение. Если у вас все пойдет через IPoE с 1500, то значение будет одно, если через PPTP с VLAN, то другое.

@Le ecureuil а с VirtualIP как сейчас происходит расчет mtu? только в одну сторону( интернет) или и mtu до клиента тоже учитываетя?

Le ecureuil · 21 февраля, 2017

8 часов назад, Dale сказал:

Я это понимаю так: тут дело не в размере MTU, допустимом у конкретного VPN провайдера, а в том, что при соединении с некоторыми сайтами алгоритм автоматического регулирования MSS по каким-то причинам работает криво (например, админы запретили ICMP пакеты на каком-то промежуточном узле и не приходит ответ fragmentation needed), если изначально установлено слишком большое значение MTU. И именно поэтому я предлагаю изменить дефолтное значение MTU при создании соединения L2TP/IPSec, чтобы алгоритм автоматического изменения MSS работал более корректно.

PS Кстати, по поводу MSS на L2TP/IPSec соединении. Прочитал тут один занятный документ, называется "IPSec Bandwidth Overhead Using AES". Там расчитывается полный overhead для разных MSS и показывается, что максимизация MSS вовсе не ускоряет скорость инкапсулированного соединения, а оптимальное значение равно 1328.

В этой статье не учитывается размер L2TP и NAT-T Encap заголовков, потому там есть неточности. Однако суть верна, будет использоваться самое оптимальное значение из возможных.

Le ecureuil · 21 февраля, 2017

Только что, r13 сказал:

@Le ecureuil а с VirtualIP как сейчас происходит расчет mtu? только в одну сторону( интернет) или и mtu до клиента тоже учитываетя?

Virtual-IP сейчас не рассчитывается, поскольку при таком типе туннеля не создается отдельного интерфейса для задания MTU. Но там стоит TCP MSS PMTU Clamp + юзер волен в консоли задать любое значение Clamp руками.

Dale · 21 февраля, 2017

1 hour ago, Le ecureuil said:

В этой статье не учитывается размер L2TP и NAT-T Encap заголовков, потому там есть неточности. Однако суть верна, будет использоваться самое оптимальное значение из возможных.

Я эту статью привел просто в качестве примера того, что не всегда увеличение MSS приводит к увеличению скорости инкапсулированного соединения (интересно было бы посчитать с учетом всех заголовков, а какой MSS действительно будет оптимальным), а уж про увеличение MTU при активном PMTUD я и не говорю даже. Кстати, после изучения цисковского описания PMTUD у меня сложилось впечатление, что он может только уменьшать MSS при попытке TCP соединения, а увеличение как-то не предусмотрено. Я что-то недопонял или тут алгоритм более гибкий?

Le ecureuil · 22 февраля, 2017

11 час назад, Dale сказал:

Я эту статью привел просто в качестве примера того, что не всегда увеличение MSS приводит к увеличению скорости инкапсулированного соединения (интересно было бы посчитать с учетом всех заголовков, а какой MSS действительно будет оптимальным), а уж про увеличение MTU при активном PMTUD я и не говорю даже. Кстати, после изучения цисковского описания PMTUD у меня сложилось впечатление, что он может только уменьшать MSS при попытке TCP соединения, а увеличение как-то не предусмотрено. Я что-то недопонял или тут алгоритм более гибкий?

"Talk's cheap, show us the code!"
https://github.com/ndmsystems/linux-3.4/blob/master/net/netfilter/xt_TCPMSS.c#L132

Dale · 22 февраля, 2017

4 hours ago, Le ecureuil said:

"Talk's cheap, show us the code!"
https://github.com/ndmsystems/linux-3.4/blob/master/net/netfilter/xt_TCPMSS.c#L132

Понятно. А как же RFC4821? Там как раз описывается вариант PMTUD с увеличением MSS.

Le ecureuil · 22 февраля, 2017

2 часа назад, Dale сказал:

Понятно. А как же RFC4821? Там как раз описывается вариант PMTUD с увеличением MSS.

Даже в linux-next этот код не изменен, значит на то есть причины.

Dale · 22 февраля, 2017

4 hours ago, Le ecureuil said:

Даже в linux-next этот код не изменен, значит на то есть причины.

Это не показатель. Например, баг в модуле PPTP "mppe_compress[0]: osize too small! (have: 1404 need: 1408)" существует как минимум с 2005 года, а периодически он прорывается до сих пор (у вас это тоже было, кстати, совсем недавно ).

Le ecureuil · 27 февраля, 2017

В 2/22/2017 в 23:00, Dale сказал:

Это не показатель. Например, баг в модуле PPTP "mppe_compress[0]: osize too small! (have: 1404 need: 1408)" существует как минимум с 2005 года, а периодически он прорывается до сих пор (у вас это тоже было, кстати, совсем недавно ).

Технически это не баг в mppe, это особенность работы в режиме, когда MTU роута меняется.

Dale · 28 февраля, 2017

14 hours ago, Le ecureuil said:

Технически это не баг в mppe, это особенность работы в режиме, когда MTU роута меняется.

А я не про то, что такое сообщение выводилось, хотя оно, конечно, раздражало, а про то, что оно выводилось неправильно. Как Вы там говорили, "Talk's cheap, show us the code!"? Их есть у меня:

Spoiler


drivers/net/ppp/ppp_mppe.c:

        /* Make sure we have enough room to generate an encrypted packet. */
        if (osize < isize + MPPE_OVHD + 2) {
                /* Drop the packet if we should encrypt it, but can't. */
                printk(KERN_DEBUG "mppe_compress[%d]: osize too small! "
                       "(have: %d need: %d)\n", state->unit,
                       osize, osize + MPPE_OVHD + 2);
                return -1;
        }

https://github.com/torvalds/linux/blob/master/drivers/net/ppp/ppp_mppe.c#L384 https://github.com/ndmsystems/linux-3.4/blob/master/drivers/net/ppp/ppp_mppe.c#L383 И т.д.

Ничего странного не замечаете?

Изменено 28 февраля, 2017 пользователем Dale

Le ecureuil · 28 февраля, 2017

6 часов назад, Dale сказал:
А я не про то, что такое сообщение выводилось, хотя оно, конечно, раздражало, а про то, что оно выводилось неправильно. Как Вы там говорили, "Talk's cheap, show us the code!"? Их есть у меня:
Скрыть содержимое
drivers/net/ppp/ppp_mppe.c:

        /* Make sure we have enough room to generate an encrypted packet. */
        if (osize < isize + MPPE_OVHD + 2) {
                /* Drop the packet if we should encrypt it, but can't. */
                printk(KERN_DEBUG "mppe_compress[%d]: osize too small! "
                       "(have: %d need: %d)\n", state->unit,
                       osize, osize + MPPE_OVHD + 2);
                return -1;
        }
https://github.com/torvalds/linux/blob/master/drivers/net/ppp/ppp_mppe.c#L384 https://github.com/ndmsystems/linux-3.4/blob/master/drivers/net/ppp/ppp_mppe.c#L383 И т.д.

Ничего странного не замечаете?

Код 1-в-1 с vanilla, как и должно быть. А что тут странного?

Dale · 28 февраля, 2017

5 hours ago, Le ecureuil said:

Код 1-в-1 с vanilla, как и должно быть. А что тут странного?

Понятно, неудивительно, что этот баг плавает с 2005 года и периодически выныривает Смотрите, в данном куске кода сравниваются значения osize и isize+MPPE_OVHD+2. В случае, если первое меньше второго, то пакет дропается и выводится то самое отладочное сообщение, что osize (практически это MTU) слишком мало и оно должно быть не меньше чем osize+MPPE_OVHD+2, хотя по логике вещей должно выводиться сообщение, что osize должно быть не меньше чем isize+MPPE_OVHD+2. В первом случае сообщение бесполезно и является неинформативным, более того, в интернете полно пользователей и советчиков, которые увидев это сообщение увеличивают MTU на 4 и удивляются, почему сообщение продолжает возникать вновь, но со значениями, увеличенными на 4. Во втором случае сообщение весьма информативно и пользователь может из него сделать выводы в виде изменения начального значения MTU на основании реальных данных. А вы говорите, про новые алгоритмы, которые не реализовывают якобы из-за каких-то высших соображений, а такой банальный баг копипастят уже более 10 лет.

PS Кстати, можете считать это сообщение багрепортом.

Изменено 28 февраля, 2017 пользователем Dale

ndm · 27 марта, 2017

Исправлено в версии 2.09.A.5.0-1.

Войти

исправлено Странная работа tcp adjust-mss pmtu

Рекомендуемые сообщения

Dale

Le ecureuil

Dale

Le ecureuil

Sfut

Dale

Le ecureuil

r13

Le ecureuil

Le ecureuil

Dale

Le ecureuil

Dale

Le ecureuil

Dale

Le ecureuil

Dale

Le ecureuil

Dale

ndm

Присоединяйтесь к обсуждению

Последние посетители 0 пользователей онлайн

Обзор

Активность

Магазин

My Details

Важная информация