| 1.1, tamerlan311 (?), 22:45, 09/12/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Это можно прочитать примерно следующим образом:
Я заметил что перестал пролезать в двери, чтобы исправить ситуацию я немного потолстел. Теперь пролезаю без всяких проблем.
Уберите пожалуйста ваш говносовет, почините бубен и почитайте что-нибудь про MTU.
1400 > 1396
| | |
| |
| 2.16, frey (ok), 14:17, 10/12/2008 [^] [^^] [^^^] [ответить]
| +/– |
>man iptables
>search "--clamp-mss-to-pmtu"
Хм! Интересно!
| | |
|
| 1.3, vadiml (?), 23:16, 09/12/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
А почему именно на 1400?
Cтандартное значение == 1500, для многих adsl, vpn надо 1492.
Но если Вы не обрезаете у себя icmp, то сетевые сами договорятся о нужном значении MTU.
PS у меня pptp MTU не меняет на для ppp0, ни для 5 других интерфейсов на моей машине (lo, eth0, eth1, vmnet1, vmnet8) и он вообще его менять не должен если специально не указано, тем более у других соединений.
PPS предлагаю завести key -- "вредные советы".
| | |
| |
| 2.5, Руслан (?), 01:55, 10/12/2008 [^] [^^] [^^^] [ответить]
| +/– |
Удалять не надо.
Ведь до этого решения кто-то дошел своим умом. И ему помогло.
А "вредные советы" или "AS IS" завести следовало бы. :)
| | |
|
| |
| 2.12, Антон (??), 09:22, 10/12/2008 [^] [^^] [^^^] [ответить]
| +/– | |
>ужос,кто то проверяет их перед размещением??
Человек показал работающий вариат обхода проблемы. Что то я не увидел, чтобы хоть один из комментаторов кроме пустой критики показал свой вариант решения. Я свое время тоже MTU на интерефейсе поднимал экспериментальным путем и все начинало работать.
| | |
| |
| 3.13, vitek (??), 09:54, 10/12/2008 [^] [^^] [^^^] [ответить]
| +/– | |
чуть выше же уже намекнули!
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.
| | |
|
|
| 1.6, Руслан (?), 02:03, 10/12/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
У меня есть мысль, что иногда вознимающая проблема на одном из подвластных мне шлюзов, имеет подобное происхождение.
Исходные данные: 1 шлюз под debian linux 2.6, 1 шлюз под FreeBSD 4.9 + ipfw.
В произвольный момент времени случается затор, в результате которого полностью перестает
а) ходить трафик между шлюзами
б) коннектиться один из шлюзов к другому
Смысла перегружать что-либо нет, хотя помогает. Смысла нет потому, что на сотню других шлюзов, общающихся с этими двумя, раз в месяц найдется еще один страдалец. И этот страдалец не будет перезагружаться ради нас, равно как и мы ради него.
| | |
| 1.8, HolyGun (?), 03:36, 10/12/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Природа появления этого совета такова.
Есть у одной организации несколько филиалов по городу. В этом городе есть городская локальная сеть. Каждый филиал подключен к этой сети. Скажем так, центральный офис также подключен к данной сети. И чтобы не покупать у провайдера, к примеру N одинаковых тарифных планов для выхода филиалов в интернет, было решено купить 1 большой ТП, и раздавать по филиалам интернет через городскую сетку. Вариант с прокси не подходил по многим причинам. Поэтому решено было запустить VPN.
Проблема образовалась почти сразу же. Не все сайты работали. Отсутствовала связь с некоторыми почтовыми серверами. Причем с шлюза в центральном офисе все работало как часы.
Опытным путем я выяснил, что нормальному прохождению пакетов мешал дефолтный MTU VPN соединения, который был установлен в 1396. А на шлюзе, у pppoe MTU:1492. Стал пробовать вручную менять у VPN соединений MTU, и о чудо! При значении 1400 все заработало.
В сроках решения проблемы руководство организации меня очень сильно ограничило, поэтому пришлось эту проблему решить именно таким способом. Времени изучать мануалы у меня небыло. Да и как-то потом отпала надобность, ибо проблема была решена.
Вопрос. А почему "ведные советы"?
| | |
| |
| 2.11, vadiml (?), 09:18, 10/12/2008 [^] [^^] [^^^] [ответить]
| +/– | |
>Вопрос. А почему "ведные советы"?
Потому что здесь описано как бороться со следствием и к тому, на мой взгляд, далеко не лучший вариант,
а надо искать причину и устранять её.
| | |
|
| 1.9, Аноним (9), 05:12, 10/12/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Использую в Fedora 8 другое решение.
Взял патч из initscripts ASPLinux 12 (ту его часть, которая изменяет и добавляет скрипты для поддержки ifup pptp0).
В ifcfg-pptp0 можно указать MTU=1460 и MRU=1460 (впн без шифрования, поэтому получается на 40 байт меньше, чем MTU для eth0).
| | |
| |
| 2.15, frey (ok), 14:16, 10/12/2008 [^] [^^] [^^^] [ответить]
| +/– |
>Использую в Fedora 8 другое решение.
>Взял патч из initscripts ASPLinux 12 (ту его часть, которая изменяет и
>добавляет скрипты для поддержки ifup pptp0).
>В ifcfg-pptp0 можно указать MTU=1460 и MRU=1460 (впн без шифрования, поэтому получается
>на 40 байт меньше, чем MTU для eth0).
Вы хоть сами поняли, что сказали? Если бы не было шифрования, то и мту остался тотже. В pptp используется 4 байта для шифрования (при require-mppe-128) и мту нужно ставить 1496 в таком случае.
| | |
|
| 1.10, suvit (?), 08:42, 10/12/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 man pppd. Есть опции mru n и mtu n.
можно для каждого vpn-канала сделать разные mru и mtu, это ставится в конфиге соединения.
| | |
| 1.17, Аноним (9), 11:05, 11/12/2008 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Прежде чем ругаться, надо разобраться.
Во-первых, описанный способ решает проблему на линуксовом сервере с виндовыми клиентами, или на линуксовом клиенте? Если случай #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
Дискретность задайте сами какую вам нужно.
| | |
| |
| 2.18, Аноним (9), 11:07, 11/12/2008 [^] [^^] [^^^] [ответить]
| +/– | |
Не на то ответил, sorry.
>Прежде чем ругаться, надо разобраться. | | |
| 2.19, port20031 (??), 13:49, 11/12/2008 [^] [^^] [^^^] [ответить]
| +/– |
 Можно вопрос в догонку ?
