user_anonymous

Спасибо за ответ. Действительно, подходы у нас схожие. Хотел спросить у вас - а зачем делать так много файлов и каталогов? У меня дерево каталогов для детализаци выстроено несколько по-другому, благодаря чему, ИМХО, фрагментация будет гораздо меньше. У меня путь строится на основе адреса сети клиента, а по дате (год+месяц) формируется имя файла. Тоесть для клиентской сети 192.168.1.10/32 путь к файлу детализации за октябрь выглядит так:detail/192/168/1/10/2008-10--192.168.1.10.txt А в сам файл детализации пишется время дампа и количество входящего и исходящего трафика на этот момент, так что если Васи Пупкину захочется узнать, когда именно было скачено 10 гигов творчества немецких кинематографистов :) - надо будет лишь внимательно просмотреть файл, и это будет ясно с точностью до периода дампа (600 секунд по умолчанию).

2 kostich - спасибо за интересный пост. Судя по всему, наваяли вы там что-то очень серьезное, у меня все гораздо скромнее, так как я хотел сделать только простую и неприхотливую систему учета. На данный момент я заморозил работу по своей программе, степень ее готвности я бы оценил процентов на 70 - 75. Реализован поклиентский обсчет входящего и исходящего трафика на лету и генерация поклиентской детализации. Детализаиця генерируется отдельно на каждого клиента и раскладывается по каталогам (путь формируется на основе времени и адреса сети клиента), ничего парсить не надо. Не реализованы операции добавления/удаления/модификации клиентских записей, тоесть чтобы добавить нового клиента прийдется останавливать коллектор. Также не реализовано реалтаймовое снятие статистики (эти вопросы взаимосвязанны, все что нужно - это обрабатывать еще один сокет) и определение факта пропуска пакетов в последовательности NetFlow (я вообще не уверен, что это нужно). К сожалению, не проведено тестирование под нагрузкой ( негде :( ), но по субъективным ощущениям потребеление ресурсов CPU очень маленькое. Да, я знаю о проблемах разбора логов flow-tools. В моей программе детализация вообще практически ничего не жрет. Самая ресурсоемкая опреация в высокоприоритетной части - это очистка массива указателей в случае обсчета больших сетей (класса А). В низкоприоритетной - это дисковый ввод-вывод.Дерево каталогов с детализацией, формируемое программой, в принципе можно просто выставить в область видимости http - сервера (это правда будет не очень красивое решение, так как права доступа настраивать замучаешься). Я же планировал доступ абонента к детальной статистике через CGI-программу (она еще не написано, но сложного в ней ничего нету). Насчет использования более современных версий NetFlow я тоже задумывался, ибо IPv6 не за горами, но это - дело будущего.

Обновил - стало лучше. А вот prov.nag.ru по прежнему туда кажет и коннект не идет :( ;; QUESTION SECTION: ;prov.nag.ru. IN A ;; ANSWER SECTION: prov.nag.ru. 1626 IN A 85.112.113.98

;; QUESTION SECTION: ;nag.ru. IN A ;; ANSWER SECTION: nag.ru. 85963 IN A 85.112.113.98 ;; AUTHORITY SECTION: nag.ru. 3138 IN NS ns0.extrim.ru. nag.ru. 3138 IN NS ns1.extrim.ru. nag.ru. 3138 IN NS ns2.extrim.ru. ;; ADDITIONAL SECTION: ns0.extrim.ru. 534065 IN A 212.49.96.101 ns1.extrim.ru. 534065 IN A 212.49.103.2 ns2.extrim.ru. 534065 IN A 212.49.96.129 Это правильно или кэш засрали? И еще - отмечаю проблемы с доступом к prov.nag.ru

Читал в каком-то обзоре, что якобы на DragonFly, разогнанной до 2КГц по тикам смогли обработать рекордное количество пакетов. Насколько достоверна эта информация - хз.

2 0Lex Тут можно посмотреть оптический кабель по вкусу: http://shop.nag.ru/core.asp?main=catalog&cat=90

Если используется VLAN на пользователя, то самым логичным методом отключения вообще видится отключение порта на коммутаторе доступа. Это можно сделать либо через telnet, либо через SNMP. Но, имхо, сначала надо просто блокировку + редирект на страничку с требованием оплатить услуги, а порт в даун уже у злостных. Если же на доступе используется оборудование, понимающее 802.1x - вопрос отключения вообще сводится к изменению значения одного поля в базе данных, с которой общается RADIUS сервер.

Примерно с год-полтора назад я обдумывал небольшую сетку как раз модели VLAN на клиента, которая должна была проходить по району с преимущественно малоэтажной застройкой и частному сектору. В нашем городе есть несколько операторов, но они сосредоточены в районах с большими домами и суваться в тото район, котрый я рассматривал в качестве цели гарантированно не будут. В этом районе действует один ADLS - оператор, но у него по ряду причин очень малые возможности по расширению своей деятельности. Требования, котрые я выдвигал к сетке: надежность при как можно меньшей стоимости оборудования, низкие эксплуатационные расходы, малые затраты времени на сопровождение и техподдержку. По моим мыслям, в маленькие дома на доступ можно ставить DES-2108 - умеют 802.1q и привязка MAC/PORT (может быть полезно в случае схемы VLAN/дом) или DES-3010 - он умеет 802.1x, что позволяет сделать ряд вкусностей, причем вкусности будут раздаваться централизовано. Недостаток - стоит раза в два дороже, чем 2108. В этом же районе есть 3 пятиэтажки - туда я думал поставить DES-3526 или DES-3028. Эти свичи помимо вланов, привязки МАС/Порт и 802.1x умеют еще списки доступа. Это очень полезная фича для борьбы с вирусной активностью и юными кулхацкерами. Для частных домов я рассмотривал возможность ставить в доме медиаконвернер, а у себя - шасси с медиаконвертерами. В этом случае для частников получалась схема "Волокно до дома". Я даже придумал, как можно попробовать избежать прокладки по столбам (и арендной платы в 250 руб/столб). В центр планировал поставить ProCurve 2626 - простой, дешевый и надежный (по отзывам разных людей) 100 мегабитный коммутатор с зачатками Л3. На нем я планировал терминировать виланы. Рассматривалось адресное пространство из серых IP-адресов, сетка /29 на каждого клиента. Выход в интернет через сервер (шэйпер,NAT, возможно Proxy + антивирус) на Linux или FreeBSD. К сожалению (а может и к счастью) проект умер в самом начале по причине появления более приоритетной цели для вкладывания туда своих сил и средств, а чужих средств у меня небыло. Доходность от такой сети была бы маленькой (так как клиентов немного) а окупаемость длительной.

Если будет желание делать выделенный сервер CounterStrike:Source - почитайте http://forums.steampowered.com/forums/forumdisplay.php?f=45 Там много полезной информации

Зачем банку 10 разных каналов? все банкоматы одного банка в один банковский вилан. И пусть себе банкоматят :)

Пока не возникает желание пробросить ВЛАН на другой конец города ;) Много ли в обычном городе наберется юриков с офисами по всему городу? ИМХО не более 10 А уж для таких клиентов пожертвовать десяток виланов - это святое ;)

