Изпечатай

[VladSun]

Здравейте!
От доста време ме мъчи един проблем - шейпване с различни скорости в зависимост дали обекта е в кеша на проксито или не.

Постановката е:
потребител -> шейпър/рутер -> прозрачно прокси -> интернет

Идеят е следната - да пачна Squida-a с http://www.it-academy.bg/zph/ и да маркирам пакетите от проксито към шейпъра по ТОС.

Линукса има само egress shaper, което затруднява извънредно много нещата.

Едната ми идея е да се сложи IMQ (ingress shaper) - http://howtos.linux.com/howtos/Adv-Routing-HOWTO/lartc.imq.shtml. Лошото е, че в майл-листа им виждам прекалено много проблеми свързани с работата на този пач. Все пак, ако някой е работил с него нека сподели.

Втората ми идея е да се използва iptables recent match-a по някакъв начин, така че когато се види пакет маркиран по ТОС, да се маркират съответните пакети в обратна посока, което ще даде възможност на HTB-то да сработи. Проблемът ми е, че доколкото разбрах няма начин да укажа, че мачнатия rdst ми е мачващия rsrc на пакетите в обратна посока.

Ако някой може да помогне и с други идеи, ще бъда много благодарен, ако сподели ! '>

Имам чувството, че се опитвам да убия муха с топ - трябва да има някакво елементарно решение, което ми убягва.

Ами защо не се опиташ да смениш схемата на:
потребител -> прозрачно прокси -> шейпър/рутер -> интернет
или:
потребител -> шейпър/рутер -> интернет
        |                   |
        |                   |
        |прозрачно прокси

[VladSun]

Защото след проксито ще получавам заявки само от неговото ИП и няма да мога да правя шейпинг по ИП. А и тая схема не ми е много ясно как точно ще работи - защо потребителя има връзка както към рутера, така и към проксито в паралел?

Правилният начин е точно както alex_c ти го е написал, само дето прозрачното прокси после ще го манипулираш с delay pools, мисли разчупено, tc не е единствения начин за bandwidth limitation :)

Успех

Малко допълнение към горният ми отговор. Днес отново прочетох (задълбочено този път) страницата на въпросния пач и се оказа че там основното на което се гради цeлия труд е че автора иска да направи всичко това на една единствена машина. Евала на пича че е тръгнал и се е потрудил сериозно за да си спести още една машинка която да му реши проблема. Предполагам че и ти го имаш същия проблем: да си сложиш 2-ро PC или да слагаш гнусни хакове :( Съжалявам за термина но това си е точно така. Не намирам за коректно приложение което работи в OSI Model Layer 7 (HTTP е точно там)  изведнъж да почне да работи и в Layer 3 (QoS e пък тук), това просто разбива въпросния модел.
Между другото това което искаш да направиш е много интересно, и ако успееш да го направиш във варианта който alex_c и аз ти предлагаме, ще бъде чудесно, а и много полезно ако пуснеш и една статийка с пълното ръководство как да стане това :)

Още веднъж успех

ПП В lartc.org го има описан примера който ти предлага alex_c  просто трябва да го допълниш с delay pools от едната страна и traffic shaper от другата.

[VladSun]

@ Sudo - има правота в отговора ти, но ....
няколко проблема:

1) проксито работи само за международния трафик (една от най-големите причини е, че в шейпъра трябва да знам дали трафика е БГ или международен) се намира на няколко километра от мене, като го използвам чрез BG peering-a. Идеята е да се съберат поне 300 потребителя, които да го ползват и по този начин да се повиши ефективността на проксито.
   Сл.1) трябва да използвам Layer-3 маркиране;
   Сл.2) не мога да направя delay-pools на вече NAT-нати локални IP адреси;

2) никъде не видях acl, който да се определя по признак HIT/MISS ?

3) много ядове си имах навремето със Squid-a - машината забива и т.н. - т.е. не искам да слагам прокси в рутера.

ПП: В новия пач ZPH автора казва:

Цитат

I have released a new version of the Zero Penalty Hit patch for SQUID caching engine (ZPH). Now it is possible to mark HIT packets leaving the proxy with an IP option - this means the packets can later be classified on the SQUID engine machine itself (via a simple tc filter command), or on any other machine through which the packet happens to pass.

т.е. дали проскито ще бъде на същата машина или на друга няма значение;

ППП: Малко глупав въпрос може би - има ли начин да се запазва ИП-адреса на потребителите на проксито след него или трафика към Интернет ще е винаги от ИП-то на проксито? В смисъл, тогава наистина ще има напълно прозрачно прокси?

Примерен код

iptables -t tproxy -A PREROUTING -j TPROXY --on-port <proxyport>

от пача http://www.balabit.com/products/oss/tproxy ще ми свърши ли някаква работа (съжалявам, че питам така, но документацията, която намерих беше доста постна)

