forum.opennet.ru - "Раздел полезных советов: Автоматическое изменение MTU при поднятии VPN соединения" (23)

"Раздел полезных советов: Автоматическое изменение MTU при поднятии VPN соединения"

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Раздел полезных советов: Автоматическое изменение MTU при поднятии VPN соединения"	+/–
Сообщение от auto_tips (?), 09-Дек-08, 22:45
Столкнулся с такой проблемой, что при поднятии VPN соединения по умолчанию у каждого соединения MTU равен был 1396. В результате чего не работало большое количество сайтов. Решение такое. Сервер Fedora 8, с установленным pptpd. в скрипт /etc/ppp/ip-up добавил одно условие: if [ "${REALDEVICE}" != "ppp0" ]; then ifconfig ${REALDEVICE} mtu 1400 fi Теперь скрипт выглядит так: #!/bin/bash # This file should not be modified -- make local changes to # /etc/ppp/ip-up.local instead PATH=/sbin:/usr/sbin:/bin:/usr/bin export PATH LOGDEVICE=$6 REALDEVICE=$1 [ -f /etc/sysconfig/network-scripts/ifcfg-${LOGDEVICE} ] && /etc/sysconfig/network-scripts/ifup-post --realdevice ${REALDEVICE} ifcfg-${LOGDEVICE} /etc/ppp/ip-up.ipv6to4 ${LOGDEVICE} if [ "${REALDEVICE}" != "ppp0" ]; then ifconfig ${REALDEVICE} mtu 1400 fi [ -x /etc/ppp/ip-up.local ] && /etc/ppp/ip-up.local "$@" exit 0 PS. Средствами pptpd я не смог установить MTU в нужное значение. Если есть какие либо идеи, не поленитесь, поделитесь :) URL: Обсуждается: http://www.opennet.me/tips/info/1863.shtml
Ответить \| Правка \| Cообщить модератору

Оглавление

Это можно прочитать примерно следующим образом Я заметил что перестал пролезать , tamerlan311 (?), 22:45 , 09-Дек-08, (1)

Кстати, дайте что-нибудь про MTU прочитать , Руслан (?), 02:06 , 10-Дек-08, (7)

man iptablessearch --clamp-mss-to-pmtu , slavon_net (?), 23:06 , 09-Дек-08, (2)

Хм Интересно , frey (ok), 14:17 , 10-Дек-08, (16)

А почему именно на 1400 Cтандартное значение 1500, для многих adsl, vpn надо , vadiml (?), 23:16 , 09-Дек-08, (3)

Удалять не надо Ведь до этого решения кто-то дошел своим умом И ему помогло А , Руслан (?), 01:55 , 10-Дек-08, (5)

ужос,кто то проверяет их перед размещением , max (??), 01:29 , 10-Дек-08, (4) +1

Человек показал работающий вариат обхода проблемы Что то я не увидел, чтобы хот, Антон (??), 09:22 , 10-Дек-08, (12)

чуть выше же уже намекнули TCPMSS This target allows to alter the MSS val, vitek (??), 09:54 , 10-Дек-08, (13) +1

У меня есть мысль, что иногда вознимающая проблема на одном из подвластных мне ш, Руслан (?), 02:03 , 10-Дек-08, (6)
Природа появления этого совета такова Есть у одной организации несколько филиало, HolyGun (?), 03:36 , 10-Дек-08, (8)

Потому что здесь описано как бороться со следствием и к тому, на мой взгляд, дал, vadiml (?), 09:18 , 10-Дек-08, (11)

Использую в Fedora 8 другое решение Взял патч из initscripts ASPLinux 12 ту его, Аноним (9), 05:12 , 10-Дек-08, (9)

Вы хоть сами поняли, что сказали Если бы не было шифрования, то и мту остался т, frey (ok), 14:16 , 10-Дек-08, (15)

