Jump to content
Dale

Странная работа tcp adjust-mss pmtu

Recommended Posts

Обратил внимание, что для моего 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

 

 

Share this post


Link to post
Share on other sites
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

  • Thanks 1

Share this post


Link to post
Share on other sites
9 hours ago, Le ecureuil said:

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

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

Share this post


Link to post
Share on other sites
13 часа назад, Dale сказал:

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

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

  • Thanks 1

Share this post


Link to post
Share on other sites
14 часа назад, Dale сказал:

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

 

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

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

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

Share this post


Link to post
Share on other sites
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 by Dale

Share this post


Link to post
Share on other sites
9 часов назад, Sfut сказал:

 

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

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

  • Thanks 4

Share this post


Link to post
Share on other sites
Только что, Le ecureuil сказал:

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

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

Share this post


Link to post
Share on other sites
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 заголовков, потому там есть неточности. Однако суть верна, будет использоваться самое оптимальное значение из возможных.

Share this post


Link to post
Share on other sites
Только что, r13 сказал:

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

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

Share this post


Link to post
Share on other sites
1 hour ago, Le ecureuil said:

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

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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
2 часа назад, Dale сказал:

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

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

Share this post


Link to post
Share on other sites
4 hours ago, Le ecureuil said:

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

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

Share this post


Link to post
Share on other sites
В 2/22/2017 в 23:00, Dale сказал:

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

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

Share this post


Link to post
Share on other sites
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 by Dale

Share this post


Link to post
Share on other sites
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, как и должно быть. А что тут странного?

Share this post


Link to post
Share on other sites
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 лет. :D

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

Edited by Dale

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...