The OpenNET Project / Index page

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

О PPPoE, MTU и проблеме Path MTU Discovery Black Hole (pppoe mtu)


<< Предыдущая ИНДЕКС Правка src / Печать Следующая >>
Ключевые слова: pppoe, mtu,  (найти похожие документы)
From: Vyacheslav Khudyakov <slava@in4net.info.> Newsgroups: email Date: Mon, 14 Mar 2007 14:31:37 +0000 (UTC) Subject: О PPPoE, MTU и проблеме Path MTU Discovery Black Hole Предыстория Приехав как-то домой, я вдруг обнаружил что некоторые сайты с моего ноутбука перестали зугружаться. Причем, на следующий день, ноутбук был проверен на работе -- интернет работал и сайты открывались замечательно, все было доступно. Дома же -- только www.yandex.ru и www.google.com. Да и то, начиная с некоторого момента, зугружаться стал только гугл. Причем, веб-сайты отлично пинговались, до них доходил трейс и даже устанавливалось соединение с помощью telnet на 80-й порт... Теперь немного о том, как я соединен с инетом. У меня дома небольшая локальная сеть, к которой подключены по wifi ноут и стационарная машина на которой работает отец. Шлюзом выступает linux сервер, который соединен с провайдером по PPPoE. По сути, такой же способ доступа в интернет, через PPPoE, предлагают все dsl провайдеры (Стрим и пр.). Сначала я был весьма наивен. И погрешил на винду, переустановив ее с диска-реаниматора... Не помогло. Загрузился на ноуте под линукс - те же яйца, вид сбоку. При этом, что интересно, на самом шлюзе все сайты замечательнейшим образом открывались... Сама история Надо сказать, что первая же мысль после этого была - посмотреть что там с MTU. Что я и сделал, введя ifconfig на шлюзе: in4net ~ # ifconfig eth0 Link encap:Ethernet HWaddr 00:02:B3:2E:1F:86 inet addr:82.199.102.68 Bcast:82.255.255.255 Mask:255.0.0.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:10031 errors:0 dropped:0 overruns:0 frame:0 TX packets:8405 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:5729567 (5.4 Mb) TX bytes:1117640 (1.0 Mb) Interrupt:11 eth1 Link encap:Ethernet HWaddr 00:50:70:F3:05:B5 inet addr:192.168.0.99 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:20929 errors:0 dropped:0 overruns:0 frame:0 TX packets:21275 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1950816 (1.8 Mb) TX bytes:7060556 (6.7 Mb) Interrupt:12 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:3297 errors:0 dropped:0 overruns:0 frame:0 TX packets:3297 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:903591 (882.4 Kb) TX bytes:903591 (882.4 Kb) ppp0 Link encap:Point-to-Point Protocol inet addr:82.199.102.68 P-t-P:10.10.10.10 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1 RX packets:8757 errors:0 dropped:0 overruns:0 frame:0 TX packets:7813 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:5392618 (5.1 Mb) TX bytes:921409 (899.8 Kb) Как видим, ppp0 соединение имеет MTU 1492. Что по сути это означает? Проще говоря, ваше соединение с интернет имеет окно в 1492 байт (MTU - Maximim Transmission Unit) - это наибольший пакет, который ваша машина может передать по данному соединению. В тоже время, почти все веб и ftp серверы соединены с интернет с MTU 1500. Если где-нибудь на пути пакета от одного хоста к другому выяснится, что он не умещается в MTU следующего участка, то роутер будет фрагментировать данный пакет. Так произошло бы, если бы роутеры не использовали технологию Path MTU Discovery :-) . Поскольку фрагментация пакетов сильно снижает производительность роутеров, то в 1988 году была предложена технология Path MTU Discoverу (PMTUD). Она описана в RFC 1191. Суть технологии состоит в том, что когда два хоста соединяются друг с другом, то устанавливается DF бит "Dont Fragmen"), который запрещает фрагментацию пакетов на роутерах. Это заставляет роутер, который собирается перенаправить пакет через соединение с MTU меньше размера пакета, отбрасывать пакеты и отправлять хосту-отправителю сообщение типа ICMP 3:4. Данное сообщение типа "Destination is unreachable" означает "Хост недоступен, поскольку пакет слишком большой и роутер не будет его фрагментировать". В добавлении к данному сообщению, при применении PMTUD, прилагается размер MTU нижестоящего за роутером участка. Таким образом, хост-отправитель, после получения ICMP 3:4 с информацией от PMTUD, уменьшает размер отправляемого пакета и пересылает его заново. Как итог -- пакеты доходят до хоста-получателя без фрагментации. Все операционные системы с 1988 года поддерживают технологию PMTUD. Однако, проблема может быть в том, что либо вышестоящий над вашим соединением роутер, либо некий роутер между вами и удаленным сервером, либо сам удаленный веб-сервер могут БЛОКИРОВАТЬ некоторые типы ICMP пакетов, включая ICMP 3:4. В этом месте хочется передать привет параноидальным администраторам -- НЕ ДЕЛАЙТЕ ТАК, НЕ БЛОКИРУЙТЕ ICMP трафик! Как итог - соединение между хостами устанавливается, но пакеты от одного хоста к другому не доставляются, отбрасяваясь где-то по пути... Похоже на наши симптомы? Собственно проблема не нова, ее начали обсуждать еще в 1998 году. Называется она Path MTU Discovery Black Hole, и описана в RFC 2923. По сути, потенциально этой проблеме подвержено любой PPPoE соединение, поскольку его MTU меньше типового MTU в 1500 байт и, для прохождение через PPPoE, TCP/IP пакет необходимо либо фрагментировать, либо использовать PMTUD. В тоже время, если у вас обыкновенная машина с DSL модемом, вы не столкнетесь с этой проблемой, поскольку на этапе инициализации соединения с удаленными серверами размер пакета будет вычислен исходя из размера MTU PPPoE соединения. Однако, если у вас DSL роутер (например как у меня, на базе линукса), то вы в зоне риска, поскольку ваша машина, при установлении соединения с удаленными серверами, по умолчанию оперирует размером пакета исходя из MTU локальной сети, которое установлено в 1500. В тоже время, пакеты от удаленных серверов к вам проходят через канал роутера, который имеет MTU PPPoE соединения, т.е. 1492... Решение проблемы Самый простой и логичный способ - снятие фильтрации ICMP 3:4, как правило, находится вне вашей компетенции. Поэтому решить проблему можно следующим способом: автоматически уменьшать размер передаваемого пакета на вашем шлюзе, либо с помошью pppd, либо с помощью iptables. При установке TCP-соединения сервер и клиент сообщают друг другу так называемый максимальный размер сегмента (MSS), который каждый из них сможет принять (по умолчанию на 40 байт меньше mtu интерфейса -- размер заголовков ip+tcp). И далее каждый из них в рамках этого tcp-соединения посылает пакеты размером не более чем min(mss+[размер заголовков], pmtu). Мы меняем MSS, заставляя обе стороны посылать друг другу tcp-пакеты только таких размеров, которые заведомо пролезут в наш интерфейс без фрагментации. Для iptables есть и модуль снятия бита DF, в случае с ним шлюз бы фрагментировал пакеты... В случае с корректировкой MSS фрагментация просто не требуется, что является более изящным решением. Сделать это можно следующим образом. Используя pppd: добавить в /etc/ppp/pppoe.conf CLAMPMSS=1412 Используя iptables: добавить правило iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu Идентификация проблемы и поиск решения у меня занял около 6 часов, в ходе которых я анализировал пакеты с помощью tcpdump и netstat, выискивал закономерность между открывающимися \ не открывавшимися сайтами, конфигурировал ядро сервера, перестанавливал операционку на ноуте и задумывался уже над тем чтобы плюнуть и поставить просто прокси-сервер... Проблема усугублялась еще и тем, что интернет мне, фактически, был недоступен.... Хотя решение, на самом деле, очень простое. Полезные ссылки по этой теме http://www.phildev.net/mss/lisa.html http://tldp.org/HOWTO/IP-Masquerade-HOWTO/mtu-issues.html Vyacheslav Khudyakov <slava@in4net.info.>