Уважаемый топикстартер, объясните плиз, ЗАЧЕМ тащить виланы в ядро? Они там нафиг ненужны. ИМХО Вилан должен идти до ближайшего Л3 свича. Причем эта схема позволяет не используя всякие Q-in-Q строить сети гигантских масштабов, ибо вилан вообще-то должен быть уникальным только в пределах одного Л3 свича. Особенно хорошо такая схема работает, кодга клиенты сидят за NAT-ом, так как используя огромные ресурсы серого адресного пространства и грамотное планирование можно все реализовать только на статической маршрутизации - а это надежность и удешевление решения.

ИМХО tbf будет кушать гораздо меньше ресурсов, чем htb, так как устроен гораздо проще. Я тут кстати пишу пакет программулек, чтобы настройки tbf брать из базы (поддерживается только PostgreSQL) и рулить всем этим делом через веб-интерфейс. Вебморда пока недоделана до конца, но впринципе все уже работает. Будет желание попробовать - обращайтесь.

Уважаемый Viv. Спасибо за совет. Но он из серии:"Скажите пожалуйста, как мне попасть на улицу ...., дом №....? У меня есть 10 руб. _ Выкинте свои 10 рублей. Просто позвоните в службу такси по номеру ...., и они вас довезут с шиком. И вы будете довольны и служба такси." Уважаемый vladh, зря вы так. 'vIv' вам предложил хорошее решение. Это, пользуясь вашей терминологией, не такси, - есть решения и покруче и подороже. Но как показывает опыт, попытка сделать сверхбюджетное решение обычно оборачивается затратами на свержбютжетное решение, головной болью, проблемами с заказчиком и затем затартами на нормальное решение. Может быть стоит попробовать не наступать на грабли и сразу сделать более менее хорошо? Опыт, опять же, показывает, что если грамотно обосновать заказчику необходимость покупки пусть и более дорогого, но более надежного оборудования, то деньги на него находятся.

2 troyand - маленькая поправочка: CounterStrike потребляет порты UDP с 27000 по 27041 и еще ряд портов по tcp, нонаиболее критичны именно UDP

