Доброго дня!
Есть ОГРОМНАЯ локальная сеть, которая через 3 железных шлюза ходит во внешний мир.
Все работает. Не жалуюсь. Но бывают моменты, что на всех (!) роутерах одновременно начинает происходить такая картина, как жалобы на следующее --
*-router kernel: ip_conntrack: table full, dropping packet.И через 10-15 минут такого один, два или все три сразу роутера виснут и начитают, даже локально отзываться ОЧЕНЬ туго...
Помогает только ребут системы...Методом проб и ошибок частично удалось сократить появление подобных записей, путем добавления количества соединений в /proc/sys/net/ipv4/ip_conntrack_max
Но это не выход из положения, т.к. оперативная память на роутерах не резиновая...В то время, когда это происходит, можно наблюдать картину в /proc/sys/net/ip_contrack, но соединений ОЧЕНЬ (!) много, чтобы вычислить "виновника торжества"...
Вопрос: чем можно воспользоваться, чтобы вычислить самых активных пользователей, исходя из содержимого /proc/sys/net/ip_contrack ? Ведь, я уверен, что есть что-то, типа, анализатора логов... Или подскажите, кто и как поступает\поступил бы в данной ситуации, чтобы вычислить обидчика?...
PS^ все роутеры на Linux Debian (версии разные)
>Доброго дня!
>Есть ОГРОМНАЯ локальная сеть, которая через 3 железных шлюза ходит во внешний
>мир.
>Все работает. Не жалуюсь. Но бывают моменты, что на всех (!) роутерах
>одновременно начинает происходить такая картина, как жалобы на следующее --
>
>*-router kernel: ip_conntrack: table full, dropping packet.
>PS^ все роутеры на Linux Debian (версии разные)raw:
This table is used mainly for configuring exemptions from connection tracking in combination with the NOTRACK target. It registers at the netfilter hooks
with higher priority and is thus called before ip_conntrack, or any other IP tables. It provides the following built-in chains: PREROUTING (for packets
arriving via any network interface) OUTPUT (for packets generated by local processes)
----------Опишите задачи рутеров подробнее. Use FreeBSD ;-)
>[оверквотинг удален]
>NOTRACK target. It registers at the netfilter hooks
>with higher priority and is thus called before ip_conntrack, or any other IP
>tables. It provides the following built-in chains: PREROUTING (for packets
>arriving via any network interface)
>OUTPUT (for packets generated by local processes)
>Для этих целей фаирволл специально обучен )))
>
>Опишите задачи рутеров подробнее.Хмм. Странный вопрос, но тем не менее отвечаю: NAT, маскарадинг, т.к. внешних адресов мало, обслуживание домена, днс-сервера, делегирование зон, squid, snmp-мониторинг кое каких устройств, сбор статистики для биллинга по пользователям.
>Use FreeBSD ;-)
"У всех вкусы разные", - сказал кот, облизывая яйца =)
>raw:SNAT без conntrack не работает.
>Use FreeBSD ;-)
Сомневаюсь что это поможет.
Иного пути кроме как добавить памяти (кстати с чего ты решил что её не хватит на увеличение таблицы ослеживаемых соединений?) и увеличить размер таблицы conntrack нет.
Или надо отказываться от NAT.
>>raw:
>
>SNAT без conntrack не работает.
>
>>Use FreeBSD ;-)
>
>Сомневаюсь что это поможет.
>вот и я про тоже ))
>Иного пути кроме как добавить памяти (кстати с чего ты решил что
>её не хватит на увеличение таблицы ослеживаемых соединений?)Пока - только предполагаю. У меня на роутерах 256мб оперативы. Возможности расширить еще - НЕТ. Увы... Какова может быть максимальная величина значений для такого объема памяти?
>и увеличить размер таблицы conntrack нет.
>Или надо отказываться от NAT.Нет. От nat отказаться нет возможности...
>Пока - только предполагаю. У меня на роутерах 256мб оперативы. Возможности расширить
>еще - НЕТ. Увы... Какова может быть максимальная величина значений для
>такого объема памяти?Считай сам, только тебе известны запущенные программы и их аппетиты. Хотя я бы ничего не запускал из сервисов на таких компьютерах вообще.
Одна запись в таблице conntrack занимает примерно 300 байт памяти ядра (которая не может быть вытеснена в свап).
>Или подскажите, кто и как поступает\поступил бы в данной ситуации, чтобы
>вычислить обидчика?...Лучше не допускать того чтобы тебя обидели. Ограничивать число сессий для каждого локального адреса.
Но этим можно обидеть пользователей локальной сети.
>>Или подскажите, кто и как поступает\поступил бы в данной ситуации, чтобы
>>вычислить обидчика?...
>
>Лучше не допускать того чтобы тебя обидели. Ограничивать число сессий для
>каждого локального адреса.
>
>Но этим можно обидеть пользователей локальной сети.Вопрос в другом. Нужно вычислить пользователя\лей из-за которых это случается.
КАК?
>Вопрос в другом. Нужно вычислить пользователя\лей из-за которых это случается.
>КАК?В большой локальной сети - никак. Если зафиксированы ip на портах коммутатторов, то по ip.
>>Вопрос в другом. Нужно вычислить пользователя\лей из-за которых это случается.
>>КАК?
>
>В большой локальной сети - никак. Если зафиксированы ip на портах коммутатторов,
>то по ip.все так и есть! как вычислить ip зачинщика???
У меня такое было на роутере Zyxel ZeWall (внутри linux) из-за DNS за NAT ом. Решил настройкой bind forwarders, query source address, port. Тогда таблица conntrack перестала переполняться udp сессиями.
Проверьте всё-таки DNS ресолвинг, потому что это скорее всего udp (без контроля состояния) и что-то очень активное.