Коллеги, добрый день
Долгое время у нас был шлюз на FreeBSD 7.
Недавно железо заглючило, пришлось его менять. Заодно поменял систему на FreeBSD 10.1
Из служб стоят:
PF, dhcprelya, named, ftpproxy, ntpd, zabbix_agent
Примерно месяц назад появились разрывы связи, причем только в утреннее время, когда нет нагрузки. Интернет сайты открываются, но постоянно отваливается ICQ и Банк клиенты у пользователей.
Помогает перезагрузка шлюза - но ИМХО это не выход.
Дайте совет куда посмотреть?
Ядро я пересобирал с теми же параметрами что и на предыдущем сервере. Служб новых не добавилось. Конфиги тоже старые.
На вопрос, почему не оставил 7-ку? Она не поддерживается больше. Хочется быть в тренде
Сергей:
1. ну это когда маршрутизация идет через локальный интерфейс образуя петлю
2. еще эффект сетевого шторма появляется, если патчкорд петлей воткнуть в сетевой свич(коммутатор) двумя концами...
xmoonlight: Ну с пачкордами все норм. Я даже для проверки всего один оставил, так что петля исключена.
А вот на счет локальной петли, как определить? Куда посмотреть?
tcpdump на lo0 ничего криминального не показывает.
xmoonlight: Кажется, я понял о чем вы. Но боюсь, это не мой случай.
Проблема только с ICQ и банк клиентами (Вспомнил! Еще teamviewer не работал нормально). Остальные службы, SSH, почта, веб сервинг.. все работает.
И проблема плавающая. Как ни странно, она возникает примерно в 24-00 и самоустраняется в 10-00... Такая вот мистика. В cron-е ничего нет.
xmoonlight: Да вот тут проблема. Логи там километровые. Знать бы что искать.
С другой стороны, настройки все со старого сервера. Конфиг файрвола тот же. Каких-то ошибок при загрузке не заметил. В messages стандартная ругань от named и все.
xmoonlight: Беда... Шлюз я перегрузил.. обычно на пару дней этого хватает. Потом начинаются проблемы.
Ок. буду ждать багов.
Впрочем возникла шальная мысль избавиться от FreeBSD и уйти на cisco, Может так и сделаю
если проблема не постоянна а переодическая вполне может быть проблема с dns сервером, у многих провайдеров по умолнанию ставится провайдерский dns, который иногда "не очень хорошо" работает, лечится подстановкой гугловского dns сервера или аналога
Нет. ДНС отпадает. У меня 5 ДНС серверов. Они дублируют друг друга. Два внешних, три внутренних.
Провайдерские ДНС не использую, только свои и рутовые.
Причем, проблемы только с ICQ и банк клиентами. Остальные сервисы работают. Почта, вебсайты, VPN, все работает
Как раз в утреннее время нагрузка очень даже есть -- все приходят, и начинают котиков вконтактике смотреть.
У вас там заббикс -- настройте мониторинг трафика на всех интерфейсах, ошибки пакетов, количество пакетов в секунду, состояние всех интерфейсов, и смотрите результаты мониторинга -- будут ли провалы по трафику. Можно запустить пинги до нескольких внешних серверов с сохранением вывода в лог (man script) и смотреть, будут пинги в моменты реконнекта асек и клиент-банков отваливаться или нет.
"Километровые логи файрвола" -- это странно. По дефолту ни один файрвол никаких логов не ведёт вообще. Какой файрвол? Какой у него конфиг?
Тип подключения к интернету какой? Чистый ethernet, или PPTP/L2TP/PPPoE?
Да вот тут нестыковка. Люди приходят к 10-00 и позднее.
А проблемы обычно в 10-00 заканчивают. Ну или примерно в это время.
А вот бухгалтерия работает с 8-00. И вот они меня пилят. У них банк клиенты отваливаются. Методом тыка вычислил что тоже самое происходит с ICQ и так же глючит teamviewer.
На счет файрвола - у меня PF. Лог у него очень большой. Собственно я так и настраивал, чтоб писал все. Зато все что нужно потом можно из него выдернуть.
Конфиг тоже огромный. Я сам его писал, Настроен по принципу все что не разрешено - запрещено. Соответственно писал кучу разрешающих правил.
Тип подключения обычный ethernet. Два кабеля от двух провайдеров.
На счет zabbix.
Внешние серверы я постоянно мониторю. Пинги к ним не терялись. Так же работал VPN, в том числе через этот шлюз на внутренний сервер (OpenVPN)
Как и говорил, проблемы только с некоторыми сервисами( ICQ, банк клиенты teamviewer .... ) Остальные сервисы работают. Почта, вебсервер, все работает. Снаружи сайты открываются. Изнутри интернет доступен.
В общем беда какая-то узконаправленная.
Сергей: Насчёт выдёргивания информации из лога файрвола -- у вас есть IP источника, IP и порт назначения и примерное время обнаружения проблем. По-grep-айте по логу на предмет соответствующих изменений.
Также можно tcpdump в фоне повесить, задав ему один из бухгалтерских IP как source и IP асечного сервера или клиент-банковского как DST. И потом смотреть логи сессии.
Кроме того, если я правильно понимаю логи вашего named, то вот это: "client 192.168.113.177#55062 (www.google.com): error sending response: host unreachable" означает, что DNS-сервер не смог отправить ОТВЕТ клиенту по причине того, что клиент (192.168.113.177) недоступен. У вас там флаппинга по маршрутизации какого-нибудь нет, чисто случайно?
athacker: Подозреваю что траблшутингом я могу заниматься вечно. tcpdump-ом можно долго пытаться что-то выловить, но когда не знаешь что, то среди всей это кучи пакетов можно не найти нужного.
Я так понимаю.
1. Раньше все работало. Значит провайдер и все что вокруг шлюза - отметаем. Оно рабочее.
2. После перезагрузки шлюза все работает стабильно несколько дней. Значит с настройками скорее всего все ОК. Правила на файрволе нормальные.
Как вариант, может что-то в ядре? Может нужно какие-то параметры ядра поправить? Знал бы куда посмотреть, но увы знаний немного не хватает.
Попробую mbuf clusters увеличить, может поможет
На счет маршрутов, вроде все нормально. 192.168.113.0/24 - это сеть гостевого WiFi. Если честно, работа этой сети меня мало волнует. Могу совсем ее убрать, пустить через другой шлюз. Но боюсь что это не решит основной проблемы. Маршрут на нее статический, ведет на WiFi шлюз.
А как диагностировать флаппинг?
Сергей: Я не очень понимаю вашей боязни tcpdump-a :-) Если у вас есть примерное время, IP источника, IP и порт назначения -- там пакетов будет не настолько много, чтобы в них утонуть. Я сомневаюсь, что банк-клиент или аська генерит огромное количество пакетов ;-)
Тут ещё есть такой момент. То, что "раньше работало, а после переустановки системы перестало" -- это не факт. Я как-то после апгрейда Squid с 3.2 до 3.3 полтора часа сношался с отсутствием интернета. Оказалось, что пока шёл апгрейд, у провайдера упал канал, и интернет отвалился как класс. Пока я не запустил пинг на какой-то внешний сервер, я об этом не знал, и продолжал с выпученными глазами ковырять конфиги прокси :-)
А, так у вас там ещё и wi-fi. Тут всё ещё хуже. Может, ваши соседи через стенку поставили микроволновку с плохой экранировкой, и разогревают себе завтраки с утра. Микроволновка фонит и ломает вам wifi-канал.
Короче, есть предложение поставить wifi-сеть на отдельный маршрутизатор. Какой-нибудь самый простой бытовой. И посмотреть, будут косяки продолжаться, или нет.
athacker: Похоже вы меня не поняли. Я не боюсь tcpdump, просто во первых я не знаю что должен высмотреть в трафике, а трафик будет немалый. Зря вы думаете что там будет мало пакетов.
Во вторых - я вообще не уверен что проблемы в банк клиенте, или в банке, или в сети... Менялся шлюз, значит проблема с очень большой вероятность. в нем. Скорее всего в каких-либо переменных окружения, или в настройках ядра.
Провайдер нормальный - я его менял. Благо у меня два канала к разным провайдерам. И проблема осталась
На счет WiFi. Он тут вообще не причем. С WiFi нет никаких проблем. Он работает. Да и черт с ним вообще. Мне бы с разрывами разобраться.
Вы поймите правильно. Я не профан, сеть у меня очень добротная. Коммутаторы везде - Cisco. Различные подсети раскиданы по VLAN итд... итп.
Я почти уверен что если я верну старый софт на новое железо (Восстановлюсь с бэкапа старого шлюза) - все заработает. Но мне бы хотелось что-бы осталась FreeBSD 10.1
Вот и интересуюсь что можно такого в настройках ядра посмотреть. Может я недокрутил что-то...
Допускаю что может сетевая карта сбоит. Но их в сервере две. Я пробовал обе. Проблема осталась.
Пробовал внешнюю сетевую карту - проблема осталась.
Сергей: Сергей, если у вас цель подкрутить что-то в настройках ядра, то боюсь, тут никто помочь не сможет. А если есть цель всё-таки разобраться с разрывами, то стоит начать с каких-то более простых проверок.
У нас в конторе фря на generic-ядре прокачивает трафик от 800-1000 клиентов практически без какого-либо тюнинга, через NAT на базе pf. В пике трафик доходит до 1.2 гигабита. Ни в какие лимиты не упирается, и не требуется крутить никакие настройки ядра. Вы правда считаете, что у вас в корпоративной сети будут проблемы с лимитами ядра или сетевой подсистемы?
Если фря упирается в какие-то лимиты, то она обычно на это жалуется в логах. Вы же утверждаете, что в логах ничего нет. Значит, вероятнее всего, ни в какие лимиты фря не упирается, и ядро тут ни при чём. Равно как и тюнинг сетевых параметров.
Я бы начал дебажить такую проблему с выноса проблемной подсети на другой роутер. Если проблема там исчезнет -- тогда можно вернуться к версии, что проблема на фре.
Что касается добротности сети... Любое оборудование может создавать проблемы. И циски и джуниперы ценой больше чем в пол-миллиона тоже иногда глючат.
Сергей: у вас случаем не PCI сетевухи? у них была проблема с переполнением стека, не помню какая модель. Еще точно такое было с Длинковским свитчем, 1ска стояла где база просто подключалась как файл на удаленной тачке, дня 3 работает потом все тормозит. Ребут спасал на 3 дня, потом повторялось. Переставил на другое место работало месяц без проблем ( грехов не было уже т.к. или ребутился раз в месяц по каким либо причинам либо просто не проявлялось). Другой свитч таких проблем там не показывал.
TCP/IP ports По умолчанию исходящие соединения инициируются с диапазона портов 49152-65535 (16 тыс.). Их можно увеличить (1024-65535):
net.inet.ip.portrange.first=1024
net.inet.ip.portrange.last=65535
Для использования портов по порядку, вместо случайной выборки (для
исключения ошибки повторного коннекта с одного порта до отработки
TIME_WAIT): net.inet.ip.portrange.randomized=0
Включаем возможность не создания состояния TIME_WAIT для соединений в рамках localhost: net.inet.tcp.nolocaltimewait=1
pr0l: Нет, сетевые карты встроенные в материнку "Intel(R) PRO/1000 Network Connection".
Кстати проблем не было уже неделю.
Я отключил все лишнее, в том числе zabbix agent. Подозреваю что проблема была именно в нем.
Если еще неделю проблем не будет, то попробую разобраться какая проверка давала сбой.
