Изпечатай

[Uvigii]

Ами аз съм научил 1 -
искаш ли нещо да стане точно както го искаш .... - правиш си го сам '>

[VladSun]

Просто не ми се преоткриваше топлата вода '>
Сега разглеждам сорса на ACCOUNT пача (както и на такива, които имат поддръжка за 2.6.х кернели) и се мъча да го направя за 2.6.х.
Лошото е, че досега не съм писал нещо за линукс по-дълго от 100 реда ... камо ли да вникна в чужд код (от това по-гадно няма)
Най-много да омажа нещата '>

[VladSun]

Тъй като е по темата '>

Примерен код

iptables -t raw -I PREROUTING -i eth1 -s 1.2.3.4/24 -j NOTRACK iptables -t raw -I PREROUTING -i eth0 -d 1.2.3.4/24 -j NOTRACK

Това (ако защ. стена е "без памет" по отношение на публичните ИП-та, т.е. тези които нямат NAT) би трябвало да поосвободи малко ресурси. '>

[Uvigii]

Лично аз не бих го нарекъл преоткриване на топлата вода
'>
Разбира се има универсални "сметачни" системки '>
но колкото са по универсални - толкова са по комплексирани и поддатливи на нестабилност !
колкото по-близо до реалността е решението на проблема - толкова по-добре
'>

[VladSun]

е да де ама наистина много отдавна ми е писнало от решения "работи за мен, за момента" ... сменяш нещо и айде наново.
Още от първите ми крачки в програмирането (преди около 10-12 год.) бях "поучен", че нещата трябва да се правят за общия случай за да работят за всеки частен '>
И се придържам към това правило и за момента '>))

[mrvoland]

тук се очертава fan-club IPtables '>
да внеса и моето скромно инфо ще ме извините ако повторя някой преди мен '>

http://www.linuxguruz.com/iptables/

това е доста добър източник за идеи, готови скриптове и т.н.
всеки може да си вземе готов скрипт и да го прерпави за неговите нужди

[VladSun]

Интересен линк, наистина '> и доста полезен
Благодаря за него '>

Но '> ... в тази тема по-скоро искаме да намерим начини за оптимизация на защитни стени, user accounting (на това не се сещам превод '> ) и т.н. изградени с iptables и обикновено *доста* големи (като брой правила).
Ще се радвам, ако се включиш '>

//Off

Цитат

нещата трябва да се правят за общия случай за да работят за всеки частен

със което не съм съгласен! Всеки подход си има плюсове и минуси! Как виждаш програма на Java работеща на AVR, PIC или какъвто и да е друг микроконтролер? Или графична среда писана на асемблер? Или драйвер за серийния порт който има гласов интерфейс към потребителя и търси извънземни докато си почива ?? Ако ти ще работиш с един или 2 частни случая за какво ти е да си напишеш програма обработваща всички възможни случаи? Това ми звучи като "Нашата складова(счетоводна) програма е най-хубавата и става за всеки склад (счетоводство) защото е предвидена да работи със всички складове и всички счетоводства на света ...
Както беше казал някой :
KISS
'>

/Off
Мисля, че и двамата сме прави донякъде, но и двамата грешим в същото време '> - просто сме застанали сме в двата края, а истината е винаги по средата '> ( където КИСС принципът действа с пълна сила ) - нещата наистина не трябва да се правят супер глобални, но не трябва и да са прекалено локални '> И в двата крайни случаи име много проблеми при добавяне на нова фукционалност, нали '>

Между другото видя ли
http://www.linux-bg.org/cgi-bin....t=11643
на мен ми звучи доста добре '>
Само дето нямам представа как се подкарва по MARK

//Off
И аз това казвам:
Има случаи когато прог трябва да е голяма, сложна и объркана , с възможност да и се намазват нови функционалности от което тя да става още по объркана и нестабилна ..
Има и случаи когато прог трябва просто да работи и нищо друго.
//Off2
Въобще замислял ли си се колко % от софтуера решава човешки задачи т.е. помага на хората и колко % решава софтуерни и хардуерни проблеми ?
като започниеш БИОС,Райд,ОС,Драйвери,Бейкъп,Протоколи,АнтиВирус, АнтиСпам,ФайърУол,ИДС, Анти това, Анти Онова АААААаааа......
и това само за да си изпратиш 1 писмо ...
'>

Да.
След като разбрах, че примера е само за клас Б а за клас Ц не ставало се отказах да го чета '>
Но сега по твоя препоръка направих един бърз прочит. Не мисля, че в случая с ло/бг/инт ще има полза, но ще поразгледам по подробно.

Доколкото си спомням tc-filter можеше да match-ва по няколко признака (fw, ip), така че би могло да ни свърши свърши работа, ако имаме MARK за лок/бг/инт и след това за всяко ИП по самото ИП '>

Е, не изглежда ли хубаво:

MARK лок/бг/инт (глобално)
ACCOUNT (по мрежи)

hashed filters htb (ip, fw)

около 20 правила, повишена ефективност на хтб-то и нищо друго '>

Цитат

ACCOUNT (по мрежи)

Имаш на предвид:
1. Клиентски?(dst) При което ще имаш акк за всяко клиентско ИП като цяло и няма да можеш да разграничиш ло/бг/инт освен ако не направиш отделен акк за всеки от видовете
2. БГ ?!(src)
btw.
Защо мислиш, че АЦЦ прави нещо различно от това да добавя по един(или повече) брояч(и) за всеки клиент ? Вярно може и да има увеличено бързодействие (което е по скоро в % отколкото в пъти).

Цитат

hashed filters htb (ip, fw)

Това би трябвало да слага във всеки филтър по 2 условия 1 за МАРК и 1 за ИП  така ли ?

[VladSun]

Еми примерно:

Маркираме мрежите БГ, ЛОК, останалото ИНТ, съотв. UL/DL
- BG_IN, BG_OUT, LOC_IN, LOC_OUT, INT_IN, INT_OUT - MARK 1,2,3,4,5,6.
Във всяка
-m account --aname mynetwork --aaddr 192.168.0.0/24
и получаваме accounting  за всяко ИП.

Производителността със сигурност ще се увеличи и то не само от самия match (1! правило), ами и в последствие при събирането на данните и обработката им - (работим с файл в /proc/sys/...., който е в паметта - доколкото разбрах от описанието на ACCOUNT).

По отношение на тц-то: хрумна ми, че *може би* можеда се направи filter по MARK за parent-а за всеки отделен трафик, а в него листата да се мачват по ИП - само, че не знам дали ще сработи '>

Цитат

Това би трябвало да слага във всеки филтър по 2 условия 1 за МАРК и 1 за ИП  така ли ?

Иначе, точно това имам предвид '>