squid sattelite problem

Zdravejte zna4i az imam sledniq problem: izpolzvam squid za da ograni4a vryzkite kym dvuposo4en satelit, no vypreki bezplodnite mi usliq typiq satelite zabiva vinagi koagto broq na connectciite nadhvyrli 20. Ako imate nqkakyvi predlogeniq ili nqkayvi RTFM.....misalta mi e kak da se ograni4at otgoing connectiite ot squida kym sattelita, btw predi tozi squid sam slogil transparent proxy na edna druga ma6ina koqto se obry6ta kym tozi squid..
Blagodarq predvaritelno na vsi4ki otzovali se!

с iptables --limit

Какво точно имаш в предвид, като казваш "с iptables --limit" !
Използването на --limit според "некои ора" помага да лимитираме броя предварително маркирани пакети, които да пропуснем за единица време.....!!!!
примерно:
IPTABLES -A FORWARD -m limit --limit 3/minute........!!!!!
Все ми струва, че ключа от бараката е другаде

сигурен ли си, че само тцп сесиите трябва да се лимитират? ако да - що се занимаваш със скуид? има си вариант и повече инфо можеш да намериш на netfilter.org - търси connlimit patch.

TANSTAAFL! There AiNt Such Thing As A Free Lunch

mislq 4e tova bi mi svar6ilo rabota 10x onzi..

Ако трябва да сме точни мисля, че ти трябва : iplimit patch
примерно така:

За да лимитираш до 2 HTTP конекции, от определено IP:

# iptables -A INPUT -p tcp --syn --dport http -m iplimit --iplimit-above 2 -j REJECT

Мислих още по въпроса и се сетих че имам и tc+cbq с което shape-вам клиентската мрежа per ip. Дали ако променя maxburst на пакетите минаващи през сателита ще се получи желания ефект: примерно - сателита подържа да кажем 20 conn, имам средно 10 активни клиента едновременно и ако им кажа maxburst 2 пакета - 10x2=20...
Защото с това правило за над 2 conn -j REJECT става кофти - не се забавя връзката, а направо на клиента си му пищи се едно няма нет.
Мислите ли, че ще се получи?
10х отново.

Използването на числото 2(две) в случая е съвсем произволно. Просто за да има пример.
Мисля че идеята ти не е лоша, но аз лично нямам такова чудо "two way satellite", затова просто пробвай и кажи какво се е получило.

Доколкото разбирам, "тайната" ти цел е да накараш сесиите да се изчакват и да не се отварят по повече от 20 едновременно. Не че теоретично е невъзможно, но аз поне не се сещам за практическа реализация. Трябва да имаш механизъм, който да буферира и задържа SYN пакетите, докато броят на отворените сесии не спадне под 20. С tc/cbq можеш да ги забавиш, но само за определено време, а не до настъпване на външно събитие. В най-добрия случай можеш да пробваш с iplimit да маркирваш всички syn пакети за сесиите над 10-тата (примерно) и да ги вкараш в някакъв много малък клас. Но като се има предвид, че тези пакети са много малки (и правят малко трафик), а една сесия трае поне 20-тина секунди, въобще не мога да си представя какъв трябва да е този клас - може би 0.000001 бпс. А и това няма да ти реши проблемът с отказаните сесии, просто ще се случва по-рядко, защото с наближаване на горната граница ще се бави отварянето на нови сесии и така ще се даде време на старите да се затворят.

Имаш и друг проблем - както iplimit, така и squid лимитирват всяко ip поотделно. Можеш да имаш един ACL който да match-ва цялата мрежа, но въпреки това лимитът е за всяко 1 ip. Трябва машината, на която си пуснал транспарантно прокси да скрива всички потребители зад нея. А можеш да пробваш и с два каскадно-свързани squid-а - при дефиницията на parent може да се каже колко максимум връзки да отваря, но не знам какво ще стане, когато се надскочат. Най-вероятно ще мине direct, освен ако нямаш забраняващо правило.

Митко

Значи първо опитах с tc+cbq и съответно стана точно това което предположи и ти - първоначално се получи желания ефект, но след едно натоварване - около 100 usera схемата издържа около 1.30 - 2 часа и пак увисваше. Съответно направих нещо друго: вдигнах още един ip adress и съответно промених routing - таблицата транспарентното прокси илизаше на сателита през един ip adress без останалите форкове, съответно обаче SYN пакетите си останаха, но с ACL правило конекциите вече се ограничават само по едно ip и за момента работи чудесно - няма вече забиване.
Мисля си обаче за още един вариант: ако на машината със сателита прекомпилирам squida с delay pools опции и си сложа правила за достъп по време - в рамките на няколко секунди 20 примерно да пуска и после 10 забранява, но си мисля че е много трудоемко. ако проработи и по този начин ще постна скрипт във форума а и ще постна и моята работещата схема в момента. Ще пробвам и предложението на Mitko.
Ако някой има още предложения моля.
Благодаря на всички отзовали се...

Сещам се за 2 възможни начина:

1. да се пачне "SYN flood" защитата в кърнъла да следи не за броя SYN пакети в секунда, а за броя на отворените TCP сесии на даден порт и при достигането на определен watermark да решава, че има syn flood. Това е интересна задача и като остана без работа (като се пенсионирам :-) може и да я пробвам.

2. да се пачне tproxyd да се fork-ва при всяка заявка, а child процеса да чака броя на сесиите да спадне, преди да отвори следващата сесия към squid. Това е по-лесно изпълнимо и трябва да се внимава за по-малко неща - май само за temeout и за достигане на някакъв максимален брой child-ове, както и за конкуренцията между child-овете кой да вземе освободената сесия.

Митко