Linux за българи: Форуми

Celeron D 1.7, RAM 384MB

uname -a
Linux 2.6.10 #5 Wed Oct 26 13:01:58 GMT-2 2005 i686 unknown

iptables -V
iptables v1.3.2

Има една частна /24 мрежа със SNAT и една публична /24 мрежа.
Прави се маркиране на пакетите по upload/download съответно за БГ/международен (т.е. 4 маркера)
Също така се прави и HTB шейп по четирите канала.

Макс. трафик е около 17Мбит.

Преди ползвах система от правила в Iptables, които бяха последователни и се обхождаха всичките, но когато сървера се натовари даже не можех да вляза в конзолата през SSH.
Поради това реших да направя дървовидна структура от правилата:

0. 2 отделни вериги за UL/DL - TRAF_IN, TRAF_OUT

1. във всяка от тези вериги се прави верига за БГ трафик (по БГ мрежи) - BG_IN, BG_OUT
2. във всяка от БГ веригите се правят две отделни вериги за разделяне на двете мрежи (публичната и частната)
3. във всяка от "мрежовите" вериги още 4 вериги за /26 мрежи
5. в получените "1/4 мрежови" вериги правя маркиране за всяко ИП
 ... по същия начин (1-5) за международния интернет
 ... по същия начин (2-5) в -t filter FORWARD веригата за разрешаване и забраняване на ИП-та

Въпросът ми е дали това което правя има смисъл и предложения за по-добри решения

ПС: в момента
 iptables -t nat -nL | iptables -nL | iptables -t mangle -nL | wc -l
 1190
при пуснати около 140 ИП-та

Мерси, Uvigii !
С AND/OR имаш предвид това ли?

Примерен код

IPMARK        Allows  you to mark a received packet basing on its IP address. This can replace many mangle/mark entries with only one,        if you use firewall based classifier.        This target is to be used inside the mangle table, in the PREROUTING, POSTROUTING or FORWARD hooks.        --addr src/dst               Use source or destination IP address.        --and-mask mask               Perform bitwise `and' on the IP address and this mask.        --or-mask mask               Perform bitwise `or' on the IP address and this mask.

или НЕДОКУМЕТИРАНАТА (поне при мене) опция за MARK --or-mark ?


Честно казано за пръв път го виждам и много ти благодаря за насоката ))))
Четох няколко пъти МАН-а, но нещо не разбрах по отношение на  --addr src/dst - по-надолу в примера използват --addrs=dst, но казват:

Примерен код

... all packets going to/from 192.168.5.2 are directed to 1:0502 queue, 192.168.5.12 -> 1:050c etc. ...

Тъй като и ти го споменаваш, това означава ли, че няма начин за отделно маркиране на входящи/изходящи пакети? Много ме обърква и това, че се намира в POSTROUING верига, пък казват "от/към"

Ако ползвам:

iptables -t mangle -A FORWARD -o ext_if -i int_if -j IPMARK --addr=src --and-mask=0xffff --or-mask=0x10000 // upload
iptables -t mangle -A FORWARD -o ext_if -i int_if -j IPMARK --addr=dst --and-mask=0xffff --or-mask=0x20000 //download

предполагам че ТРЯБВА да получа два различни маркера на пакетите?

ПС: След известно наблюдение на сървера мога да кажа, че използването на дървовидната структура имаше ОГРОМЕН ефект

pootdelno na vseki potrebitel imam napredvid***

ina4e za in/out ako si napravi6 pootdelno
iptables -t mangle -N MARK_O
iptables -t mangle -N MARK_I
i vatre sloji6 pravilata za markirane
iptables -t mangle -A POSTROUTING -o $eth_internal -j MARK_I
iptables -t mangle -A POSTROUTING -o $eth_external -j MARK_O
bi trqbvalo da stane

Btw.

Цитат

2. във всяка от БГ веригите се правят две отделни вериги за разделяне на двете мрежи (публичната и частната)

I vav vsqka ot "leaf" verigite ima6 pravilo za vseki IP adres ?
A za kakvo ti e vsqka BG mreja po otdelno ? Ne e li po-dobre vsi4ki BG mreji v edna veriga i tam spored adresa na polu4atelq da markira6 .

Ето как изглеждат при мен нещата:

Цитат