ППП: Ако тръгне ще има статия със сигурност !

Ух-Ох бая сложничко изглежда така като си го написал, и ако те разбирам правилно, май единственото работещо решение си остава това което ти искаш, продължавам да твърдя че не е коректно, но пък ще е работещо '> Не е коректно щото както си написал проксито ти е на няколко километра от теб и минаваш през ПОНЕ едно активно устройство а може и повече. Ако само ти ги администрираш OK  обаче ако не ... лека подсказка погледни само в този форум колко много въпроси се навъдиха "Как да манипулирам ttl стойноста на IP пакета?" а tos field е само на няколко бита разстояние от ttl field. И целият ти труд отива на вятъра. Това е от мен '>

ПП Относно въпроса дали след проксито можеш да запазиш IP на потребителите, на ниво Application(Layer 7) Да, в HTTP header-a си пише "Forwarded for: 192.168.X.Y", но на ниво Network(Layer 3) Не, реално проксито не forward-ва пакети,  а чете заявката от браузъра, обработва я, праща нова генерирана от него заявка до сървъра (ако е нужно) и връща отговор на клиента. Така че физически пренос на пакети м/у интерфейсите на проксито нямаш. Всъщност май стриймовете правят изключение.

[VladSun]

Мдам, сложничко е - за това си питкам '>

[Sertys]

Ми не е никак сложно. Просто си избери pattern на който да мач-ваш на рутер-а ти и оттам слагай в по-висок клас. Примерно ако сет-неш 4-5 ТОС бита със ZPH-a(не знам дали го предоставя софт-а) после мачваш с umatch и мачкаш рибките.

[VladSun]

umatch? какво е това? Малко по-подробно? Ще съм благодарен ...

[Sertys]

TC umatch, бе ВладСън - u8,u16,u32 - match-va битовете в header-a.

[VladSun]

'> Човек ... проблемът ми не е в това как ще ги мачвам пакетите, които идват ОТ проксито, а как ще ги мачна пакетите КЪМ проксито, които са обратните пакети на маркираните ... и всичко това заради egress шейпинга. С други думи сега мога да ограничавам само upload-a към проксито, което слабо ме интересува.
Мислех, че този umatch е за iptables и наистина не го бях чувал '>
tc-то го ползвам и ще го ползвам само с MARK мач поради ред причини, които нямат отношение към проблема.

[etg]

1.потребител -> шейпър/рутер -> прозрачно прокси -> интернет
2.потребител <- шейпър/рутер <- прозрачно прокси <- интернет

Нещо не ми е ясно: на кое му казвате upload, и на кое download?
"...проблемът ми не е в това как ще ги мачвам пакетите, които идват ОТ проксито, а как ще ги мачна пакетите КЪМ проксито, които са обратните пакети на маркираните ... и всичко това заради egress шейпинга. С други думи сега мога да ограничавам само upload-a към проксито, което слабо ме интересува..."
Така че кой трафик трябва да се ограничи - от интернет към потребителя (което е download), или от потребителя към интернет (което е upload). Защото ако ви интересува download-а (т.е. от интернет към потребителя, което предполагам е по-важното), то Sertys ви го е написал. А ако това, което той ви е написал не ви върши работа, значи или и той, и аз нещо не схващаме в постановката, или вие нещо тотално бъркате и се опитвате да направите нещо, което хем е по-сложно, хем е грешно. Или може би няма кой да прочете това по-долу?
Purpose
The idea behind this patch is to allow classification of packets generated from the squid cache engine towards clients. The classification is based on whether the content is being served from cache (a cache HIT), or is being retrieved from a remote server (a cache MISS).

P.S. @VladSun: извинявай, вместо тука си пуснах отговора като лично съобщение до тебе '>

[VladSun]

Значи с този проблем се сблъсках за първи път когато трябваше да шейпвам доунлоада на международния трафик, който го докарваха от Евронет. Евронет маркират пакетите по DSCP, но се оказа, че иначе работещ шейпър (с разделяне на мрежите на БГ и на международен), не шейпваше абсолютно нищо, когато гледаше маркировката от Евронет. По този случай си мисля, че всъщност шейпинга става някак си чрез обратния канал на този който искаме да шейпнеме (ъплоада към Евронет си беше отлично шейпнат).
А случая с проксито е идентичен с този.

[etg]

Пак не ми стана ясно какво правите. Единствено разбрах, че правите нещата много по-сложни, отколкото са в действителност. Когато правиш шейпър в едната посока (примерно на трафика КЪМ клиента), просто забрави, че има и трафик в другата посока (този трафик в обратната посока няма никакво значение). Ако нещо не работи, то това по никакъв начин не е свързано с обратния трафик, така че не търси там проблема