zvlasny problem z firewallom

[arpanet na post.cz]

> > Mam takyto problem. Mam firewall na PII 500MHz, RedHat 9, jadro 2.4.23
> opathovane na BridgeNF (to je ta vec aby sa aplikovali iptables cez bridge).
> V kancelarii mam skusobny server, ked pred neho dam firewall (na nom so ho
> vlastne vzdy skusal) tak vsetko bezi ok. Ked ten firewall dam na salu pred
> normalny server klesne priepustnost asi na 10KB/s. Bez neho to bezi asi
> 9500KB/s, ale skusobny server bezal stale asi 8700KB/s ci s firewallom alebo
> bez rozdieli boli iba nepatrne. Potom som spravil pokus a dal som firewall
> iba za svoj PC a bez problemov som cez neho pristupoval na oba
> serveri.Nechapem to, lebo ten firewall je vlasne bridge cize nema ip nieko
> nemeni adresny priestor len obcas stopne niaky ten paket, proste
> inteligentnejsi kus kablu. Ma niekto napad co to moze sposobovat?
> 
> Je mozne aby tento problem niako sposoboval router? (napryklad ci mu nemozu
> byt divne tie mac adresy sietoviek vo firewalle) Je mozne vidiet tieto mac
> adresy ked sietovky idu v promisc mode ?
> 
nevim jestli je to neni pouze muj blud  ... ale
pokud vy jste za tim bridgem ... a pristupujete k siti skrz nej 
tak to funguje asi takhle 
  1. paket vyleze z vasi sitovky do dratu 
  2. bridge na sitovce bliz k vam slysi paket a jukne 
     na jeho zdrojovou a cilovou MAC adresu ... jukne 
     do svych tabulek .... (bridge si buduje seznamy 
     na kterem drate (interni sitovce) slysi ktere 
     zdrojove adresy) .... a za 
        a) zdrojova a cilova jsou na stejne strane ...
            -> bridge nedela nic 
        b) zdrojova a cilova jsou na ruzne strane
            -> nabere paket na lopatu, prohodi ho skrz 
               pravidla ip tables a vyplivne na cilovou stranu
               (nebo zahodi)
        c) cilova MAC neni v tabulkach ... 
               -> jako b... ale na vsechny sitovky (segmenty)
                  krome te z ktere prisel tenhle paket
        d) zdrojova MAC neni v tabulkach  
	       -> zapamatuje si odkud paket prisel ... 
               -> dale jako b
        e) neni znam ani zdroj ani cil ... 
               -> jako  d c
  
        xxx) cilova mac je FFFF.FFFF.FFFF 
            (asi doufam ze to nejni 0000.0000.0000)
            jedna se o eth. broadcast
               -> jako u c 

 3. a jedeme znovu od zacatku ...
  


z toho mi vychaziiii ze vy jako klient tlacite data 
skrz bridge na server ... a ostatni toho po vas moc nechtej
   a) tabulka MAC adres nenjni moc velka ... 
      skrz bridge jdou jenom vase pakety ... 
   -> tim padem se ten bridge muze docela nudit 

   b) vy a spousta dalsich klientu tlaci data na ten server
       ...
   -> to bude ten bridge docela dost zpocenej a uhonenej ... 

proste si myslim na rozdil od ip ... kde si ta masina vsima 
jen svejch eth paketu a dal se rozhoduje podle IP adr ... atd 
tak ten bridge ma docela dost prace kdyz se musi o kazdym eth 
paketu kterej svistii dratem vokolo rozhodnout esli ho nabrat 
na lopatu a nebo ne .... 

vem te si treba takovejch 20 kompuuu na eth siiti kteryy si na jedne 
strane  dratu povidaj se sebou se serverem a k tomu spoustu veselejch broadcastu ... a na druhy strane site ten server za bridgem ... 
ten bridge musiii vyhodnotit kazdej paket kterej si svistii draatem
okolo .... 

-> sem se nejak rozkecal ... proste sw bridge je reseni ... ale 
ne pro hustej provoz ... a ne pro Lan <x> Server .... ale mozna je to 
jenom muuj dojem ... 


s pozdravem arpanet na post.cz 

-----Banshee foot--------------------------------
            Better Artificial Inteligence than Natural Stupidity
   		  a nekdy je nejlepczi kedluben -)