Ситуация такая :
1)от прова инет приходит через адсл ,с него на свич ,со свича компы получают реальные ип;
2)на одном из них крутится мой сервак , на нем есть сервер впн , который нормально обслуживает компы с серой сетки и компы , подключенные со свича .
Проблема в том что с инета впн типа подымается , но там ни чего не ходит .
Может поможите ?
| | |
| 2.20, sfstudio (?), 16:05, 11/12/2008 [^] [^^] [^^^] [ответить]
| +/– |
 >на линуксовом клиенте? Если случай #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
| | |
|
| 1.23, andrek (?), 03:55, 02/09/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
тоже натолкнулся на теже грабли, вообщем решение простое, выставляем 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+
| | |
| 1.24, EIKA (ok), 20:24, 20/11/2018 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Товарищи, а что можете сказать по такой теме. CentOS 7, PPTPD 2.4.5 со стандартным конфигом. Цепляюсь к демону Микротиком, туннель поднят и активен, и все в целом работает отлично, но с некоторыми сайтами нет коннекта. Методом тыка, потратив целый день, нашел проблему - нужно MRU повысить на 4 единицы или более, тогда появляется коннект с "проблемными" сайтами. Сами по себе значения MTU и MRU не критичны, можно ставить все что угодно в диапазоне 1300-1492, но главное, чтобы выполнялось правило: MRU = MTU + 4 (или более). Куда бы копнуть по это теме?
| | |
|