classic.ISPforum.cz

Ahoj zajímlo bym ne, jaký je rozdíl mezi těmito dvěma markováním. je mi jasné, že jedno omarkuje paket a druhý omarkuje spojení, ale není mi jasné jaký v tom je rozdíl při použití např. v Queue Tree... Díky moc za vysvětlení

asi v tom nehledej rozdíl, jde spíš o využití.

Pokud chceš markovat v rámci jedné IP adresy pakety, které jdou ven i dovnitř. Příchozí paket pro konkrétní IP omarkuješ jedině na základě omarkovaného spojení.

OK a když tedy chci omarkovat všechny pakety na portu 80 (http), tak použiji asi mark paket...

Ok, díky

pokud se jedná pouze o pakety na portu 80 nehledě na zdrojovou a cílovou IP tak stačí packet mark respektive dvě pravidla. Jedno pravidlo na odchozí paket a druhé na příchozí paket..

Ahoj, označuji příchozí i odchozí pakety pro konkrétní IP i bez omarkovaného spojení. Pro upload přidávám značku v preroutingu, pro download v postroutingu a potom omezuji v Queue Tree (pro download mám parent global-out, pro upload global-in) a zdá se mi, že vše funguje. Nebo je to špatně a mám použít to označování spojení?
Nevíte jak je to s rychlostí, jestli třeba není označení podle spojení rychlejší nebo pomalejší než označení paketů? Děkuji za vysvětlení.

Besito píše:Ahoj zajímlo bym ne, jaký je rozdíl mezi těmito dvěma markováním. je mi jasné, že jedno omarkuje paket a druhý omarkuje spojení, ale není mi jasné jaký v tom je rozdíl při použití např. v Queue Tree... Díky moc za vysvětlení

Velmi jasne je povedane na eng fore, ze lepsiu detekciu znacenia p2p spojeni je v markovani celych spojeni, kde je zarucena ovela vacsia uspesnost detekcie. Ale zdalo sa mi to celkom divocina, tolko pravidiel tvorit len kvoli sosacom

Jak to chápu já, ikdyž je mi jasné, že v porovnání s ostatníma toho ohledně síařiny chápu ještě dost málo :-)

V Simple queue, nebo i QT, máme možnost zadat pouze packet mark. Teoreticky by tedy stačilo pouze omarkovat pakety, ne connection. Myslím si ale, že důvod proč se to dělá, je NAT většinou na odchozím interface - masquarading.

"Normální" komunikace (zapněte si třeba Ethereal) vypadá takto:

PC1: 10.0.0.10
PC2: 10.0.0.20

PC1 to PC2:
dotaz: src 10.0.0.10 dst 10.0.0.20
reply: src 10.0.0.20 dst 10.0.0.10

Jenže když jdeme třeba ven do Internetu, myslím že to bude takto:

PC1: 10.0.0.10
server v Internetu: 81.82.83.84

dotaz: src 10.0.0.10 dst 81.82.83.84 (server někde v Internetu)
router masquarading: src 80.80.80.80 (naše veřejná IP) dst 81.82.83.84
reply: src 81.82.83.84 dst 80.80.80.80
router: src 81.82.83.84 dst 10.0.0.10

Prostě když je tam NAT, tak ten venkovní server neví nic o 10.0.0.10. Proto si myslím, že musí být povolen connection tracking a následně se nejprve musí markovat connections - prostě je to pro nás helper, kdy nám router pozná, které pakety patří k danému spojení. Následně tedy až na základě connection marku můžeme provést packet mark ...

Tak nějak to tedy chápu já, můžu se mýlit :-) Ale tak nějak začínám chápat, proč nám pan Klíma jako jednu z variant nabízel, že možná by bylo vhodné na hlavním routeru nedělat NAT (aby právě tyto věci byly jednodušší) a NAT dělat na nějakém předřazeném stroji .... (do této varianty jsme zatím nešli).

Ještě k těm chainům - ikyž se dívám na flow diagram jak dlouho chci, zatím stejně přesně nechápu, ve kterém chainu by měl co člověk markovat. Vidím příklady na p2p manglování ve forwardu - když jsem to tak měl na jednom uzlu, tak to markovalo download i upload, když to bylo na centrálním routeru, tak upload ukazoval pořád 0. Tak jsem to dal do preroutingu a začalo to jet.

