URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 79693
[ Назад ]

Исходное сообщение
"Специфичная проблема с NAT на Debian Etch"

Отправлено slant , 07-Апр-08 21:58 
Имеется очень специфическая проблема, прошу помощи хотя-бы на уровне мозгового штурма (генерация идей).
Ситуация:

Имеется маленький сервер-роутер на базе Debian Etch 4.0 r1 (на момент инсталляции), stable.
Через него к интернету, через NAT подключена домашняя сеть. Подключение – через ADSL модем D-Link 500T (в режиме моста). pppoe поднимает сервер, настройка сделана через стандартные средства Debian (pppoeconf).

Сервер прекрасно работает, если в интернет через него выходят машины на Windows. (XP и 2000). Однако, если подключить через него машину с Линуксом, и попытаться зайти на google.com брозуер задумывается, после чего показывает абсолютно белый лист. Пинги на гугль бегают.

Дополнения:
-    Проблема замечена только с google (но не гарантировано, что нету с другими сайтами – возможно не попадалась?).
-    На работе в офисе стоит практически такой-же сервер (Тот-же дебиан, тот-же ADSL, тот-же провайдер), и, подключая к нему ноутбук с линуксом (Debian) на гугль зайти можно. С этого же ноутбука здесь – не получается.
-    Не зависит от версии линукса на клиенте – пробовал грузить в vmware различные live дистрибутивы (убунту, ALT) – результат стабилен.
-     Основным броузером в тестировавшихся линуксах выступал Firefox (на ноуте - Iceweasel). Однако konqueror тоже на гугль зайти не может.
Так-же, ради теста была установлена виндовс версия фаерфокса через wine – результат тот-же, гугль не грузится.
-    МОЖНО зайти на гугль если использовать сеть TOR или просто внешний socks прокси (в faerfox).
-    Обращаю повторное внимание – виндовс-машины через этот сервер на гугль ходят совершенно без проблем.

Понимаю, что проблема крайне специфичная, и буду благодарен за любые идеи – куда стоит посмотреть, и что проанализировать.

P.S. документацию на iptables уже перерыл насколько хватает знаний, из боле-менее близких вещей, нашел только описание проблемы с MTU и MSS при работе NAT на ADSL соединениях. Однако в конфиге есть строчка которая выставляет MSS на 1400:1536 и точно такая-же строчка есть в конфиге офисного сервера.


Содержание

Сообщения в этом обсуждении
"Специфичная проблема с NAT на Debian Etch"
Отправлено KobaLTD , 08-Апр-08 11:47 
>[оверквотинг удален]
>совершенно без проблем.
>
>Понимаю, что проблема крайне специфичная, и буду благодарен за любые идеи –
>куда стоит посмотреть, и что проанализировать.
>
>P.S. документацию на iptables уже перерыл насколько хватает знаний, из боле-менее близких
>вещей, нашел только описание проблемы с MTU и MSS при работе
>NAT на ADSL соединениях. Однако в конфиге есть строчка которая выставляет
>MSS на 1400:1536 и точно такая-же строчка есть в конфиге офисного
>сервера.

мало инфы
нужно снять дампы трафика на обоих сервера когда конектишься линем (желательно одним и темже)
и на проблемном серве когда конектишься маздаем и линем (в идеале чтобы клиентом была одна и таже физическая машина)
дальше надо конфиги с обоих серверов  (pppoe, firewall)
развернутые параметры интерфейсов
таблицы маршрутизации
+ ко всему версии ПО и патчей (если накладывались)

для теста занизь MTU до 1250 + на проблемном серваке накати проксю и попробуй через нее пустить клиент?, с самого сервака как открываеться?


"Специфичная проблема с NAT на Debian Etch"
Отправлено slant , 08-Апр-08 14:28 
>развернутые параметры интерфейсов

Огромное спасибо!!! Благодаря вот этой строчке проблема оказалась решена.

Итак, весь фокус был в том, что ppp интерфейс проблемного сервера был зажат на MTU 512. Стыдно признаваться, но я не обратил на это внимания... А сейчас в процессе полной сверки всего выше предложенного, сравнил с офисным сервером - там стояло по умолчанию: MTU 1492.

По всей видимости, гугль не дает фрагментировать свои пакеты...

Путем экспериментов, выяснилось, что гугль перестает грузится, при понижении MTU до 551.

P.S. MTU зажимался для улучшения пинга к одному игровому серверу. :)