man pppd Есть опции mru n и mtu n можно для каждого vpn-канала сделать разные m, suvit (?), 08:42 , 10-Дек-08, (10)
Прежде чем ругаться, надо разобраться Во-первых, описанный способ решает проблем, Аноним (9), 11:05 , 11-Дек-08, (17)

Не на то ответил, sorry , Аноним (9), 11:07 , 11-Дек-08, (18)
Можно вопрос в догонку Ситуация такая 1 от прова инет приходит через адсл ,с , port20031 (??), 13:49 , 11-Дек-08, (19)
В случае pptp на сервере в etc ppp options pptp достаточно указать mru mtu и не, sfstudio (?), 16:05 , 11-Дек-08, (20)

root sadnet linux pppd --version pppd version 2 4 5 2 4 5 или я отстал от жиз, replicant (?), 00:14 , 15-Дек-08, (21)
Это костыли Достаточно правильно настроить mpd добавив опцию set pptp disable w, rrv (ok), 08:44 , 15-Дек-08, (22)
тоже натолкнулся на теже грабли, вообщем решение простое, выставляем mtu mru в к, andrek (?), 03:55 , 02-Сен-09, (23)
Товарищи, а что можете сказать по такой теме CentOS 7, PPTPD 2 4 5 со стандартн, EIKA (ok), 20:24 , 20-Ноя-18, (24)

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от tamerlan311 (?), 09-Дек-08, 22:45 +/–

Это можно прочитать примерно следующим образом:
Я заметил что перестал пролезать в двери, чтобы исправить ситуацию я немного потолстел. Теперь пролезаю без всяких проблем.
Уберите пожалуйста ваш говносовет, почините бубен и почитайте что-нибудь про MTU.
1400 > 1396

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #7

2. Сообщение от slavon_net (?), 09-Дек-08, 23:06 +/–

man iptables
search "--clamp-mss-to-pmtu"

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #16

3. Сообщение от vadiml (?), 09-Дек-08, 23:16 +/–

А почему именно на 1400?
Cтандартное значение == 1500, для многих adsl, vpn надо 1492.
Но если Вы не обрезаете у себя icmp, то сетевые сами договорятся о нужном значении MTU.
PS у меня pptp MTU не меняет на для ppp0, ни для 5 других интерфейсов на моей машине (lo, eth0, eth1, vmnet1, vmnet8) и он вообще его менять не должен если специально не указано, тем более у других соединений.
PPS предлагаю завести key -- "вредные советы".

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #5

4. Сообщение от max (??), 10-Дек-08, 01:29 +1 +/–

ужос,кто то проверяет их перед размещением??

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #12

5. Сообщение от Руслан (?), 10-Дек-08, 01:55 +/–

Удалять не надо.
Ведь до этого решения кто-то дошел своим умом. И ему помогло.
А "вредные советы" или "AS IS" завести следовало бы. :)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3

6. Сообщение от Руслан (?), 10-Дек-08, 02:03 +/–

У меня есть мысль, что иногда вознимающая проблема на одном из подвластных мне шлюзов, имеет подобное происхождение.
Исходные данные: 1 шлюз под debian linux 2.6, 1 шлюз под FreeBSD 4.9 + ipfw.
В произвольный момент времени случается затор, в результате которого полностью перестает
а) ходить трафик между шлюзами
б) коннектиться один из шлюзов к другому
Смысла перегружать что-либо нет, хотя помогает. Смысла нет потому, что на сотню других шлюзов, общающихся с этими двумя, раз в месяц найдется еще один страдалец. И этот страдалец не будет перезагружаться ради нас, равно как и мы ради него.

Ответить | Правка | Наверх | Cообщить модератору

7. Сообщение от Руслан (?), 10-Дек-08, 02:06 +/–

Кстати, дайте что-нибудь про MTU прочитать.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

8. Сообщение от HolyGun (?), 10-Дек-08, 03:36 +/–

