classic.ISPforum.cz

Toto téma by mě také zajímalo. Díky

Nic na tom neni.
V primarni chainu, kterej chcete pouzivat (obvykle Forward) si vytvorite dve pravidla (up/down) pro kazdej subnet. Ja mam segmentovani po /26. V Action vyberete Jump a do Jump Target napisete jak ten novej chain chcete pojmenovat - napr. ==192.168.57.0/26== (je to fuk)
V tyto chvili mate vytvorenej novej chain, vpravo nahore si do nej prepnete a tam uz hazite pravdila/usery jako v klasickym Forwardu a manglujete.
Stejne to funguje i ve Firewallu. Pokud chci filtrovat napr. jednotlivy IP z nejakyhu subnetu, udelam to uplne stejne jako v prikladu vyse: Vytvorim Jump do novyho chainu a vsechny IP z toho subnetu povoluju/zakazuju v tom chainu. A na konci kazdyho takovyho chainu ve FW mam globalni drop.
Smysl to ma jednoduchej: Firewal/Mangle se prochazi od shora dolu. Paklize udelam Jump do jednotlivych subnetu, packet proste dle zadanych kriterii skoci do toho patricnyho chainu a nemusi prolizat tisice zaznamu.
Pokud s tim packetem chci nasledne jeste neco delat, misto Accept v tom specifickym chainu dam Return a skoci mi to zpet do chainu, ze kteryho sem do tohoto chainu skakal (snad je to pochopitelny )
Rozhodne pouzivejte address listy, i kdyby se melo jednat o 5 IP
Pokud to vas layout site umoznuje, v pravidlech definujte i ifacy.
A posledni vec.. pouzivejte established, related pravidla! A to vždy nahoře FW. Tím se navázaný spojení znova netlačí zbytečně do chainů.



J.

edit: NAT na MK neresim, NATuju na ASR za MK (MPLS, BGP)

Keď už sme pri tom asi to bude zaujímať viacerých ,predpokladám ,že sem to nikto nepostne tak do PM sa pridávam tiez

jestli je to možné, tak bych to taky rád viděl. diky

mark jump, down i up se pošle do jinýho chainu jumpem





a následný mark v novým chainu




máme to po /24 ale to je proto protože tak prostě máme adresovanou síť. Něco přes 100 subnetů /24 a v každym cca 20-50 userů s /32. Jiný adresování bude jinak rozdělovaný. Pokud má někdo 1000 klientů a má na to použito 4x /24 tak to bude muser rozsekat třeba po /26 nebo /28.

Díky mate u nás na Moravě flašku

Btw proč je vždy in a out interface ether1? Což je předpokládám uplink port. S NATem to půjde udělat nejspíš taky tak ze?

CrazyApe píše:Díky mate u nás na Moravě flašku

ja sem z Moravy kua! Kam prijet?

Jsme od UH

CrazyApe píše:Jsme od UH

Tam jsem hrával v clubu No.6! Celkem dobrá provozní..

Já bych ještě úplně na začátek dal JUMP podle toho, jestli je to UP nebo DOWN. Jinak kdyby to byla veliká síť, mohlo by to klidně mít dvě úrovně (např. nejprve skok s maskou /16 a druhý s maskou /24). Další možností pro drobnou optimalizaci je řazení pravidel podle datového toku (tahači nebo prostě jen velké tarify nahoru). Úplně ideální řešení by pak bylo, kdyby to co nejoptimálněji generoval skript.

Nevím, jestli tady zaznělo, v čem je vlastně ta optimalizace. Vezměme např. síť s 1000 uživateli. Pokud budeme mít neoptimalizovaný "plochý" mangle, bude obsahovat 2000 pravidel (up+down), každý průchozí paket se těmi pravidly pohrne shora dolů = s každým se teoreticky udělá průměrně 1000 porovnávacích operací (s některým jedna, s některým 2000 - z tohoto pohledu je lepší mít nahoře pravidla pro DOWN a velké tarify).
Pakliže je těch 1000 uživatelů rozloženo řekněme do 20ti subnetů /24 a udělá se nejprve jump podle UP/DOWN (2 řádky), následně jump podle /24 (20 řádků) a následně koncové markování (průměrmě 1000/20=50 řádků) bude se na každý paket prohánět průměrně 1,5+10+25 pravidly = 36,5 porovnávacích operací. To je proti původním 1000 sakra rozdíl.

rsaf píše:Já bych ještě úplně na začátek dal JUMP podle toho, jestli je to UP nebo DOWN. Jinak kdyby to byla veliká síť, mohlo by to klidně mít dvě úrovně (např. nejprve skok s maskou /16 a druhý s maskou /24). Další možností pro drobnou optimalizaci je řazení pravidel podle datového toku (tahači nebo prostě jen velké tarify nahoru). Úplně ideální řešení by pak bylo, kdyby to co nejoptimálněji generoval skript.

Nevím, jestli tady zaznělo, v čem je vlastně ta optimalizace. Vezměme např. síť s 1000 uživateli. Pokud budeme mít neoptimalizovaný "plochý" mangle, bude obsahovat 2000 pravidel (up+down), každý průchozí paket se těmi pravidly pohrne shora dolů = s každým se teoreticky udělá průměrně 1000 porovnávacích operací (s některým jedna, s některým 2000 - z tohoto pohledu je lepší mít nahoře pravidla pro DOWN a velké tarify).
Pakliže je těch 1000 uživatelů rozloženo řekněme do 20ti subnetů /24 a udělá se nejprve jump podle UP/DOWN (2 řádky), následně jump podle /24 (20 řádků) a následně koncové markování (průměrmě 1000/20=50 řádků) bude se na každý paket prohánět průměrně 1,5+10+25 pravidly = 36,5 porovnávacích operací. To je proti původním 1000 sakra rozdíl.

no a pro blbý jako já to znamená menší zátěž CPU, že jo

Anebo se na to celé můžeme vykašlat a svěřit to TCAM.

Já mám co AP to /24 takže asi udělám jumpy na ty /24 subnety a je. Je jich asi 50-60. Teď mám 3500 manglu +-

rsaf píše:Anebo se na to celé můžeme vykašlat a svěřit to TCAM.

proto mám na NAT ASRko

CrazyApe píše:Já mám co AP to /24 takže asi udělám jumpy na ty /24 subnety a je. Je jich asi 50-60. Teď mám 3500 manglu +-

ano, nebo to udelaj jak psal rsaf: agreguj ty /24 do vice mensich a pak skakej dal.