1. По една верига за всеки входящ интерфейс Chain PREROUTING (policy ACCEPT 69908 packets, 31M bytes)  pkts bytes target     prot opt in     out     source               destination  8171 6648K MARK_0_S   all  --  eth1   *       0.0.0.0/0            0.0.0.0/0 16776   18M MARK_1_S   all  --  eth2   *       0.0.0.0/0            0.0.0.0/0  6798 4181K MARK_2_S   all  --  eth3   *       0.0.0.0/0            0.0.0.0/0 2. Маркирам всеки пакет като такъв с: Локален, БГ или международен произход (0x1000, 0x1100, 0x1200) Chain MARK_0_S (1 references)  pkts bytes target     prot opt in     out     source               destination //-> Това са локалните  за ISP0 мрежи     0     0 MARK       all  --  *      *       212.116.x.y/24     0.0.0.0/0           MARK set 0x1000    10   862 MARK       all  --  *      *       217.160.a.b       0.0.0.0/0           MARK set 0x1000    35  2660 MARK       all  --  *      *       216.104.c.d       0.0.0.0/0           MARK set 0x1000     0     0 MARK       all  --  *      *       66.45.n.m         0.0.0.0/0           MARK set 0x1000    34  2584 MARK       all  --  *      *       195.161.f.p      0.0.0.0/0           MARK set 0x1000     0     0 MARK       all  --  *      *       67.15.g.e          0.0.0.0/0           MARK set 0x1000 //-> тук прявя проверка за това дали пакета е маркиран вече - ако да няма нужда да се обхождат правилата по нататък    79  6106 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x1000 //-> //-> следват всички БГ мрежи     0     0 MARK       all  --  *      *       62.32.52.0/24        0.0.0.0/0           MARK set 0x1100     0     0 MARK       all  --  *      *       62.32.56.0/24        0.0.0.0/0           MARK set 0x1100     7  3875 MARK       all  --  *      *       62.44.96.0/19        0.0.0.0/0           MARK set 0x1100     0     0 MARK       all  --  *      *       62.73.64.0/18        0.0.0.0/0           MARK set 0x1100     0     0 MARK       all  --  *      *       62.176.64.0/18       0.0.0.0/0           MARK set 0x1100     0     0 MARK       all  --  *      *       62.200.195.0/24      0.0.0.0/0           MARK set 0x1100     0     0 MARK       all  --  *      *       62.204.128.0/19      0.0.0.0/0           MARK set 0x1100 .......... //-> Проверка за това дали е БГ ? 3416 2242K RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x1100 //-> //-> Ако не е БГ и не е Локален - значи е международен.  4672 4398K MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK set 0x1200 Тази верига е аналогична на останалите 2  (MARK_1_S за  пристигащите през eth2 и MARK_2_S  пристигащите през eth3) разликите са само в стойностите с които се маркира) 0x2000,0x2100,0x2200; 0x3000,0x3100,0x3200 3. Премаркирам пакетите според получателя (тук е мястото където може да се използва OR и да се заменят всички правила само с 1) Chain POSTROUTING (policy ACCEPT 67092 packets, 31M bytes)  pkts bytes target     prot opt in     out     source               destination 39542   29M MARK_0_D   all  --  *      eth0    0.0.0.0/0            0.0.0.0/0 Chain MARK_0_D (1 references)  pkts bytes target     prot opt in     out     source               destination     1    76 MARK_0_D_0x1000  all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x1000    38  6274 MARK_0_D_0x1100  all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x1100    70 93607 MARK_0_D_0x1200  all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x1200    33 46588 MARK_0_D_0x2000  all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x2000    90 16529 MARK_0_D_0x2100  all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x2100    49  5960 MARK_0_D_0x2200  all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x2200     0     0 MARK_0_D_0x2300  all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x2300    31  2987 MARK_0_D_0x2400  all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x2400   203  105K MARK_0_D_0x2500  all  --  *      *       0.0.0.0/0            0.0.0.0/0           MARK match 0x2500 Chain MARK_0_D_0x1000 (1 references)  pkts bytes target     prot opt in     out     source               destination     0     0 MARK       all  --  *      *       0.0.0.0/0            192.168.1.1      MARK set 0x1001 .....     0     0 MARK       all  --  *      *       0.0.0.0/0            192.168.1.254      MARK set 0x10FE Chain MARK_0_D_0x1100 (1 references)  pkts bytes target     prot opt in     out     source               destination     0     0 MARK       all  --  *      *       0.0.0.0/0            192.168.168.1      MARK set 0x1101 ...... Chain MARK_0_D_0x1200 (1 references)  pkts bytes target     prot opt in     out     source               destination     0     0 MARK       all  --  *      *       0.0.0.0/0            192.168.1.11      MARK set 0x1201 ...... //-> Същото е и за останалите вериги. Chain MARK_0_D_0x2000 (1 references)  pkts bytes target     prot opt in     out     source               destination     0     0 MARK       all  --  *      *       0.0.0.0/0            192.168.168.1      MARK set 0x2001 ........