Природа появления этого совета такова.
Есть у одной организации несколько филиалов по городу. В этом городе есть городская локальная сеть. Каждый филиал подключен к этой сети. Скажем так, центральный офис также подключен к данной сети. И чтобы не покупать у провайдера, к примеру N одинаковых тарифных планов для выхода филиалов в интернет, было решено купить 1 большой ТП, и раздавать по филиалам интернет через городскую сетку. Вариант с прокси не подходил по многим причинам. Поэтому решено было запустить VPN.
Проблема образовалась почти сразу же. Не все сайты работали. Отсутствовала связь с некоторыми почтовыми серверами. Причем с шлюза в центральном офисе все работало как часы.
Опытным путем я выяснил, что нормальному прохождению пакетов мешал дефолтный MTU VPN соединения, который был установлен в 1396. А на шлюзе, у pppoe MTU:1492. Стал пробовать вручную менять у VPN соединений MTU, и о чудо! При значении 1400 все заработало.
В сроках решения проблемы руководство организации меня очень сильно ограничило, поэтому пришлось эту проблему решить именно таким способом. Времени изучать мануалы у меня небыло. Да и как-то потом отпала надобность, ибо проблема была решена.
Вопрос. А почему "ведные советы"?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #11

9. Сообщение от Аноним (9), 10-Дек-08, 05:12 +/–

Использую в Fedora 8 другое решение.
Взял патч из initscripts ASPLinux 12 (ту его часть, которая изменяет и добавляет скрипты для поддержки ifup pptp0).
В ifcfg-pptp0 можно указать MTU=1460 и MRU=1460 (впн без шифрования, поэтому получается на 40 байт меньше, чем MTU для eth0).

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #15

10. Сообщение от suvit (?), 10-Дек-08, 08:42 +/–

man pppd. Есть опции mru n и mtu n.
можно для каждого vpn-канала сделать разные mru и mtu, это ставится в конфиге соединения.

Ответить | Правка | Наверх | Cообщить модератору

11. Сообщение от vadiml (?), 10-Дек-08, 09:18 +/–

>Вопрос. А почему "ведные советы"?
Потому что здесь описано как бороться со следствием и к тому, на мой взгляд, далеко не лучший вариант,
а надо искать причину и устранять её.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

12. Сообщение от Антон (??), 10-Дек-08, 09:22 +/–

>ужос,кто то проверяет их перед размещением??
Человек показал работающий вариат обхода проблемы. Что то я не увидел, чтобы хоть один из комментаторов кроме пустой критики показал свой вариант решения. Я свое время тоже MTU на интерефейсе поднимал экспериментальным путем и все начинало работать.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #13

13. Сообщение от vitek (??), 10-Дек-08, 09:54 +1 +/–

чуть выше же уже намекнули!
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. This target is used to overcome criminally braindead ISPs or  servers  which  block  ICMP  Fragmentation Needed  packets.   The  symptoms  of  this  problem are that everything works fine from your Linux fire‐wall/router, but machines behind it can never exchange large packets:
        1) Web browsers connect, then hang with no data received.
        2) Small mail works fine, but large emails hang.
        3) ssh works fine, but scp hangs after initial handshaking.
       Workaround: activate this option and add a rule to your firewall configuration like:
        iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
                    -j TCPMSS --clamp-mss-to-pmtu
       --set-mss value
              Explicitly set MSS option to specified value.
       --clamp-mss-to-pmtu
              Automatically clamp MSS value to (path_MTU - 40).
       These options are mutually exclusive.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

15. Сообщение от frey (ok), 10-Дек-08, 14:16 +/–

>Использую в Fedora 8 другое решение.
>Взял патч из initscripts ASPLinux 12 (ту его часть, которая изменяет и
>добавляет скрипты для поддержки ifup pptp0).
>В ifcfg-pptp0 можно указать MTU=1460 и MRU=1460 (впн без шифрования, поэтому получается
>на 40 байт меньше, чем MTU для eth0).
Вы хоть сами поняли, что сказали? Если бы не было шифрования, то и мту остался тотже. В pptp используется 4 байта для шифрования (при require-mppe-128) и мту нужно ставить 1496 в таком случае.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

