--}}
Новая тема
Вы не можете создавать новые темы.
Т.к. вы неавторизованы на сайте. Пожалуйста назовите себя или зарегистрируйтесь.
Список тем

Почему могут пропадать входящие пакеты в сети, а транзитные нет?

33
23
С друзьями на NN.RU
В социальных сетях
Поделиться
Labutin
07.12.2006
Ситуация следующая. В локалке стоит сервер под Fedora Core 5, который является шлюзом в инет (маскарадинг). На этом сервере крутится сайт. Пользователи ИЗ ЛОКАЛКИ жалуются, что сайт часто недоступен (Connection timeout). При этом сервер пингуется и, что самое важное, внешний интернет работает нормально!!! Я сначала грешил на Apache. Но похоже он не виноват.
Я запустил tcpdump на внутреннем интерфейсе собирать статистику с 80-го порта. И был сильно удивлен тем, что когда пользователи видят Connection timeout, то на сервер действительно не поступали пакеты на 80-й порт! Т.е. инет через сервер работает (пакеты не теряются), а вот на сам сервер запросы иногда не доходят :( Пробовал запускать Apache на 88-м порту. Картина точно такая же. После нескольких попыток сайт все-таки открывается. Проблемы возникают почти у каждого пользователя 3-4 раза в день.
Ума не приложу где грабли :( Может быть есть идеи, что можно посмотреть?
Надо бы глянуть сниффером, что при этом происходит на стороне клиента, ИМХО. Куда его пакеты улетают и улетают ли вообще. Вообще то тут куча вариантов - от глюков dns, если доступ по имени и защиты от synflood-а до кабеля/железа...
В iptables можно еще логирование настроить и selinux выключить, если он еще не того...
Labutin
07.12.2006
Да, на стороне клиента действительно неплохо посниферить. Я попробую это организовать. Что посоветуешь в качестве софта?
Обращение именно по IP-адресу http://192.168.0.254 маска подсети 255.255.255.0
selinux - выключен.
Попробую еще логи в iptables организовать.
Хрю.
07.12.2006
Labutin писал(а)
Да, на стороне клиента действительно неплохо посниферить. Я попробую это организовать. Что посоветуешь в качестве софта?

CommView.
Wireshark (Ethereal)
nnstepan
08.12.2006
А правило НАТа как выглядит?
Labutin
08.12.2006
-A POSTROUTING -j MASQUERADE
rh9
08.12.2006
echo "Allow 'loopback interface'"
/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A OUTPUT -o lo -j ACCEPT

не забыл?
Labutin
08.12.2006
OUTPUT по умолчанию на ACCEPT
-A INPUT -i lo -j ACCEPT конечно имеется
rh9
08.12.2006
выложи все правила iptables
+1. может там какой connlimit нарисовался.
nnstepan
09.12.2006
А надо
iptables -t nat -A POSTROUTING -o $INET_IF -j MASQUERADE
или
iptables -t nat -A POSTROUTING -o $INET_IF -j SNAT --to-source $INET_IP
где INET_IF - имя внещнего интерфейса
а INET_IP его АйПи адрес
я конечно написал бы + 1. т.к. указание таблицы nat и интерфейса весьма полезно. Но ИМХО результат у автора должен получаться нормальным и с таким правилом, потому что действие MASQUERADE применяется только в этой таблице и только для этой цепочки. Если маршрутизация работает по человечески (т.е. роутер знает что локальные ресурсы - это здесь, а внешний инет- там), то проблем быть не должно.

В примеру его правило сработает так при локальном обращении к web-серверу ( http://192.168.0.254:80 )
http://192.168.0.30 ---> [ http://192.168.0.254 -> http://127.0.0.1 ] ---> http://127.0.0.1
и наоборот преобразует аналогично. В кач-ве интерфейса и его ip в обоих случаях должна выбираться ЛАН-сетевуха и ее ip.. если маршрутизация в норме (повторюсь). Вот если она косячит, тогда по идее надо указать параметр -o.

Запрос к внешнему web-серверу:
http://192.168.0.30 ---> [ http://192.168.0.254 -> http://212.92.130.254 ] ---> http://81.176.76.101
и наоборот тоже самое.

Вообще в такой ситуации неплохо бы помониторить логами и счетчиками iptables входящие из локалки прибегающие на внутренний интерфейс syn-пакеты и убегающие syn/ack. И в это же время засечь исходящие syn-пакеты на юзерской тачке. Тогда можно уже определить куда дальше копать. Как вариант - глюки вообще железные.. делов -то: всего одну пару в кабеле не по стандарту обжать и глюки появляются неописуемые.
Labutin
09.12.2006
Судя по всему оказался виноват промежуточный свич :( В организации сетка состоит из многих сегментов и выяснилось, что в одном из них проблем не было. Перенесли сервер в другое место и пока вроде проблема пропала.
Параметр -o в маскарадинге действительно будет не лишним. Хотя и без него все нормально работало :)
Поздравляю с находением причины проблемы. Лишний раз убеждаюсь, что решение всех сетевых проблем лучше начинать с нижних уровней модели OSI и постепенно подниматься выше.

<off> Недавно тоже наблюдал необъяснимые глюки с "ненахожением объектов групповой политики" в логах винды и общими дикими тормозами сети. Часа полтора пытался понять, что с AD такое твориться... оказалось просто кабель (от свича до кросс-панели) криво обжат был. pathping показал, что выпадает от 6 до 17 % пакетов в среднем. Рекомендую взять тулзу на вооружение. </off>
Warwar
08.12.2006
сколько народу-то в сети? во внутренней?.. как настроен апач? MinSpareServers, MaxSpareServers, MaxClients... короче, прощще сюда приаттачить конфиг аппача
настроен как standalone или через inetd?..
короче, вопросов больше чем советов...
AlexKB
08.12.2006
У меня такое было при использовании ipchains, когда был разрешен доступ снаружи не не весь диапазон локальных портов, используемых для маскарадинга (у мена на rh9 это 61001-65535). Получалось, что если ядро выбирало случаынйм образом запрещенный порт - соединение tcp не устанавливалось.
Labutin
08.12.2006
Не совсем понял :( Можно подробней и с решением проблемы? :)
AlexKB
08.12.2006
Суть в том, что когда изнутри кто-то выходит через маскарадинг "наружу", то на внешнем IP открывается порт, через который перенаправляется tcp-поток. По умолчанию в линуксе, это порт из диапазона "за локальными портами". Локальные порты указаны в /proc/sys/net/ipv4/ip_local_port_range. У меня там "32768 61000". Соответственно, маскарадинг использует порты начиная с 61001. Для нормальной работы, к этим портам должен быть доступ с "внешней" сети (в том числе и с самого этого же внешнего ip-адреса). Примерно так
ipchains -A input -p tcp -d 82.208.x.y 61001:65535 -j ACCEPT

У iptables свои особенности, не очень хорошо их знаю..
Stinky
08.12.2006
Эээээ... netfilter до сих пор вроде был stateful, т.е. если соединение установилось, то отдельно открывать порты уже не трэба. А вообще '-m state --state ESTABLISHED,RELATED'
Хуже другое - соединения ну устанавливаются из локалки на сервер на вполне конкретный порт.
AlexKB
08.12.2006
Проверено - не работает без открытых высоких портов. Напоминаю, у меня ipchains, а не iptables..
Stinky
08.12.2006
Блин, действительно, про чейны так и написано, что stateless...
nnstepan
09.12.2006
Если это Iptables то такого уже не надо, он keep state. Т.е. запоминает состояния. И здесь вместо портов используются понятия Эстаблишед и Релейтед, как правильно написал Стинки.
Новая тема
Вы не можете создавать новые темы.
Т.к. вы неавторизованы на сайте. Пожалуйста назовите себя или зарегистрируйтесь.
Список тем
Последние темы форумов
Форум Тема (Автор) Последний ответ Ответов
Сетевой фильтр APC Surge Arrest

Сетевой фильтр APC Surge Arrest для радиолюбителя.и не только Отправка в регионы после оплаты. ЦЕНА 3000 руб. В рабочем состоянии....
Цена: 3 000 руб.

Материнские платы на запчасти и не только

Материнские платы на запчасти и не только Материнские платы и другие комплектующие Отправка в регионы после оплаты. Транспортной...
Цена: 3 000 руб.

Оперативная память Corsair XMS3 CMX8GX3M2A1600C9

Оперативная память Corsair XMS3 CMX8GX3M2A1600C9 Отправка в регионы после оплаты. Продаются сразу обе. Цена за обе 2000 руб....
Цена: 1 000 руб.

Принтер лазерный HEWLETT PACKARD HP-6L

Принтер лазерный HEWLETT PACKARD HP-6L Отправка в регионы после оплаты. 3штуки БУ. Внешний вид из магазина простояли на складе...
Цена: 4 500 руб.