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

[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

 

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]

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]

9 hours ago, Le ecureuil said:

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

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

[Le ecureuil]

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

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

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

[Sfut]

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

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

 

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

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

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

[Dale]

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.

Edited February 21, 2017 by Dale

[Le ecureuil]

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

 

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

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

[r13]

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

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

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

[Le ecureuil]

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]

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

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

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

[Dale]

1 hour ago, Le ecureuil said:

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

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

[Le ecureuil]

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]

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]

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

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

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

[Dale]

4 hours ago, Le ecureuil said:

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

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

[Le ecureuil]

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

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

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

[Dale]

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 И т.д.

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

Edited February 28, 2017 by Dale

[Le ecureuil]

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]

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 Кстати, можете считать это сообщение багрепортом.

Edited February 28, 2017 by Dale

[ndm]

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