16. Сообщение от frey (ok), 10-Дек-08, 14:17 +/–

>man iptables
>search "--clamp-mss-to-pmtu"
Хм! Интересно!

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

17. Сообщение от Аноним (9), 11-Дек-08, 11:05 +/–

Прежде чем ругаться, надо разобраться.
Во-первых, описанный способ решает проблему на линуксовом сервере с виндовыми клиентами, или на линуксовом клиенте? Если случай #1, тогда всё совершенно правильно, т.к. винда при поднятии VPN искренне считает, что у неё MTU 1400. Причём, обратите внимание, --clamp-mss-to-pmtu в данном случае не работает. Или работает неправильно, что, в общем, одно и то же.
Я у себя ситуацию решаю набором правил:
-A table -i ppp+ -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1301:1350 -j TCPMSS --set-mss 1300
-A table -i ppp+ -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1351:1400 -j TCPMSS --set-mss 1350
-A table -i ppp+ -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1401:1450 -j TCPMSS --set-mss 1400
-A table -i ppp+ -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1451:65535 -j TCPMSS --set-mss 1430
Дискретность задайте сами какую вам нужно.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #18, #19, #20

18. Сообщение от Аноним (9), 11-Дек-08, 11:07 +/–

Не на то ответил, sorry.
>Прежде чем ругаться, надо разобраться.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

19. Сообщение от port20031 (??), 11-Дек-08, 13:49 +/–

Можно вопрос в догонку ?
Ситуация такая :
1)от прова инет приходит через адсл ,с него на свич ,со свича компы получают реальные ип;
2)на одном из них крутится мой сервак , на нем есть сервер впн , который нормально обслуживает компы с серой сетки и компы , подключенные со свича .
Проблема в том что с инета  впн типа подымается , но там ни чего не ходит .
Может поможите ?

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

20. Сообщение от sfstudio (?), 11-Дек-08, 16:05 +/–

>на линуксовом клиенте? Если случай #1, тогда всё совершенно правильно, т.к.
>винда при поднятии VPN искренне считает, что у неё MTU 1400.
В случае pptp на сервере в /etc/ppp/options.pptp достаточно указать:
mru mtu и не заморачиваться, тогда значения будут корректно переданы вантузу и приняты в работу.
Ессно сразу заработает и --clamp-mss-to-pmtu
[root@sadnet:linux]# pptp --version
pptp version 1.7.2
[root@sadnet:linux]# pppd --version
pppd version 2.4.5
[root@sadnet:linux]# uname -a
Linux sadnet.lo 2.6.27.8 #9 Mon Dec 8 04:46:11 OMST 2008 i686 Pentium III (Coppermine) GNU/Linux

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17

21. Сообщение от replicant (?), 15-Дек-08, 00:14 +/–

[root@sadnet:linux]# pppd --version
pppd version 2.4.5
2.4.5 или я отстал от жизни?

Ответить | Правка | Наверх | Cообщить модератору

22. Сообщение от rrv (ok), 15-Дек-08, 08:44 +/–

Это костыли! Достаточно правильно настроить mpd добавив опцию set pptp disable windowing.
Читать тут http://rrv.nsk.ru/wiki/index.php/Vpn_server_%D0%BD...

Ответить | Правка | Наверх | Cообщить модератору

23. Сообщение от andrek (?), 02-Сен-09, 03:55 +/–

тоже натолкнулся на теже грабли, вообщем решение простое, выставляем mtu mru в конфиге ppptp-options, и результирующее правило в iptables:
$IPTABLES -A FORWARD -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 0:65535 -j TCPMSS --clamp-mss-to-pmtu -i ppp+

Ответить | Правка | Наверх | Cообщить модератору

24. Сообщение от EIKA (ok), 20-Ноя-18, 20:24 +/–

