Claudiu Cismaru wrote:
>>Tu vrei sa spui ca-si construieste un hash table pe baza tuturor
>>parametrilor? De ce ar face asta, de vreme ce nu-l intereseaza sa
>>sorteze sau sa gaseasca regulile pe baza cheii "suma parametrilor"?
>>Singura sortare care intereseaza e rulenum din chain.
>>
>>
>
>Cand un packet "intra la verficat" in chain, tu vrei sa spui ca verifica
>TOATE regulile una dupa alta? Adica daca eu am 100 de reguli in care e
>source IP de la 1-100 si pachetul meu are source ip 101, el mai
>verifica si cele 100 de reguli dinainte? Pai in cazul asta e mare
>consumator de timp... Bineinteles ca poti spune aleator IP-urile in
>pozitii, dar si in cazul asta s-ar putea face hash pe keys din
>informatii partiale: hash table de ips, hash table de ports, de in
>device de out device... Sau b-trees. Dar in cazul asta, nu pot sa spun
>ce ar putea consuma mai mult timp... Sau poate ca sistemul firewall e
>facut cu "keep it short - as no. of rules - in mind" ?
>
>Dar totusi, nu stiu de ce ne dam cu parerea si nu citim sursele, la cum
>se face parcurgerea...
>
>
>
am studiat sursele din iptables. Singurul hash table care l-am gasit
este cel aferent conntrack-ului.
cheia e (ip_src, ip_dst, protonum, port_src, port_dst) iar valoarea e
bineinteles tuplul din conntrack (vezi /proc/ip_conntrack).
chain-urile sint ceea ce le arata si numele, adica lanturi. iptables
este OBLIGAT prin definitie sa parcurga regulile din chain-urile
respective IN ORDINEA hotarita de administrator. nu stiu pe cita lume ar
incinta faptul ca iptables ar parcurge un lant de genul
-s 192.168.0.1 -j DROP
-d 192.168.0.2 -j ACCEPT
intr-o ordine pseudo-aleatoare, dictata un b-tree oarecare.
nu pot sa inteleg cum de nu realizati ca administratorul hotaraste
regulile si ORDINEA in care sint ele parcurse de catre fiecare pachet...
tine de domeniul evidentei!!!
---
Detalii despre listele noastre de mail: http://www.lug.ro/
