Andrey Lyubimets пишет:
В общем-то речь про очередной косяк ppp :) - с которым многие мучаются и
когда заходит речь про "очередной косяк ррр" - в первую очередь ищите
кривые руки.
Ну возможно, значит я не совсем правильно понял суть проблемы. Факт в
том, что почему-то при использовании CISCO as5350
подобной вещи не наблюдалось (не знаю уж как они это обходят) а при
настройке VPN сервера на Linux получил такую проблему.
ответы я нашел только в какой-то из буржуйских рассылок.
(Хотя сейчас еще раз поискал зная уже нужные слова и нашел во многих
других местах, но тем не менее решил запостить сие письмо сюда -
может кому пригодится.)
Path MTU Discovery Black Hole
проблеме этой уже 10 лет -- http://www.znep.com/~marcs/mtu/
по русски об этом тоже не раз писали, например --
http://www.opennet.ru/base/net/pppoe_mtu.txt.html
Да, да, да.... и я на русском прочитал когда задал поиск по словам linux
mtu mss clamp но когда "не работает" не сразу подберешь
нужные слова для поиска.
В общем если на Debian etch 4.0 сделаете vpn сервер, то выяснится что
некоторые сайты при подключении по такому соединению не
открываются в принципе из-за маленького размера MTU/MRU и
соответственно попыткой фрагментировать пакеты. Однако некоторые
сайты отдают пакеты с флагом dont fragment (ну например yandex) и эта
фрагментация обламывается..... в результате расследования выяснилось
было бы неплохо расследовать кто режет icmp пакеты - вы сами или ваш
провайдер?
Насколько я понимаю icmp пакеты могут резаться на всем пути до например
того-же яндекса и не только его, как вариант - на это может влиять NAT и
выяснять кто что где режет - дело неблагодарное. Так что лучше костыль,
с ним пока особых проблем не вижу.
что какой-бы MRU/MTU не выставляли в конфиге - pppd договаривается с
виндовыми машинами (Linux не пробовал тогда) на меньший размер
(не помню на вскидку какой) и первым моим решением было добавить в
/etc/ppp/ip-up.d скрипт которы с помощью ifconfig изменял-бы MTU/MRU
на уже поднятом ppp интерфейсе. Это помогло но было в принципе криво,
дальнейшие раскопки привели к вот такому решению:
это тоже криво - проблема на уровне IP, а решение на TCP, но
на безрыбье и рак- рыба, если нет возможности настучать по башке
наглухо закрывшему icmp админу.
Насколько я понял из той ссылки что указали Вы - проблема в том что
участок pptp имеет самый маленький MTU а протокол TCP при
инициации соединения (ну или при увеличения окна) не узнает об этом -
соответственно пересылая большие фреймы которые не проходят
через pptp соединение, или я не так понял?.
Олег.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