Můj skromný názor je, že by se většina měla dělat v preroutingu, protože to je chain, kam se leze nejdříve, a na co se zdržovat :-) Pouze v případě, že bych chtěl něco manglovat až třeba po NATu, tak bych si asi našel jiný chain, nebo tak nějak, nevím :-)

zdar,
-pekr-

vidis, na to som zabudol, pravdu mas .
http://forum.mikrotik.com/viewtopic.php?t=5808

pekr píše:Jak to chápu já, ikdyž je mi jasné, že v porovnání s ostatníma toho ohledně síařiny chápu ještě dost málo

V Simple queue, nebo i QT, máme možnost zadat pouze packet mark. Teoreticky by tedy stačilo pouze omarkovat pakety, ne connection. Myslím si ale, že důvod proč se to dělá, je NAT většinou na odchozím interface - masquarading.

"Normální" komunikace (zapněte si třeba Ethereal) vypadá takto:

PC1: 10.0.0.10
PC2: 10.0.0.20

PC1 to PC2:
dotaz: src 10.0.0.10 dst 10.0.0.20
reply: src 10.0.0.20 dst 10.0.0.10

Jenže když jdeme třeba ven do Internetu, myslím že to bude takto:

PC1: 10.0.0.10
server v Internetu: 81.82.83.84

dotaz: src 10.0.0.10 dst 81.82.83.84 (server někde v Internetu)
router masquarading: src 80.80.80.80 (naše veřejná IP) dst 81.82.83.84
reply: src 81.82.83.84 dst 80.80.80.80
router: src 81.82.83.84 dst 10.0.0.10

Prostě když je tam NAT, tak ten venkovní server neví nic o 10.0.0.10. Proto si myslím, že musí být povolen connection tracking a následně se nejprve musí markovat connections - prostě je to pro nás helper, kdy nám router pozná, které pakety patří k danému spojení. Následně tedy až na základě connection marku můžeme provést packet mark ...

Tak nějak to tedy chápu já, můžu se mýlit Ale tak nějak začínám chápat, proč nám pan Klíma jako jednu z variant nabízel, že možná by bylo vhodné na hlavním routeru nedělat NAT (aby právě tyto věci byly jednodušší) a NAT dělat na nějakém předřazeném stroji .... (do této varianty jsme zatím nešli).

Ještě k těm chainům - ikyž se dívám na flow diagram jak dlouho chci, zatím stejně přesně nechápu, ve kterém chainu by měl co člověk markovat. Vidím příklady na p2p manglování ve forwardu - když jsem to tak měl na jednom uzlu, tak to markovalo download i upload, když to bylo na centrálním routeru, tak upload ukazoval pořád 0. Tak jsem to dal do preroutingu a začalo to jet.

Můj skromný názor je, že by se většina měla dělat v preroutingu, protože to je chain, kam se leze nejdříve, a na co se zdržovat Pouze v případě, že bych chtěl něco manglovat až třeba po NATu, tak bych si asi našel jiný chain, nebo tak nějak, nevím

zdar,
-pekr-

Connection tracking musí být zapnutý, jinak ti nepojede net...

Moc jsem to nepobral, proč se dělá mark connection... Já nemarkuju spojení a jde mi to taky

Předřazený stroj s nat dělat nebudu, protože si osobně myslim, že je to na mé poměry zbytečné...

Besito píše:Connection tracking musí být zapnutí, jinak ti nepojede net...

Moc jsem to nepobral, proč se dělá mark connection... Já nemarkuju spojení a jde mi to taky :-)

Předřazený stroj s nat dělat nebudu, protože si osobně myslim, že je to na mé poměry zbytečné... :-)

Imo connection tracking by teoreticky zapnutý být nemusel, kdyby se nepoužíval NAT (masquarading) nebo tak něco, ale to je jedno, vpodstatě jo, měl by být pořád zapnutý, protože proč ne, že jo :-) ...

To že ti bez mark connection jede marking, tak to máš štěstí - mě na hlavním routeru nejel v Simple Queue upload. A jen proto, že jsem to měl ve forward chainu a jak mi Eugene řekl, tak prostě SQ vytvoří 3 HTB classy, v global-in, globat-total a global-out, takže když omanglujeme paket jen ve forward chainu, nebude ten mark ta SQ vidět v global-inu například. Přitom v dokumentaci tam mají ukázku na p2p dělanou ve forward chainu, tak nevím. Jinde zase odpovídá, že se connection markuje kvůli NATu.

-pekr-