Newsgroup: it.comp.os.linux.sys
Titolo: Ebtables vs Iptables

Ciao a tutti,
spero di non essere OT, forse questo messaggio poteva stare anche su
it.comp.reti.ip-admin.
Sto realizzando un firewall in bridgind in modo che sia trasparente e mi
consenta libertà in una infrastruttura che non ne ha. Nelle settimane scorse
mi era stato suggerito di usare ebtables (che nessuno usa ancora in
produzione) poichè iptables non gestiva egregiamente il controllo dei
pacchetti su bridge. Ho invece trovato in questi giorni molti articoli che
mi dicono il contrario, in particolare tutti articolo che vorrebbero usare
un bridging patchato da Lennert Buytenhek (
bridge.sourceforge.net
) che non
ho capito cosa abbia di diverso dal normale supporto nel kernel.
Qualcuno per caso ha già provato o implementato quieste soluzioni? come vi
siete trovati?
grazie per i vostri pareri
Stefano

 come vi siete trovati?
Ne ho alcuni in produzione ma sono limitati: non permettono di matchare
in funzione dell'interfaccia di ingresso/uscita del pacchetto, non sono
in grado di gestire mangling nè altre alterazioni dei pacchetti.
Sicuramente anche altro che non so/non mi viene.
Byez.
-- 
Emanuele Balla  aka Skull -  Public Key #661E5CBF on 
www.keyserver.com
+----------------------------------------------------------------------+
"And 1.1.81 is officially BugFree(tm), so if you receive any bug-reports
on it, you know they are just evil lies." (By Linus Torvalds)

 consenta libertà in una infrastruttura che non ne ha. Nelle settimane scorse
In alternativa al bridge puoi considerare l'ipotesi di usare proxy-arp:
http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.bridging.proxy-arp.html
-- 
Vincenzo

 ho capito cosa abbia di diverso dal normale supporto nel kernel.
Io lo ho provato, e funziona bene. Ebtables invece e` ancora piuttosto
immaturo (ho avuto problemi di prestazioni degradanti nel tempo sotto
stress). Ti raccomando decisamente la soluzione iptables+patch.
-- 
	kinkie (kinkie chiocciola tiscalinet punto it)
	E ora, qualche parola dai nostri sponsor:
My experience with government is when things are non-controversial, beautifully
co-ordinated and all the rest, it must be that not much is going on.
		-- J.F. Kennedy

 in grado di gestire mangling nè altre alterazioni dei pacchetti.
Mi permetto di dissentire. Ho usato io iptables+patch per fare dnat
con connection tracking, e ha funzionato correttamente. La patch per
usare iptables+bridge altro non fa che "estrarre" dal flusso dei
pacchetti attraverso il bridge i pacchetti che vanno trattati, i quali
poi venono gestiti sostanzialmente a layer-3.
[...]
-- 
	kinkie (kinkie chiocciola tiscalinet punto it)
	E ora, qualche parola dai nostri sponsor:
I have hardly ever known a mathematician who was capable of reasoning.
		-- Plato

 con connection tracking, e ha funzionato correttamente. La patch per
Urka.. qui si fa interessante.
Tutto quello che m'era riuscito di fare č stato trattare l'interfaccia
bridge come una interfaccia di nat. Ovvero
Inet-----BRIDGE-----DMZ
           |
          eth0
           |
          LAN
Ma su bridge puro non mi č riuscito di fare nat.
Puoi inviarmi un esempio, se non ti costa troppe evoluzioni?
Byez...


 che altrimenti non è possibile.
Non ti so dire perchè, kernel 2.4.20, debian normale (kernel preso e
compilato da me), nessuna patch se non ebtables .... iptables legge e lavora
sui pacchetti anche sul bridge... sul chain FORWARD
Bye, Stefano

 lavora sui pacchetti anche sul bridge... sul chain FORWARD
poesse che abbiano incluso la patch nel main tree di netfilter.
L'ultima macchina che ho messo su in bridging aveva (e ha) kernel
2.4.18...


 Puoi inviarmi un esempio, se non ti costa troppe evoluzioni?
Purtroppo il sistema e` ormai smantellato, ma e` abbastanza semplice:
- patchi il sistema
- fai un bridge-device
- applichi le regole di iptables al cosi` come le applicheresti
normalmente, e se c'e` da specificare una interfaccia specifichi il
bridge-device.
-- 
	kinkie (kinkie chiocciola tiscalinet punto it)
	E ora, qualche parola dai nostri sponsor:
phosflink:
	To flick a bulb on and off when it burns out (as if, somehow, that
	will bring it back to life).
		-- "Sniglets", Rich Hall & Friends

 bridge-device.
Probabile che abbia fatto troppe cazzate, ma mi era parso di capire che
l'attraversamento dell'interfaccia di bridge non contemplasse il
passaggio per prerouting (dato che routing non v'č...).
Per questo l'avevo data su...
Byez.


 passaggio per prerouting (dato che routing non v'č...).
[...]
E` esattamente il pezzo aggiunto da quella patch.
-- 
	kinkie (kinkie chiocciola tiscalinet punto it)
	E ora, qualche parola dai nostri sponsor:
"Once they go up, who cares where they come down?  That's not my department."
-- Werner von Braun