Товарищи, а что можете сказать по такой теме. CentOS 7, PPTPD 2.4.5 со стандартным конфигом. Цепляюсь к демону Микротиком, туннель поднят и активен, и все в целом работает отлично, но с некоторыми сайтами нет коннекта. Методом тыка, потратив целый день, нашел проблему - нужно MRU повысить на 4 единицы или более, тогда появляется коннект с "проблемными" сайтами. Сами по себе значения MTU и MRU не критичны, можно ставить все что угодно в диапазоне 1300-1492, но главное, чтобы выполнялось правило: MRU = MTU + 4 (или более). Куда бы копнуть по это теме?

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. Сообщение от tamerlan311 (?), 09-Дек-08, 22:45	+/–
Это можно прочитать примерно следующим образом: Я заметил что перестал пролезать в двери, чтобы исправить ситуацию я немного потолстел. Теперь пролезаю без всяких проблем. Уберите пожалуйста ваш говносовет, почините бубен и почитайте что-нибудь про MTU. 1400 > 1396
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #7

2. Сообщение от slavon_net (?), 09-Дек-08, 23:06	+/–
man iptables search "--clamp-mss-to-pmtu"
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #16

3. Сообщение от vadiml (?), 09-Дек-08, 23:16	+/–
А почему именно на 1400? Cтандартное значение == 1500, для многих adsl, vpn надо 1492. Но если Вы не обрезаете у себя icmp, то сетевые сами договорятся о нужном значении MTU. PS у меня pptp MTU не меняет на для ppp0, ни для 5 других интерфейсов на моей машине (lo, eth0, eth1, vmnet1, vmnet8) и он вообще его менять не должен если специально не указано, тем более у других соединений. PPS предлагаю завести key -- "вредные советы".
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #5

4. Сообщение от max (??), 10-Дек-08, 01:29	+1 +/–
ужос,кто то проверяет их перед размещением??
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #12

5. Сообщение от Руслан (?), 10-Дек-08, 01:55	+/–
Удалять не надо. Ведь до этого решения кто-то дошел своим умом. И ему помогло. А "вредные советы" или "AS IS" завести следовало бы. :)
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #3

6. Сообщение от Руслан (?), 10-Дек-08, 02:03	+/–
У меня есть мысль, что иногда вознимающая проблема на одном из подвластных мне шлюзов, имеет подобное происхождение. Исходные данные: 1 шлюз под debian linux 2.6, 1 шлюз под FreeBSD 4.9 + ipfw. В произвольный момент времени случается затор, в результате которого полностью перестает а) ходить трафик между шлюзами б) коннектиться один из шлюзов к другому Смысла перегружать что-либо нет, хотя помогает. Смысла нет потому, что на сотню других шлюзов, общающихся с этими двумя, раз в месяц найдется еще один страдалец. И этот страдалец не будет перезагружаться ради нас, равно как и мы ради него.
Ответить \| Правка \| Наверх \| Cообщить модератору

7. Сообщение от Руслан (?), 10-Дек-08, 02:06	+/–
Кстати, дайте что-нибудь про MTU прочитать.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #1

8. Сообщение от HolyGun (?), 10-Дек-08, 03:36	+/–
Природа появления этого совета такова. Есть у одной организации несколько филиалов по городу. В этом городе есть городская локальная сеть. Каждый филиал подключен к этой сети. Скажем так, центральный офис также подключен к данной сети. И чтобы не покупать у провайдера, к примеру N одинаковых тарифных планов для выхода филиалов в интернет, было решено купить 1 большой ТП, и раздавать по филиалам интернет через городскую сетку. Вариант с прокси не подходил по многим причинам. Поэтому решено было запустить VPN. Проблема образовалась почти сразу же. Не все сайты работали. Отсутствовала связь с некоторыми почтовыми серверами. Причем с шлюза в центральном офисе все работало как часы. Опытным путем я выяснил, что нормальному прохождению пакетов мешал дефолтный MTU VPN соединения, который был установлен в 1396. А на шлюзе, у pppoe MTU:1492. Стал пробовать вручную менять у VPN соединений MTU, и о чудо! При значении 1400 все заработало. В сроках решения проблемы руководство организации меня очень сильно ограничило, поэтому пришлось эту проблему решить именно таким способом. Времени изучать мануалы у меня небыло. Да и как-то потом отпала надобность, ибо проблема была решена. Вопрос. А почему "ведные советы"?
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #11