Хочу высказать пару мыслей по теме. ИМХО анализ пакетов - это тупиковое направление, и развивать его смысла нету. Ибо даже достаточно слабое шифрование сведет эффективность такого мероприятия на нет. Считаю, что действовать надо по-другому. У всех любителей P2P сетей есть одна общая черта - большой трафик. Мне кажется, что отталкиваться стоит именно от этого. Можно спрятать тип трафика, но нельзя спрятать его объем. Также заслуживает внимания подход от противного - если мы не может выделить p2p сеть, то это не значит, что мы не можем выделить http или ftp. И тогда можно действовать по старому доброму принципу "все, что не разрешено - запрещено", который в нашем случае из запрещено превратится в зашэйплено. Тоесть схема борьбы получается двухуровневая: сначала на основе статистики мы отделяем потребителей большого объема трафика, и ставим им ограничения, потом пытаемся выделить из их трафика обычный HTTP и FTP и созаем для них более выгодные условия.

Похоже, в вашей сети завелся Властелин Колец. Ищите, кто и где нагадил.

Можно сделать один мощный виндовый терминальный сервер к нему при помощи rdesktop коннектятся клиенты из под линукса или фряхи. В прописках рдесктопа можно поставить кэширование, после чего жить становится лучше и веселее. В том месте, гдя я рабоатю, таким макаром работает достаточно много народу, причем значительная часть его сидит через ВПН, проложенная через довольно узкий радиоканал. По сравнению с ним сеть дяже на 10МБит кажется мечтою. Скорость конечно порою напрягает, но работать можно. По поводу оснащения виндового сервера выше уже сказали. На уровне слухов: Недавно разговаривал с одним человеком, который слышал от другого человека, что у тех в организации работает сервер 1С 7 версии под вайном от этерсофта, причем работает так, что винда нервно курит. Сам я этого не видел, поэтому достоверность подтвердить затрудняюсь. Тоесть теоретически можно заплатить за этот вайн (или попробовать запустить сервер под обычным - благо он сейчас очень быстро развивается) и вообще полностью отказаться от винды и работать в терминальном режиме.

Люди, а что, кроме VLC никто ничего не использует? (я натыкался на свободные программы, которые могут гнать мультикаст в сеть и при этом гораздо меньше грузять компьютер (по крайней мере так утверждает их описание) - вот и хочется узнать)

ИМХО 24 на пользователя - это уж слишком. Реально нужно выдавать сетку /30 или, что на мой взгляд лучше, /29 При таком раскладе у вас на дом вцелом будет уходить сетка /24 - тут уж трудно запутаться :)

Не нужно вешать никуда никаких адресов. И следует помнить, что роутинг в OpenVPN имеет весьма отдаленное отношение к роутингу системному. Вам следует внимательно почитать OpenVPN HOWTO, обратив особое внимание на опции route, iroute и ccdИ я бы рекомендовал использовать для такого шлюза нормальную ОС, а не windows. У вашего офиса на выезде и у удаленного офиса будут разные сети (если пользоваться tun интерфейсом). На правильно сконфигурированном OpenVPN клиенте будут маршруты к сети за правильно сконфигурированном OpenVPN сервером. У компьютеров, подключенных к шлюзу, будет только маршрут по умолчанию, но они будут видеть компьютеры за основным сервером, а те, в свою очередь, будут видеть эти машины. Будут проблемы с сетевым окружением - решается прописыванием сетевых дисков руками.

Не просто позволяет, а это и есть моя религия, Основной постулат которой: в бэушной циске (и не только) дохнуть не чему. Там нет движущихся частей (кроме вентиляторов) имеющих износ, как например в автомобиле. И если агрегат проработал 3 года исправно, что ему мешает еще столько же проработать.....:) Нелишне тут будет вспомнить про деградацию полупроводниковых структур, особенно при работе оборудования в условиях повышенной температуры.

еще в самом-самом начале имеет смысл раскидывать цепочки по протоколам - tcp, udp, icmp, greеще имеет смысл посмотреть в сторону модуля recent.

ИМХО было бы правильно дать им какое-то тестовое задание по области их компетенции, но с результатами, которые вы могли бы проверить и на основе этого уже делать какие-то выводы. Аргументировать всегда гораздо легче, когда есть хоть какие-то факты.

вообще-то DES-2108 умеет виланы 802.1q ИМХО весьма неплохие свичи и самое то для мелкозатратной сети. Воткнуть эти свичи можно в коммутатор HP2626 (J4900B). При таком выборе оборудования можно делать или влан на дом или даже вилан на клиента. Цена у HP 2626 весьма демократичная.