Титла: Грешка в библиотеките на iptables
Публикувано от: KPETEH в Nov 21, 2006, 11:58
| Примерен код |
| 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 |
тази грешка ми излиза при имплементиране на правилата,някой има ли идея за какво иде реч ?
Титла: Грешка в библиотеките на iptables
Публикувано от: karaman в Nov 21, 2006, 12:27
това понякога се появява, ако не си компилирал iptables с
-KERNEL_DIR=/usr/src/linux-.....
някои от правилата изискват сорс на кърнъла
примерно аз използвам string match
дано съм помогнал, в сайта на netfilter.org май ги имаше някъде изискванията за всички правила и как да се компилират
-KERNEL_DIR=/usr/src/linux-.....
някои от правилата изискват сорс на кърнъла
примерно аз използвам string match
дано съм помогнал, в сайта на netfilter.org май ги имаше някъде изискванията за всички правила и как да се компилират
Титла: Грешка в библиотеките на iptables
Публикувано от: Hapkoc в Nov 21, 2006, 12:28
Ще рече, че не може да си намери дадения модул, което пък ще рече че го нямаш стандартно компилиран и/или не си го компилирал сам. Относно самия модул - нямам идея какво прави и дали трябва да се кърпи netfilter за да го има.
Титла: Грешка в библиотеките на iptables
Публикувано от: zeridon в Nov 21, 2006, 14:32
@KPETEH: липсва ти модула ... patch-o-matic-ng + iptables + linux sources и си ок
@Harkoc: да трябва да се пачне
@Harkoc: да трябва да се пачне
Титла: Грешка в библиотеките на iptables
Публикувано от: VladSun в Nov 21, 2006, 15:32
Интересно ми е за какво ще го ползваш тоя модул?
Load-balancing?
Load-balancing?
Титла: Грешка в библиотеките на iptables
Публикувано от: gat3way в Nov 21, 2006, 16:52
Не мисля че е толкова лесно, въпросът не е всеки 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 е къде по-добра идея
Колко чакане и колко ретрансмитнати на пакети ще има обаче не ми се мисли. Една машина зад такъв балансер като изпрати *window_size* обем данни ще чака ACK за да продължи. ACK-то от страна на клиента ще бъде върнато, но понеже балансера ще го прати с вероятност 1/брой_машини там където трябва, ще настане мазало. Машината зад балансера ще спре да праща повече докато не му дойде тъпия ACK. След като не му пристигне известно време ще ретрансмитне последните непотвърдени данни и отново същото, докато по една или друга причина накрая връзката не бъде преустановена. Възможно е със 1000 мъки една tcp сесия да премине успешно (и много бавно). По-вероятно е обаче да timeout-не поради много причини. Абе не знам. Според мен така единствено може да се създаде балансер, който позволява установяване на връзки на чист късмет, освен което такъв, който ще гарантира ужасно деградирала мрежова производителност, правопропорционално на броят машини зад него.
Интересно ми е какво би се получило от някакъв подобен експеримент...според мен жива трагедия
А като се замисля и колко много конекции няма да се затварят като хората (т.е едната или другата страна няма да знаят че е затворена докато не изтече keepalive времето (2 или 3 часа ако не се лъжа). Те съответно ще заемат ресурси на машините зад балансера.
Абе никак не е добра идея да се прави балансиране така. LVS е къде по-добра идея
Титла: Грешка в библиотеките на iptables
Публикувано от: Hapkoc в Nov 21, 2006, 17:19
gat3way, дай на човека шанс да отговори де. Той не е казал за какво ще ползва модула, ти вече го прати в трета глуха...
Титла: Грешка в библиотеките на iptables
Публикувано от: gat3way в Nov 21, 2006, 17:25
Е, не, аз само казвам защо не е добра идея да се ползва за балансиране. Нямам идея защо ще го ползва (мене ми хрумва единствено идеята за някакъв допотопен трафик шейпинг), но пък наистина не знам.
Между другото, още една причина поради която е неразумно да се ползва за балансиране примерно на уеб сървъри е проблемът, че iptables по никакъв начин не знае за HTTP сесии и ако отделните сървъри не си "споделят" такава информация по някакъв начин (дали java session beans, дали някакъв shared storage на който да се пази информация за тях или някакво друго решение)...в едно уеб приложение ще се наложи всяка втора стъпка да ти е лог-ване Апропо, това е проблем и за LVS.
Между другото, още една причина поради която е неразумно да се ползва за балансиране примерно на уеб сървъри е проблемът, че iptables по никакъв начин не знае за HTTP сесии и ако отделните сървъри не си "споделят" такава информация по някакъв начин (дали java session beans, дали някакъв shared storage на който да се пази информация за тях или някакво друго решение)...в едно уеб приложение ще се наложи всяка втора стъпка да ти е лог-ване
Апропо, това е проблем и за LVS.Титла: Грешка в библиотеките на iptables
Публикувано от: VladSun в Nov 21, 2006, 17:53
Аз досега в практиката си съм виждал едно единствено приложение на nth patch-а - нещо подобно на действието на TARPIT, ама не напълно.
А иначе, за да не се чупят TCP сесиите може да се използва CONNMARK
А иначе, за да не се чупят TCP сесиите може да се използва CONNMARK
Титла: Грешка в библиотеките на iptables
Публикувано от: gat3way в Nov 21, 2006, 18:04
Хехе, може и weighted round-robin да имплементираш, стига да ти се отдава математиката
Титла: Грешка в библиотеките на iptables
Публикувано от: VladSun в Nov 21, 2006, 18:20
| Цитат (gat3way @ Ноември 21 2006,18:04) |
| Хехе, може и weighted round-robin да имплементираш, стига да ти се отдава математиката |
Мога
Нали и аз за това питам - какви може да са постановките, при които да се ползва nth patch-a.
Титла: Грешка в библиотеките на iptables
Публикувано от: gat3way в Nov 21, 2006, 18:44
Имаше една tc qdisc която дропеше случайни пакети когато утилизацията на канала достигне зададена стойност, не помня как се казваше, мисля че с малко усилия може да се наподоби нейното действие. За жалост в пъти по-неефективно и бавно.
Както са казали хората, който не познава добре линукс е обречен да го преоткрие по некадърен начин
Както са казали хората, който не познава добре линукс е обречен да го преоткрие по некадърен начин
Титла: Грешка в библиотеките на iptables
Публикувано от: zeridon в Nov 22, 2006, 12:12
Употребата на nth пача е доста ограничена но има някои полезни страни.
Лично аз го ползвам за допотопен шейпър и то само на някои лакомници и то само към определени места. Може да се ползва и като tarpit но не е много стока тогава.
Също така може да се ползва за маскиране на комуникацията ... преставете си следната ситуация:
Лично аз го ползвам за допотопен шейпър и то само на някои лакомници и то само към определени места. Може да се ползва и като tarpit но не е много стока тогава.
Също така може да се ползва за маскиране на комуникацията ... преставете си следната ситуация:
| Примерен код |
| Модифициран клиент за ssh който знае че всеки 5ти пакет към определена машина ще бъде издропен и си избухва някакъв боклук там. Навярно ще трябва да се пипне и кернела (tcp стека) но не е невъзможно за реализация. |
Титла: Грешка в библиотеките на iptables
Публикувано от: gat3way в Nov 22, 2006, 12:41
Минавала ми е подобна идея през главата, но това не е ефективно.
TCP стека ще ретрансмитва докато отсреща се потвърди че е получено...няма да има проблем, само дето връзката ще е 5 пъти по-бавна според мен. Това е начина този протокол да постига надеждност върху калпави връзки - пакетите се потвърждават и има и доста други механизми, които да гарантират комуникацията дори в среда в която да речем всеки 3 от 5 пакета биват "изгубени".
Мисля, че има и по-добри идеи за бутане на TCP трафика с постигане на такава цел (заблуда на противника)...примерно може да се получават единствено пакети с определен TCP timestamp (и връзка от клиента ще е възможна само ако той знае как да си го сет-ва (или само в един определен интервал от време след неговият ребуут.) ). Timestamp-а също така не се променя при нат-ване или рутиране, което е предимство.
Възможно е игрички и с други неща...IPID, ToS, tcp window size и т.н. но те са ограничени и ненадеждни с оглед на това че може да се променят по пътя или в течение на комуникацията.
А ако се промени начинът по който работи самият TCP стек, това би дало доста възможности....примерно връзка да се установява само ако инициращият пакет е SYN+URG да речем, така портът ще изглежда затворен и за SYN сканиране, както и за хора, които не знаят как да се свържат.
Последното изисква редакция на сорса на ядрото и противоречи на RFC-тата, но е вариант Но иначе при добро желание можеш да направиш много, за да накараш един порт да изглежда "затворен" и към него да се свързват само по строго определен начин.
TCP стека ще ретрансмитва докато отсреща се потвърди че е получено...няма да има проблем, само дето връзката ще е 5 пъти по-бавна според мен. Това е начина този протокол да постига надеждност върху калпави връзки - пакетите се потвърждават и има и доста други механизми, които да гарантират комуникацията дори в среда в която да речем всеки 3 от 5 пакета биват "изгубени".
Мисля, че има и по-добри идеи за бутане на TCP трафика с постигане на такава цел (заблуда на противника)...примерно може да се получават единствено пакети с определен TCP timestamp (и връзка от клиента ще е възможна само ако той знае как да си го сет-ва (или само в един определен интервал от време след неговият ребуут.) ). Timestamp-а също така не се променя при нат-ване или рутиране, което е предимство.
Възможно е игрички и с други неща...IPID, ToS, tcp window size и т.н. но те са ограничени и ненадеждни с оглед на това че може да се променят по пътя или в течение на комуникацията.
А ако се промени начинът по който работи самият TCP стек, това би дало доста възможности....примерно връзка да се установява само ако инициращият пакет е SYN+URG да речем, така портът ще изглежда затворен и за SYN сканиране, както и за хора, които не знаят как да се свържат.
Последното изисква редакция на сорса на ядрото и противоречи на RFC-тата, но е вариант
Но иначе при добро желание можеш да направиш много, за да накараш един порт да изглежда "затворен" и към него да се свързват само по строго определен начин.