Изпечатай

[KPETEH]

Примерен код

iptables v1.3.5: Couldn't load match `nth':/usr/lib/iptables/libipt_nth.so: cannot open shared object file: No such file or directory

тази грешка ми излиза при имплементиране на правилата,някой има ли идея за какво иде реч ?  

[karaman]

това понякога се появява, ако не си компилирал iptables с
-KERNEL_DIR=/usr/src/linux-.....
някои от правилата изискват сорс на кърнъла

примерно аз използвам string match

дано съм помогнал, в сайта на netfilter.org май ги имаше някъде изискванията за всички правила и как да се компилират

[Hapkoc]

Ще рече, че не може да си намери дадения модул, което пък ще рече че го нямаш стандартно компилиран и/или не си го компилирал сам. Относно самия модул - нямам идея какво прави и дали трябва да се кърпи netfilter за да го има.

[zeridon]

@KPETEH: липсва ти модула ... patch-o-matic-ng + iptables + linux sources и си ок
@Harkoc: да трябва да се пачне

[VladSun]

Интересно ми е за какво ще го ползваш тоя модул?
Load-balancing?

[gat3way]

Не мисля че е толкова лесно, въпросът не е всеки N-ти пакет да пристигне до N-тата машина зад балансера. Поне ако става въпрос за TCP сесии. Твърде вероятно нито една няма да се установи, но и да се установи това ще бъде жив късмет и благодарение единствено на това, че и двата пакета от едната страна необходими за handshake-а с машината N ще са били N-тите от гледна точка на балансера. Повечето TCP стекове като установяват тцп сесия пращат до 3-5 SYN пакета (и чакат около 30 секунди за всеки SYNACK) и отебават. Ако по случайност (вероятност 1/брой_машини) получи все пак SYNACK връзка ще се установи все пак.

Колко чакане и колко ретрансмитнати на пакети ще има обаче не ми се мисли. Една машина зад такъв балансер като изпрати *window_size* обем данни ще чака ACK за да продължи. ACK-то от страна на клиента ще бъде върнато, но понеже балансера ще го прати с вероятност 1/брой_машини там където трябва, ще настане мазало. Машината зад балансера ще спре да праща повече докато не му дойде тъпия ACK. След като не му пристигне известно време ще ретрансмитне последните непотвърдени данни и отново същото, докато по една или друга причина накрая връзката не бъде преустановена. Възможно е със 1000 мъки една tcp сесия да премине успешно (и много бавно). По-вероятно е обаче да timeout-не поради много причини.  Абе не знам. Според мен така единствено може да се създаде балансер, който позволява установяване на връзки на чист късмет, освен което такъв, който ще гарантира ужасно деградирала мрежова производителност, правопропорционално на броят машини зад него.

Интересно ми е какво би се получило от някакъв подобен експеримент...според мен жива трагедия '>

А като се замисля и колко много конекции няма да се затварят като хората (т.е едната или другата страна няма да знаят че е затворена докато не изтече keepalive времето (2 или 3 часа ако не се лъжа). Те съответно ще заемат ресурси на машините зад балансера.

Абе никак не е добра идея да се прави балансиране така. LVS е къде по-добра идея '>

[Hapkoc]

gat3way, дай на човека шанс да отговори де. Той не е казал за какво ще ползва модула, ти вече го прати в трета глуха...

[gat3way]

Е, не, аз само казвам защо не е добра идея да се ползва за балансиране. Нямам идея защо ще го ползва (мене ми хрумва единствено идеята за някакъв допотопен трафик шейпинг), но пък наистина не знам.

Между другото, още една причина поради която е неразумно да се ползва за балансиране примерно на уеб сървъри е проблемът, че iptables по никакъв начин не знае за HTTP сесии и ако отделните сървъри не си "споделят" такава информация по някакъв начин (дали java session beans, дали някакъв shared storage на който да се пази информация за тях или някакво друго решение)...в едно уеб приложение ще се наложи всяка втора стъпка да ти е лог-ване '> Апропо, това е проблем и за LVS.

[VladSun]

Аз досега в практиката си съм виждал едно единствено приложение на nth patch-а - нещо подобно на действието на TARPIT, ама не напълно.

А иначе, за да не се чупят TCP сесиите може да се използва CONNMARK '>

[gat3way]

Хехе, може и weighted round-robin да имплементираш, стига да ти се отдава математиката '>

[VladSun]

Цитат (gat3way @ Ноември 21 2006,18:04)

Хехе, може и weighted round-robin да имплементираш, стига да ти се отдава математиката '>

Мога  

Нали и аз за това питам - какви може да са постановките, при които да се ползва nth patch-a.

[gat3way]

Имаше една tc qdisc която дропеше случайни пакети когато утилизацията на канала достигне зададена стойност, не помня как се казваше, мисля че с малко усилия може да се наподоби нейното действие. За жалост в пъти по-неефективно и бавно.

Както са казали хората, който не познава добре линукс е обречен да го преоткрие по некадърен начин '>

[zeridon]

Употребата на nth пача е доста ограничена но има някои полезни страни.

Лично аз го ползвам за допотопен шейпър и то само на някои лакомници и то само към определени места. Може да се ползва и като tarpit но не е много стока тогава.

Също така може да се ползва за маскиране на комуникацията ... преставете си следната ситуация:

Примерен код

Модифициран клиент за ssh който знае че всеки 5ти пакет към определена машина ще бъде издропен и си избухва някакъв боклук там. Навярно ще трябва да се пипне и кернела (tcp стека) но не е невъзможно за реализация.

[gat3way]

Минавала ми е подобна идея през главата, но това не е ефективно.

TCP стека ще ретрансмитва докато отсреща се потвърди че е получено...няма да има проблем, само дето връзката ще е 5 пъти по-бавна според мен. Това е начина този протокол да постига надеждност върху калпави  връзки - пакетите се потвърждават и има и доста други механизми, които да гарантират комуникацията дори в среда в която да речем всеки 3 от 5 пакета биват "изгубени".

Мисля, че има и по-добри идеи за бутане на TCP трафика с постигане на такава цел (заблуда на противника)...примерно може да се получават единствено пакети с определен TCP timestamp (и връзка от клиента ще е възможна само ако той знае как да си го сет-ва (или само в един определен интервал от време след неговият ребуут.) ). Timestamp-а също така не се променя при нат-ване или рутиране, което е предимство.

Възможно е игрички и с други неща...IPID, ToS, tcp window size и т.н. но те са ограничени и ненадеждни с оглед на това че може да се променят по пътя или в течение на комуникацията.

А ако се промени начинът по който работи самият TCP стек, това би дало доста възможности....примерно връзка да се установява само ако инициращият пакет е SYN+URG да речем, така портът ще изглежда затворен и за SYN сканиране, както и за хора, които не знаят как да се свържат.

Последното изисква редакция на сорса на ядрото и противоречи на RFC-тата, но е вариант '> Но иначе при добро желание можеш да направиш много, за да накараш един порт да изглежда "затворен" и към него да се свързват само по строго определен начин.