9. Сообщение от Аноним (9), 10-Дек-08, 05:12	+/–
Использую в Fedora 8 другое решение. Взял патч из initscripts ASPLinux 12 (ту его часть, которая изменяет и добавляет скрипты для поддержки ifup pptp0). В ifcfg-pptp0 можно указать MTU=1460 и MRU=1460 (впн без шифрования, поэтому получается на 40 байт меньше, чем MTU для eth0).
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #15

10. Сообщение от suvit (?), 10-Дек-08, 08:42	+/–
man pppd. Есть опции mru n и mtu n. можно для каждого vpn-канала сделать разные mru и mtu, это ставится в конфиге соединения.
Ответить \| Правка \| Наверх \| Cообщить модератору

11. Сообщение от vadiml (?), 10-Дек-08, 09:18	+/–
>Вопрос. А почему "ведные советы"? Потому что здесь описано как бороться со следствием и к тому, на мой взгляд, далеко не лучший вариант, а надо искать причину и устранять её.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #8

12. Сообщение от Антон (??), 10-Дек-08, 09:22	+/–
>ужос,кто то проверяет их перед размещением?? Человек показал работающий вариат обхода проблемы. Что то я не увидел, чтобы хоть один из комментаторов кроме пустой критики показал свой вариант решения. Я свое время тоже MTU на интерефейсе поднимал экспериментальным путем и все начинало работать.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #4 Ответы: #13

13. Сообщение от vitek (??), 10-Дек-08, 09:54	+1 +/–
чуть выше же уже намекнули! 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. This target is used to overcome criminally braindead ISPs or servers which block ICMP Fragmentation Needed packets. The symptoms of this problem are that everything works fine from your Linux fire‐wall/router, but machines behind it can never exchange large packets: 1) Web browsers connect, then hang with no data received. 2) Small mail works fine, but large emails hang. 3) ssh works fine, but scp hangs after initial handshaking. Workaround: activate this option and add a rule to your firewall configuration like: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \ -j TCPMSS --clamp-mss-to-pmtu --set-mss value Explicitly set MSS option to specified value. --clamp-mss-to-pmtu Automatically clamp MSS value to (path_MTU - 40). These options are mutually exclusive.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #12

15. Сообщение от frey (ok), 10-Дек-08, 14:16	+/–
>Использую в Fedora 8 другое решение. >Взял патч из initscripts ASPLinux 12 (ту его часть, которая изменяет и >добавляет скрипты для поддержки ifup pptp0). >В ifcfg-pptp0 можно указать MTU=1460 и MRU=1460 (впн без шифрования, поэтому получается >на 40 байт меньше, чем MTU для eth0). Вы хоть сами поняли, что сказали? Если бы не было шифрования, то и мту остался тотже. В pptp используется 4 байта для шифрования (при require-mppe-128) и мту нужно ставить 1496 в таком случае.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #9

16. Сообщение от frey (ok), 10-Дек-08, 14:17	+/–
>man iptables >search "--clamp-mss-to-pmtu" Хм! Интересно!
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #2

