❗️Toto je původní verze internetového fóra ISPforum.cz do února 2020 bez možnosti registrace nových uživatelů. Aktivní verzi fóra naleznete na adrese https://telekomunikace.cz
rozdíl mezi "mark paket" a "mark connection&q
rozdíl mezi "mark paket" a "mark connection&q
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í
Naposledy upravil(a) Besito dne 28 Aug 2006 13:17, celkem upraveno 1 x.
0 x
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í.
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í.
0 x
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
0 x
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-
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-
0 x
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ýlitAle 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
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é...
Naposledy upravil(a) Besito dne 30 Aug 2006 22:04, celkem upraveno 1 x.
0 x
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-
0 x