LINUX.ORG.RU
ФорумAdmin

Не открываются страницы через PPTP

 ,


0

2

Есть два провайдера. Компьютер-шлюз автоматически перекидывающий с основного провайдера на резервный в случае аварии у основного. Резервный провайдер предоставляет услугу через PPTP. Аварии у основного случаются крайне редко. Но во время последней выяснилось, что хоть PPTP и поднимается (пинги до интернетов исправно идут, причем трассировка показывает, что пакеты идут исправно через сервер PPTP провайдера) а страницы не открываются. Так-как доступна только консоль, проверялось через консольный браузер links. MTU на интерфейсе ppp0 1400. При этом всем на Win2003 PPTP поднимается исправно - странички грузятся. Куда копать? PS раньше работало, смс оповещение на телефон приходило через второго провайдера, сейчас только через основного приходят смс-ки, мол восстановился основной канал.

MTU

Сюда и копать, видимо. Наверное, как и с PPPoE, проблема в районе MTU Discovery.

AS ★★★★★ ()
Ответ на: комментарий от rabiddios

Ваш файервол ICMP не режет? А то зачастую дело не в том, что pmtu «не работает», а в том, что оно работать не может и начинают натуральное шаманство без понимания причины :)

vodz ★★★★★ ()
Ответ на: комментарий от rabiddios

«1400 выставлено» - это не «MTU Discovery работает»... Но особенностей PPtP я не знаю. Попробуй погуглить про «iptables -j TCPMSS --clamp-mss-to-pmtu». Ставиться правило может в разных местах netfilter.

AS ★★★★★ ()
Ответ на: комментарий от AS

«1400 выставлено» - это не «MTU Discovery работает»

Вот и ожидаемое шаманство... Если нет чёрных дыр = обрезание ICMP FRAG_NEEDED, то ручное изменение TCPMSS не нужно, если mtu выставлено верно.

vodz ★★★★★ ()
Последнее исправление: vodz (всего исправлений: 1)
Ответ на: комментарий от AS

топорное iptables --append FORWARD --protocol tcp --tcp-flags SYN,RST SYN --jump TCPMSS --clamp-mss-to-pmtu не принесло результата... PS я чайник)))

rabiddios ()
Ответ на: комментарий от vodz

Вот и ожидаемое шаманство...

Увы, это не шаманство, а вполне рабочий инструмент в современной реальности...

AS ★★★★★ ()
Ответ на: комментарий от AS

Увы, это шаманство, ибо понимания сути вы не продемонстрировали. ТС в первом сообщении указал, что дыры с MTU у провайдера нет.

vodz ★★★★★ ()

пинги до интернетов исправно идут, а страницы не открываются

Кстати, не открываются со шлюза именно, или изнутри сети ? И пинги тоже откуда ? А размер icmp echo пробовал увеличивать ? Со шлюза, по идее, всё должно работать, если проблема в районе MTU, а вот на рабочих станциях за ним - нет.

AS ★★★★★ ()
Ответ на: комментарий от vodz

ТС в первом сообщении указал, что дыры с MTU у провайдера нет.

В каком месте ? Это раз. Почему именно провайдер ? Это два.

AS ★★★★★ ()
Последнее исправление: AS (всего исправлений: 1)
Ответ на: комментарий от AS

В каком месте ?

В таком, что он меняет ОС и всё работает.

Почему именно провайдер ?

Потому что a) он сервер pptp и первый интерфейс с mtu < 1500 появляется у него и б) ТС божится, что icmp не режет и в) см «'это раз».

vodz ★★★★★ ()
Ответ на: комментарий от vodz

В таком, что он меняет ОС и всё работает.

:-)

Для этого надо знать, что именно делает эта ОС с PPP. А делает она именно это самое. Сама. И лет 15 (это не только 2003, но и более ранних Win касается) назад про это копья ломали, FAQ-и писали.

AS ★★★★★ ()
Ответ на: комментарий от AS

Сначала была замечена проблема на пользовательских компах. (Типа отвалился основной провайдер). Изначально трассировалось с них, но опосля родилась мысль «роди интернет на шлюзе - его пользователям раздать будет просто»

Проверялось консольным браузером links. Естественно, что с основного провайдера links отрабатывает корректно. Приводимые здесь листинги - со шлюза. Сферически в вакууме - комп с debian на борту не получает инет через PPTP.

rabiddios ()
Ответ на: комментарий от AS

Виндоза первая научилась pmtu, но это в обратную сторону, когда на удалённой стороне либо по пути идёт уменьшение mtu. clamp-mss виндоза не делает по умолчанию и сейчас, так как заставить её быть шлюзом инет через ptp интерфейсы надо сильно постараться.

vodz ★★★★★ ()
Ответ на: комментарий от vodz

я за последние 5 минут столько умных слов прочитал..... это жутко интересно, но по моей проблеме мысли будут? я же деревянный..... про mtu подумал и в /etc/ppp/peers/Prov исправил значение mtu c 1476 на 1400..... до обращения к специалистам (как обезьяна с очками, ей богу.... смысл девайса понятен, а вот инструкции нету)

rabiddios ()
Ответ на: комментарий от rabiddios

но по моей проблеме мысли будут?

Так вы же информации недаёте, а только плачетесь, что не работает. ЧТО не работает? Вы тесты с ping-гом с размерами пакетов и pmtu проводили? Анализатор пакетов запускали? На «не работает» можно ответить только одно — УМВР.

vodz ★★★★★ ()
Ответ на: комментарий от vodz

я проводил тест даже на наличие нечистой силы в офисе))) (в результаты последнего не очень верится) Если серьезно, подскажите как это делается правильно, какая инфа нужна? Повторюсь, я деревянный.... Но быстро учусь)))

rabiddios ()
Ответ на: комментарий от rabiddios

Пока оба канала работают у вас идеальное время на проведение тестов. Запускаете на машинах, подключенных на разных каналах анализатор пакетов, смотрите, что уходит, что приходит, ping-ом, пробуйте странички с разным размером, сделайте простейший http сервер, например netcat-ом с разным размером вывода, от 1000 до 1500 байт и смотрите. Сравнивайте с виндозой. У вас же может что угодно, вплоть до отсутствия поднятия default gw :)

vodz ★★★★★ ()
Ответ на: комментарий от rabiddios

Что нужно сделать? (rm -rf - волосато)

Вариантов вагон. Как и причин проблемы. Сделай, что я написал, для начала, и отчитайся. То есть, попингай пакетами разного размера со шлюза и с компьютера за ним. Допустим, от 1000 байт до 1500, с шагом 100. На самом деле, интересно граничное значение, когда проходит, и когда нет. При этом надо точно знать, что целевой хост не имеет ограничения по icmp echo. Можно проверить с рабочего канала, например.

AS ★★★★★ ()
Последнее исправление: AS (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.