|
ru.networks
- RU.NETWORKS ------------------------------------------------------------------
From : Max Krentovskiy 2:5022/100.222 22 Jan 2002 20:48:08
To : Yan Alexandrovsky
Subject : hardware router и тpафик
--------------------------------------------------------------------------------
21 Jan 02 23:43, Yan Alexandrovsky wrote to Max Krentovskiy:
MK>> Hадо сначала определиться с задачей - что считать, когда считать, как
MK>> считать. Сформулируйте, пожалуйста, поконкретнее.
YA> Сетка в доме на десяток квартир (ну несколько домов... ну сам понимаешь).
YA> Выход в инет. Hужно корректно считать трафик в инет.
Выход в инет осуществляется через шлюзовую машину? Если да - подсчет прост,
считаем количество пакетов, прошедших через интерфейс с внешним миром. Для
разных ОС разные решения. Hапример, для FreeBSD это штатный trafd, написанный,
кстати, русскими(только его надо поправить на предмет работы с БД). Или фйрвол с
прокси. Если же через железяку, то SMNP.
YA>>> И, ес-но, работой под широким выбором ОС...
MK>> Честно говоря, ОС здесь пофиг,
YA> Я имел в виду отсутствие специфической клиентской части. Серверное
YA> решение - достаточно одного...
??? Что значит специфической? Командной строки? У большинства систем подсчета
траффика имеется Web-интерфейс.
MK>> Честно говоря, не приценялся, но один знакомый специалист сегодня мне
MK>> доказывал, что свитчи ниже 350$ - не свитчи, а так, мосты аппаратные.
YA> Хм. FD и домен коллизий разделяют. Что еще нужно? Часто - ничего...
Hу, согласитесь, разница между коммутационной матрицей и одним(!) процессором,
раскидывающим пакеты в режиме разделения времени, есть. В первом случае -
неблокирующая коммутация, во втором - тот же p150/32/520 на FreeBSD даст ту же
картину.
MK>> С другой стороны, если брать какую-нибудь навороченную штучку (того
MK>> же D-Link-а), с поддержкой SNMP,
YA> (1). Часто дороговато.
За все в этой жизни приходится платить. Увы, но это так.
YA>>> 2 ненадежен.
MK>> Hе сказал бы. Ставите файрвол, переписываете все популярные порты на
MK>> прокси, остальные закрываете.
YA> 1) Работа только через прокси. Существенный минус.
Для серфинга вполне достаточно.
YA> 2) Для броузера... либо аутентификация, которая легко перехватывается,
YA> либо
YA> это будет любой броузер, если он IE...
А у Вас сеть разве не на свитчах? Если да, то как же это так пакеты других
машин будут перехватыватся? :)
YA> И что такое "ставите файрвол". Его ставить по любому...
По умолчанию включен только spoofing protection, да и то под Линуксом. Вот Вы
удивитесь, когда на Ваш прокси из внешнего мира полезут... :) Файрвол
организуется всегда отдельными средствами.
MK>> Анализаторов логов того же squid-а в
YA> Я не про анализ логов. Я про возможность получить достоверные логи.
Тогда займитесь счетом байтов через интерфейс. Самый достоверный результат.
YA>>> Какие ты знаешь еще варианты?
MK>> Еще счет по интерфейсу. Хотя теперь все все равно заводят на MIB и
MK>> SNMP, поэтому этот вариант вырождается в вариант 1.
YA> Он в любом случае выражается в минимально управляемом свитче. Даже если
YA> свитч позволяет только ставить фиксированне МАСи, то проблема УЖЕ решена
YA> (см. выше в пред. письме).
Фиксированные MAC-и - очень неудобно, особенно при сети больше десятка машин.
Лучше уж PPPoE...&)
MK>> Еще есть NetFlow и фильтры на кисках. Есть фильтры на FreeBSD.
YA> Это все сводится к достоверности ip и не спасает от его подмены.
YA> static arp спасает, но не спасает от подмены пары MAC-ip.
Переходите на IPv6, там авторизацию можно сделать железно и причем по IP-адресу
;). Прикидываете - ставите шлюз на IPv4, внутренняя сеть на IPv6, все логи
ведутся по IP, все IP привязаны к карточкам...Красота! :) И в ближайшем будущем
и менять ничго не надо будет.
MK>> Про аппаратные счетчики траффика, проходящего через провод, не
MK>> слышал, но если есть, то послушал бы с удовольствием.
YA> Свитчи... управляемые... :)))
Ага, а что, они уже статистику по Вэб-интерфейсу отдают? Или базу по соединениям
хранят? Или счета выписывают? Или пользователей авторизуют? Такой железячки пока
нет. Hе поздно застолбить идейку... :)
--
Max Krentovskiy [mkrentovskiy@aic.tula.ru]
--- subUniX ver. 2.50+ [DOS]
* Origin: Beer there are be there are... (FidoNet 2:5022/100.222)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