<< Предыдущая ИНДЕКС Правка src / Печать Следующая >>

Обсуждение [ Линейный режим | Показать все | RSS ]
  • 1.1, tau (?), 15:24, 16/03/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Отличная статья для начинающих!
     
  • 1.2, scamp (??), 17:54, 16/03/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Сам с месяц назад напоролся на такую проблему. решение заняло около 3 часов. после консультации с сетевым специалистом, начал копать в сторону mtu (хотя подозрения на этот счет были сразу). поиск по конфигам shorewall (именно им пользуюсь для удобства управления iptables. рекомендую всем) привел к интересным коментариям:

    [From the kernel help:
    #
    #    This option adds a 'TCPMSS' target, which allows you 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).
    #
    #    This 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
    #    firewall/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.
    # ]

    Собственно решение превратилось в активацию в shorewall опции
    CLAMPMSS=Yes

     
     
  • 2.36, riv1329 (?), 17:20, 03/02/2012 [^] [^^] [^^^] [ответить]  
  • +/
    В 2011 году CLAMPMSS=Yes в конфиге shorewall всё еще актуален. Хотя было-бы логично включать эту опцию по умолчанию.

    Спасибо за информацию.

     

  • 1.3, _Kuzmich (??), 08:53, 19/03/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

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

     
  • 1.4, greg (??), 20:13, 27/05/2007 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    поправка :
    iptables -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
     
     
  • 2.5, omegas (ok), 10:31, 04/12/2007 [^] [^^] [^^^] [ответить]  
  • +/
    перепробовал все, ограничение мту не помогло. Решилось все красиво, вот такой строчкой в цепочке mangle: -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1300
     
     
  • 3.19, Variable (?), 14:32, 18/12/2009 [^] [^^] [^^^] [ответить]  
  • +/
    А вот этому пути лучше не следовать. Дело в том, что если у вас где-то по дороге окажется сайт, у которого MSS окажется меньше 1300 , то он его увеличит до 1300 и у вас могут возникнуть проблемы с фрагментацией пакетов!
     

  • 1.6, DemoN (??), 16:57, 09/03/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Была аналогичная проблема с L2TP содинением. Исходищее соединение L2TP с MTU 1460 (от Корбины), внутренная квартирная сеть на Ethernet... Долго понять не мог почему часть сайтов работает, а часть нет...
    После длительного установления проблемы, пришел к решению с iptables...
     
     
  • 2.48, Anton (??), 21:13, 03/03/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Та же фигня была недавно... Спасибо автору!
     

  • 1.7, ciwl (??), 02:24, 03/04/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    respect! 3-й день ломаю голову... уже тож хотел проксик ставить =)
     
  • 1.8, Аноним (-), 11:26, 12/05/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Стать класс
    Уже вообще хотел от Linux отказаться т.к. прокси не подходил
     
  • 1.9, Ламо (?), 02:12, 08/11/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Век живи, век учись...
    Моя ситуация - Ноутбук+обычный ПК подключены к D-Link DSL-2640U, ноут по ВайФай.
    На ноуте одноклассники.ру работают, на компе нет, причем на компе явные тормоза при работе в нете - половина сайтов не открывается... Я уж и антивиром прогнал комп, и переустанавливать задумал, но... засада в МТУ. Причем, где-то на Microsoft.com прочитал, что изначальное значение MTU определяется драйверами для сетевой карты. Ессно, я посмотрел в реестре на буке (знач. 1300) и на ПК (1500). На ПК поставил 1300 и все заработало...
    Такие вот пироги
     
  • 1.10, merax (??), 18:50, 30/11/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Аналогично была проблема с Cisco 2651 c модулем ADSL. Что самое интересное mail.ru открывался, а вот r.mail.ru посылал в null. Решил проблему вот так -
      
    ip tcp adjust-mss 1452
    ip policy route-map clear-df
     
  • 1.11, Борис (??), 00:35, 20/12/2008 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Та же самая проблема, провод от корбины с MTU 1460 попадает на сервер Windows 2000, который через вторую сетевуху раздает инет на клиенты. На серваке стоит RRAS. Инет с клиентов без ручной переустановки MTU не работает (((
     
  • 1.12, Penguin (?), 11:24, 17/04/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Подниму своим спасибом, напоролся при раздаче Йоты на мелкий офис. Помогло :-)
     
  • 1.13, Bill Routers (??), 01:59, 02/06/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Перешел  с Ubu на Deb, а он не выставил при настройке ppp0 mtu, искал часов 5 думал с ума сойду,
    на ядре 2.6.24 работает на 2.6.26 нет, при этом конечно, как указано в статье, локальный комп. в Internet нормально ходит, а остальные через NAT фиг.
     
  • 1.14, YuSt (?), 17:51, 04/09/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Действительно спасибо!, нарвался на "умников", которые закрыли ICMP 3:4, думал мозгами двинусь, пока искал проблему... Самое смешное, что эти "товарищи" - админы банка, у них видете-ли политика безопасности такая ;)
     
     
  • 2.21, Greg (??), 09:36, 13/04/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Самое смешное, что эти "товарищи" - админы банка, у них видете-ли
    > политика безопасности такая ;)

    Гы... верняк, только что столкнулся именно с такой ситуацией.
    Банк-клиент не хотел работать через ppp туннель, потому что банковский хост не блочит icmp.


      

     

  • 1.15, lioxa (?), 18:20, 10/09/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Spasibo dobrij chelovek!
     
  • 1.16, Вася (??), 02:27, 05/10/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Очень полезная статья! Автору огромнейшее спасибо! Все мои проблемы с настройкой шлюза сразу решились!
     
  • 1.18, TITO (?), 18:25, 28/10/2009 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Спасибо огромное добрый человек, очень выручил, здоровья те и удачи)
     
  • 1.20, Анатолий (??), 13:56, 31/03/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Автору огромный респект, я тоже столкнулся с такими клоунами (mtu 1490), почтовики через pop3 получали список писем а сами письма нет, соединение вешалось. С самого шлюза все работало нормально
     
     
  • 2.26, Andrew.D.Mashkov (?), 15:40, 10/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Та же проблема, не бегает pop3 хоть убей, все остальное - номрально. Добавление строки к сожалению проблемы не решили. Все равно конект есть, письма не забираются.
    Может подскажете куда еще копнуть?
     

  • 1.22, Iv (??), 12:19, 08/05/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Автор - мегачеловек! Огромнейшее спасибо! Я бился с клиент-банком 2 дня. После общения с серваком по телнету понял что копать надо в сторону МTU. И тут такой подарок!
     
  • 1.23, Андрей (??), 16:30, 04/08/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Всё это хорошо, только вот проблема. Почему -j TCPMSS --clamp-mss-to-pmtu высчитывает MSS как MTU-40 (т.е.20-IP, 20-TCP)? Проснифил. У меня на Windows 7 TCP заголовки сплошь и рядом идут более 20 байт. Доходит до 56! Соответственно эти пакеты не проходят и дропаются. Все MSS уменьшать до мин.значения с учётом TCP-56 - равносильно уменьшению скорости для пакетов с размером TCP-20. Почему в iptables нету автоматической определялки MSS?!
     
     
  • 2.25, Андрей (??), 09:06, 24/09/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Потом уже разобрался. Заголовок TCP+IP более 40 байт только во время установления TCP сессии. В это время пакеты небольшие и не достигают MTU в любом случае. А вот во время передачи, когда пакеты большие, заголовок равен ровно 40 байт.
     

  • 1.24, Сергей (??), 17:30, 23/09/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Всё это замечательно. Спасибо огромное за статью. В инете вообще мало информации о MTU.
    Но есть вопрос такого плана - а что, в обычных пакетах с HTTP нагрузкой (хотя не важно что там внутри, может быть и FTP или что-то ещё) всегда устанавливается бит DF? И если да, то зачем?

     
  • 1.27, Олег Рева (?), 16:16, 23/12/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А вот за это спасибо!!

    iptables -I OUTPUT 1 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

    iptables -I FORWARD 1 -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

    Реально помогло.

     
  • 1.28, OEM_щука (?), 23:12, 24/05/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А теперь для Микротика:

    в профайле выбирает no в пункте change mss, и далее выполняем в терминале эту строку:

    / ip firewall mangle add chain=forward protocol=tcp tcp-flags=syn tcp-mss=1453-65535 action=change-mss new-mss=1360  disabled=no

     
     
  • 2.51, Евгений (??), 00:43, 08/01/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Помогло ))
    RouterOS V6.45.1
    Благодарю ))
     

  • 1.29, Alex (??), 16:12, 02/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Сделал как тут написано через iptables
    пипец, раньше сайты грузились 5 минут, теперь вабще не грузятся, пишет чото там про DNS

    чо делать?

     
  • 1.30, Alex (??), 16:16, 02/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    причему чтобы команды подействовали нужен префикс sudo

    у меня убунту стоит на wmware в винде сайты грузятся, а в убунту нет
    причем раньше грузились но по 2-3 минуты, после вашего способа ваще не грузятся пишет:

    Веб страница не доступна
    проверьте DNS бла бла бла бла бла и тд

     
     
  • 2.31, Андрей (??), 16:32, 02/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > причему чтобы команды подействовали нужен префикс sudo
    > у меня убунту стоит на wmware в винде сайты грузятся, а в
    > убунту нет
    > причем раньше грузились но по 2-3 минуты, после вашего способа ваще не
    > грузятся пишет:
    > Веб страница не доступна
    > проверьте DNS бла бла бла бла бла и тд

    От этой команды не может перестать грузиться:)

     
     
  • 3.32, Alex (??), 16:47, 02/09/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Тем не менее факт остается фактом =)
    проблема в том что я даже (как одно из решений) днс сервера задать не могу, потому что мой провайдер их не говорит, в справочники пользователя для всех ОСей пунктик стоит определять dns автоматически =) я хз чо делать
     

  • 1.33, Alex (??), 21:42, 02/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    можно как нибудь сбросить iptables ???????
     
  • 1.34, Alex (??), 11:56, 04/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Ухахаха

    смотрели видео один день админа? когда он просил ламера перегрузиться 3 раза?)

    Так вот пока писал эту команду ребутился раза 2 инет так и не заработал! забил вот наследующий день загрузил убунту все летает =)

    надо было просто ребутиться 3 раза ;)

     
  • 1.35, Андрей (??), 14:15, 15/09/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Включите реакцию на ICMP и не парьтесь.
    По секрету - ICMP бывает с полезным payload'ом. В частности, получатель может попросить уменьшить размер пакета.
     
  • 1.37, wolf10 (?), 19:03, 19/08/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Большой поклон автору :) Второй день мучаюсь почему rutracker.org не может открыться. Решил проблему с iptables -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
     
     
  • 2.38, funditus (?), 09:02, 22/08/2012 [^] [^^] [^^^] [ответить]  
  • +/
    > Большой поклон автору :) Второй день мучаюсь почему rutracker.org не может открыться.
    > Решил проблему с iptables -A FORWARD -p tcp -m tcp --tcp-flags
    > SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

    Правильней было бы:
    iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

    Именно в таблице mangle. См. man iptables.

     

  • 1.39, Ivan Drago (?), 06:18, 02/09/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    У меня такая ситуация.
    Провайдер NetByNet, протокол PPPoE.
    Если шнур воткнуть в комп напрямую, инет замечательно работает.
    Если через роутер Asus RX3041H (работает на линуксе), начинаются проблемы:
    - многие сайты грузятся с тормозами;
    - при попытке проиграть видео на ютубе, оно может загрузиться частично, для дальнейшей загрузки нужно передвинуть ползунок;
    - на сайте нтв.ру видео либо не проигрывается вообще, либо грузится по 1% за полчаса.
    Ставил разные значения MSS в роутере. Ничего не меняется.
    Как заставить роутер нормально работать?
     
     
  • 2.41, Nas_tradamus (ok), 10:23, 30/10/2012 [^] [^^] [^^^] [ответить]  
  • +/
    Ну у меня на dd-wrt помогло NetBynet такое:

    iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

    Таких глюков как у вас я не наблюдал, но иногда они возникали: то какой-нибудь сайт перестает открываться на одном из компов (не более минуты глюк), то еще какой прикол с ютьюбом. Главное что бесило: после ребута роутера сайты минут 5 нормально не открывались - открывалось лишь несколько, а остальные не были доступны, потом все становилось нормально. Но 99% времени все работало хорошо. Кстати, посмотрите выставлено ли значение MTU 1492 в самом подключении pppoe.

     
     
  • 3.43, Ivan Drago (?), 07:19, 02/09/2013 [^] [^^] [^^^] [ответить]  
  • +/
    (Разгребая закладки, наткнулся на сайт, где я год назад оставил сообщение.)
    Спасибо за помощь. Скорее всего, старый роутер (ASUS RX3041H) вышел из строя, поэтому работал с такими глюками. С новым роутером (ASUS RT-N66U) всё работает как надо.
    Где нужно прописывать команду "iptables..."?
     

  • 1.40, DrTiE (?), 00:09, 18/10/2012 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    У меня провайдер NetByNet модем ZTE ZXV10 W300 все настраиваю но в инет не входит. в чем проблема...
     
  • 1.42, netc (??), 12:55, 14/07/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    спасибо большое - если не сказать огромное !!!

    правило с iptables сработало

     
  • 1.44, Алексей (??), 20:39, 03/11/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    этой волшебной строчки не хватало для полноценного моста из ящика на линуксе с ppp на wlan
    вот весь мост
    echo 1 > /proc/sys/net/ipv4/ip_forward
    iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
    iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
    iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
     
     
  • 2.45, funditus (?), 08:24, 04/11/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > этой волшебной строчки не хватало для полноценного моста из ящика на линуксе
    > с ppp на wlan
    > вот весь мост
    > echo 1 > /proc/sys/net/ipv4/ip_forward
    > iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
    > iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
    > iptables -I FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

    Это не мост, а маршрутизатор, да и очень специфичный (натится на оба интерфейса).

     

  • 1.46, Vitto (?), 00:39, 12/05/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Сегодня столкнулся, чуть умом не тронулся пока искал в чем засада..

    В убунте, в /etc/ppp/ip-up.d/0clampmss лежит эта настройка такого вида:




    iptables -t mangle -o "$PPP_IFACE" --insert FORWARD 1 -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1400:65495 -j TCPMSS --clamp-mss-to-pmtu


    так вот, если луна стоит в правильной позиции и ты вдруг про эту настройку не знаешь и трешь все правила iptables перед тем, как залить свой набор правил, жди сюрпризов..

    В любом случае спасибо за статью!!!

     
  • 1.50, procsik (ok), 15:49, 09/12/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Если сам шлюз инициирует соединение, то пакет не пройдёт через FORWARD, поэтому лучше записать это на выходе в POSTROUTING (например, для интерфейса ppp0):

    iptables -t mangle -A POSTROUTING -p tcp --tcp-flags SYN,RST SYN -o ppp0 -j TCPMSS --clamp-mss-to-pmtu

    И нужно учесть то, что по-умолчанию pppd через pppoeconf ставить mtu:1492. Придётся замерить с другого шлюза реальный MTU:

    ping -M do <ipaddr> -s <MTU>, где MTU это значение с учётом ICMP. Например, если 1452 проходит, то в конфиг pppoe нужно записать 1452+28, т.е. 1480. Тогда --clamp-mss-to-pmtu сам будет выставлять 1480-20-20, т.е. 1440 Что является правильным.

     

    игнорирование участников | лог модерирования

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




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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