17. Сообщение от Аноним (9), 11-Дек-08, 11:05	+/–
Прежде чем ругаться, надо разобраться. Во-первых, описанный способ решает проблему на линуксовом сервере с виндовыми клиентами, или на линуксовом клиенте? Если случай #1, тогда всё совершенно правильно, т.к. винда при поднятии VPN искренне считает, что у неё MTU 1400. Причём, обратите внимание, --clamp-mss-to-pmtu в данном случае не работает. Или работает неправильно, что, в общем, одно и то же. Я у себя ситуацию решаю набором правил: -A table -i ppp+ -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1301:1350 -j TCPMSS --set-mss 1300 -A table -i ppp+ -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1351:1400 -j TCPMSS --set-mss 1350 -A table -i ppp+ -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1401:1450 -j TCPMSS --set-mss 1400 -A table -i ppp+ -p tcp -m tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1451:65535 -j TCPMSS --set-mss 1430 Дискретность задайте сами какую вам нужно.
Ответить \| Правка \| Наверх \| Cообщить модератору
Ответы: #18, #19, #20

18. Сообщение от Аноним (9), 11-Дек-08, 11:07	+/–
Не на то ответил, sorry. >Прежде чем ругаться, надо разобраться.
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #17

19. Сообщение от port20031 (??), 11-Дек-08, 13:49	+/–
Можно вопрос в догонку ? Ситуация такая : 1)от прова инет приходит через адсл ,с него на свич ,со свича компы получают реальные ип; 2)на одном из них крутится мой сервак , на нем есть сервер впн , который нормально обслуживает компы с серой сетки и компы , подключенные со свича . Проблема в том что с инета впн типа подымается , но там ни чего не ходит . Может поможите ?
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #17

20. Сообщение от sfstudio (?), 11-Дек-08, 16:05	+/–
>на линуксовом клиенте? Если случай #1, тогда всё совершенно правильно, т.к. >винда при поднятии VPN искренне считает, что у неё MTU 1400. В случае pptp на сервере в /etc/ppp/options.pptp достаточно указать: mru mtu и не заморачиваться, тогда значения будут корректно переданы вантузу и приняты в работу. Ессно сразу заработает и --clamp-mss-to-pmtu [root@sadnet:linux]# pptp --version pptp version 1.7.2 [root@sadnet:linux]# pppd --version pppd version 2.4.5 [root@sadnet:linux]# uname -a Linux sadnet.lo 2.6.27.8 #9 Mon Dec 8 04:46:11 OMST 2008 i686 Pentium III (Coppermine) GNU/Linux
Ответить \| Правка \| Наверх \| Cообщить модератору
Родитель: #17

21. Сообщение от replicant (?), 15-Дек-08, 00:14	+/–
[root@sadnet:linux]# pppd --version pppd version 2.4.5 2.4.5 или я отстал от жизни?
Ответить \| Правка \| Наверх \| Cообщить модератору

22. Сообщение от rrv (ok), 15-Дек-08, 08:44	+/–
Это костыли! Достаточно правильно настроить mpd добавив опцию set pptp disable windowing. Читать тут http://rrv.nsk.ru/wiki/index.php/Vpn_server_%D0%BD...
Ответить \| Правка \| Наверх \| Cообщить модератору

23. Сообщение от andrek (?), 02-Сен-09, 03:55	+/–
тоже натолкнулся на теже грабли, вообщем решение простое, выставляем mtu mru в конфиге ppptp-options, и результирующее правило в iptables: $IPTABLES -A FORWARD -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 0:65535 -j TCPMSS --clamp-mss-to-pmtu -i ppp+
Ответить \| Правка \| Наверх \| Cообщить модератору

24. Сообщение от EIKA (ok), 20-Ноя-18, 20:24	+/–
Товарищи, а что можете сказать по такой теме. CentOS 7, PPTPD 2.4.5 со стандартным конфигом. Цепляюсь к демону Микротиком, туннель поднят и активен, и все в целом работает отлично, но с некоторыми сайтами нет коннекта. Методом тыка, потратив целый день, нашел проблему - нужно MRU повысить на 4 единицы или более, тогда появляется коннект с "проблемными" сайтами. Сами по себе значения MTU и MRU не критичны, можно ставить все что угодно в диапазоне 1300-1492, но главное, чтобы выполнялось правило: MRU = MTU + 4 (или более). Куда бы копнуть по это теме?
Ответить \| Правка \| Наверх \| Cообщить модератору