Както съм го направил има много недостатъци и утежнява (макр, че на мен не ми пречи) работата на машината.
Но има ЕДНО основно предимство: имам статиска по абсолютно всеки вазможен параметър.

Да, и аз това се сетих ...
Ама след това реших, че от статистиката на tc ще мога да си правя статистика по IP (по-скоро по MARK)

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

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

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

Примерен код

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) би трябвало да поосвободи малко ресурси.

Лично аз не бих го нарекъл преоткриване на топлата вода

Разбира се има универсални "сметачни" системки
но колкото са по универсални - толкова са по комплексирани и поддатливи на нестабилност !
колкото по-близо до реалността е решението на проблема - толкова по-добре

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

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

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

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

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

Но ... в тази тема по-скоро искаме да намерим начини за оптимизация на защитни стени, 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 правила, повишена ефективност на хтб-то и нищо друго

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

Маркираме мрежите БГ, ЛОК, останалото ИНТ, съотв. 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 за ИП  така ли ?

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

Там е работата, че с текущата НИ accounting система, като цяло има адски много правила - идеята ми е глобално да се намалят тези правила (за FORWARD разрешенията на ИП-тата няма как да стане, но за MARK има). С други думи да се премахнат *последователното* обхождане на правилата във веригите за маркиранe, а както се видя може и да се премахне и *последователното* обхождане на филтрите на тц-то.
По принцип ВСЯКА система, която се занимава с филтриране (търсене) ТРЯБВА да използва hashing (или поне сортиране) алгоритми за по-добра производителност - не е ли така?
Това го има във всяка книжка за "алгоритми-структури-данни".

За ACCOUNT patch-a:

1. Истината е, че броят на правилата в момента през които минаваме средно е 1/2 от всичките правила за маркиране - съгласен? ;
2. Ако преминем към системата, която ти предлагам в пред. пост, то както ти каза по-рано няма как да правим traffic accounting - ето тук използването на ACCOUNT е просто наложително (другия вариант е статистиките на тц-то);
3. на 99% съм сигурен, че ACCOUNT-patach-a е направен с hashing-алгоритъм (то дори и по индекс на масив да го правят стига). Нещо от сорта на:
account_table[IP]+= lengthOf(packet);
Това ние не можем да го постигнем с iptables правила;
4. по отношение на ползването на RAM-a - ок, съгласен съм

Цитат

това е идейно  донякаде макар,че ще увеличи правилата спрямо случая с hash-a ... струва си да тестваш

Тъй като не те разбрах много добре, ще кажа какво аз съм имал предвид:
root - > parent_bg_in(mark) -> hashed filters(ip)
root - > parent_bg_out(mark) -> hashed filters(ip)
root - > parent_int_in(mark) -> hashed filters(ip)
.......
Ние и в момента имаме това разделение (и няма начин да го махнем), но hashing алгоритъма в листат за ип-тата ще си работи пак по същия начин.

ПС: За n-ти път ще ти благодаря, че участваш в дискусията А за прекомерния ми ентусиазъм - ще ми простиш

//Off
Има проблем - има ентусиазъм.
Аз като нямам проблем само си човъркам пресъхналия мозък с контра-тези ей така да открием истината в спора.
Трябва някой път да обсъдим решението на задачката.

/офф
все си мисля, че обсъждането ще протече по-гладко на маса със салатка и ракийка (все пак зима е )

@Uvigii
Пак ти благодоря за коментарите
Вече има резултат - статийка