The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги | ]

Автоматическое изменение MTU при поднятии VPN соединения
Столкнулся с такой проблемой, что при поднятии 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 в нужное значение. Если есть какие либо идеи, 
не поленитесь, поделитесь :)
 
09.12.2008 , Автор: HolyGun
Ключи: pptp, tunnel, mtu / Лицензия: CC-BY
Раздел:    Корень / Администратору / Сетевая подсистема, маршрутизация / Туннелинг, VPN, VLAN

Обсуждение [ Линейный режим | Показать все | RSS ]
 
  • 1.1, tamerlan311 (?), 22:45, 09/12/2008 [ответить] [показать ветку] [···]    [к модератору]
  • +/
    Это можно прочитать примерно следующим образом:

    Я заметил что перестал пролезать в двери, чтобы исправить ситуацию я немного потолстел. Теперь пролезаю без всяких проблем.

    Уберите пожалуйста ваш говносовет, почините бубен и почитайте что-нибудь про MTU.
    1400 > 1396

     
     
  • 2.7, Руслан (?), 02:06, 10/12/2008 [^] [ответить]    [к модератору]
  • +/
    Кстати, дайте что-нибудь про MTU прочитать.
     
  • 1.2, slavon_net (?), 23:06, 09/12/2008 [ответить] [показать ветку] [···]    [к модератору]
  • +/
    man iptables
    search "--clamp-mss-to-pmtu"
     
     
  • 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" завести следовало бы. :)

     
  • 1.4, max (??), 01:29, 10/12/2008 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    ужос,кто то проверяет их перед размещением??
     
     
  • 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 ту ег... весь текст скрыт [показать]
     
     
  • 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 [ответить] [показать ветку] [···]     [к модератору]  
  • +/
    Прежде чем ругаться, надо разобраться Во-первых, описанный способ решает пробле... весь текст скрыт [показать]
     
     
  • 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.21, replicant (?), 00:14, 15/12/2008 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    [root@sadnet:linux]# pppd --version
    pppd version 2.4.5

    2.4.5 или я отстал от жизни?

     
  • 1.22, rrv (ok), 08:44, 15/12/2008 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Это костыли! Достаточно правильно настроить mpd добавив опцию set pptp disable windowing.
    Читать тут http://rrv.nsk.ru/wiki/index.php/Vpn_server_%D0%BD%D0%B0_
     
  • 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+
     

    Ваш комментарий
    Имя:         
    E-Mail:      
    Заголовок:
    Текст:



      Закладки на сайте
      Проследить за страницей
    Created 1996-2018 by Maxim Chirkov  
    ДобавитьПоддержатьВебмастеруГИД  
    Hosting by Ihor