Co se tyka UDP paketu tak se to da udelat i tak ze pakety omarkujes v
manglu a potom pocitas spojeni pomoci tech omarkovanych paketu...chce to
jeste logicky domyslet ale tak nejak bych si to asi predstavoval...
samozrejme ze pokud mas APcka v bridgi tak je to problem, iptables
pravidla se tam uplatni spise nahodnym zpusobem protoze iptables je
staveno na zaklade manipulace se stackem v kernelu ... tam je ten
problem ze v rezimu bridge je ten stack modifikovanej.....jinak v
mikrotiku to jsou standarni iptables pouze s grafickym rozhranim...
jinymi slovy asi neni problem si v manglu udelat mark udp paketu s
passthrough, potom hned zanej nalepit pravidlo mark connection kery to
rozpozna na zaklade marku paketu a nasledne uz pravidlo spojeni per
ip....problem je v tom ze tohle rozhodne neudelas na APcku, musel bys
tam mit pecko s mikrotikem kery by to udelalo ...jenze pokud to udelas
az na centralnim orezu tak se zahlti backbone presne jak si
rikal....jedina moznost ktera me napada tak pokud nedavas klientum extra
rychly linky (pres 1mbit pro domacnosti) tak tyhle filtrovaci pravidla
nahazet primo na klient side mikrotiku( hadam ze rb433c)...
chce to ale na nekom takrikajic otestovat...teorie je krasna vec...
ja sem to zatim moc neresil, orezavam klienty na apcku v modu routeru a
centralni preklad/routing mi dela linuxovej stroj...zatim pri malejch
tocich (mame jenom asi 160klientu) s tim problem neni ale jak
rikam...skusil bych to udelat klient-side, pripadny problemy s normalnim
trafficem by se pak mely dat poresit QoSem...
Zdravi Vilem Kebrt alias Saevar...
Impulz.cz ...decin
Zbyne(k Burget napsal(a):
Na tohle odpovim jen kvuli ujasneni situace - tohle je zde uz dost
tezce OT
Vilem Kebrt napsal(a):
Zdravim...neni preci problem pridat do firewallu na mikrotiku
pravidlo ktere povoli urcity pocet spojeni per ip...
Tohle samozrejme mam nastaveno, ale:
1. ne vzdy to funguje spolehlive a to zd uvodu, ze vetsinu AP nemam v
modu routeru, ale bridge. A v teto konfiguraci to proste nepracuje
tak, jak bych si predstavoval.
2. Nefunguje pro UDP provoz, takze torrentisti se tomuhle budou jenom
smat.
3. nechutne drsne to zatezuje procesor na tech routerboardech, takze
to musim mit udelano tak, ze se to zapina jen ve chvilich, kdy je
zatizeni procesoru nizsi.
Jinak mi pomerne slusne funguje rozpoznani provozu p2p ...primo
integrovano opet v mikrotiku...proste to omarkuju(delam to teda na
bohuzel se spolehlivosti rozpoznavani p2p provozu na RouterOS mam
pomeren rozpacite zkusenosti. Pro jistotu tedy nepouzivam vubec a
resim na jinymi cestami na centralnim routeru (FreeBSD).
rozpozna...jedinej problem je v okamziku kdy klient ma trosku v hlave
a prepne na sifrovany spojeni p2p(napr v bittorentu), ale to zase poresi
A o tohl emi jde, ostatni mne zase tak moc nemrzi.
to pravidlo x spojeni per ip...
neporesi - protoze pak tam leti UDP provoz a cele pravidlo je na dve
veci.
Co je ale zasadni pruser, tak je to, ze se torrent snazi navazat velka
kvanta spojeni smerem ven (tedy v situaci, kdy si "nekdo" chce
stahnout neco od klienta z me site). Shaper na routeru sice ten provoz
hezky usmerni, ale neuzsi hrdlo je na trase klient - AP a tam se ty
spojeni omezit nedaji. Kdyz jsme zkouseli uplne cokoli, proste to
osetrit nejde. I kdymy fungovalo pravidlo na max. pocet spojeni na
mikrotiku, nezabrani to klientovi v tom, aby se nesnazil odesilat
stovky az tisice SYN packetu za sekundu, cimz pak totalne "umlati"
pripojny bod a cela sit na tom bode prestava fungovat. Jedine reseni
je takoveho klienta natvrdo odpojit. Kdyz jsem se snazil rozchodit
pocitani poctu spojeni, mel jsem udelany automat, ktery klienta
odpojoval. Problem je, ze to ty spojeni nepocitalo prilis regulerne a
diky tomu to obcas odpojilo i toho, koho nemelo. A pruser byl na
svete. Pozdeji se ukazal i problem s pretezovanim CPU, kdyz bylo
vyrobeno providlo pocitajici pocet spojeni a cele to prakticky letelo
do kose.
Proto hledam jine reseni, kterak nejak spolehliveji pocitat spojeni na
routeru, neni problem, abych pak na dalku automaticky prislusneho
klienta sestrelil a poslal si o tom informaci, abych jej mohl
upozornit na to, co se stalo.
Zbynek
--
FreeBSD mailing list ([email protected])
http://www.freebsd.cz/listserv/listinfo/users-l
--
FreeBSD mailing list ([email protected])
http://www.freebsd.cz/listserv/listinfo/users-l
