Ethernet Bridge + netfilter Howto <author><htmlurl url="mailto:Nils.Radtke_@_Think-Future.de" name="Nils Radtke"> <date>v0.8, luglio 2005  <abstract> Installare un ethernet bridge offre la possibilità di integrare in una rete già esistente uno strumento di controllo e di regolazione del traffico in maniera del tutto trasparente. Questa installazione non richiede cambiamenti alla topologia logica della rete e viene realizzata collegando il bridge ethernet nella topologia fisica, tra la rete stessa e l'istanza di instradamento (quella parte dell'hardware connessa a Internet). Traduzione a cura di Ginox (ginox@toglimi.autistici.org) e Michele Ferritto (m.ferritto@toglimi.virgilio.it), revisione a cura di Daniele A. (illusionsensei@yahoo.it). </abstract> <toc> Questo Howto è disponibile in <htmlurl url="http://www.think-future.de/DOCUMENTATION/Ethernet-Bridge-netfilter-HOWTO/other_formats/" name="diversi formati">. Preferibilmente scaricabile come: <htmlurl url="http://www.think-future.de/DOCUMENTATION/Ethernet-Bridge-netfilter-HOWTO/Ethernet-Bridge-netfilter-HOWTO.tar.gz" name="tarball">. Si può reperire l'Howto presso il <htmlurl url="http://www.tldp.org/docs.html#howto" name="Linux Documentation Project">. <newline> Si sta cercando una traduzione in un'altra lingua? Si veda la <htmlurl url="http://www.think-future.de/DOCUMENTATION/Ethernet-Bridge-netfilter-HOWTO_de/" name="versione tedesca">. Da Marzo 2003 è c'è una versione francese di questo HOWTO, disponibile grazie a Francois Romieu e Guillaume Lelarge: <htmlurl url="http://fr.tldp.org/HOWTO/lecture/Ethernet-Bridge-netfiter-HOWTO.html" name="versione francese">. Ultimamente, a luglio 2005, sono inciampato su di una versione italiana di questo HOWTO! Sfortunatamente non c'è nessuna nota dei traduttori nel documento, grazie agli sconosciuti: <url url="http://ftp-ildp.httpdnet.com/Ethernet-Bridge-netfilter-HOWTO" name="versione italiana">. <descrip> <tag>2005-07-12:</tag> Aggiunto il link alla versione italiana di questo HOWTO (si veda sopra). Inserita inoltre una sezione su come rendere <ref id="reboot" name="permanenti al riavvio"> le modifiche, una nota sul <ref id="kernel-2.6" name="kernel 2.6 che non funziona come ci si dovrebbe aspettare"> e la <ref id="user-exp" name="sezione esperienze degli utenti">. Inclusa la <ref id="final-note" name="sezione Note Finali">. :) <tag>2005-06-06:</tag> Sfortunatamente, il linux documentation project non risponde attivamente alle richieste di aggiornamento. Il risultato è una versione non aggiornata di questo documento, sul sito www.tldp.org. Si utilizzi invece il presente, se si vuole avere la versione più recente di questo HOWTO. Biasimo alle persone del tldp. <tag>2004-08-03:</tag> Carsten (C DOT Lueth AT fielmann DOT com) ha scoperto una variante per i <htmlurl url="http://www.tecchannel.de/software/1387/0.html" name="sistemi MS Windows (TM)">. <tag>2004-06-13:</tag> Aggiornamento sulle versioni del kernel utilizzate, avvertimento sulla <ref id="HINT_cutoff" name="amministrazione remota">, codice per <ref id="HINT_netfilter_debugging" name="netfilter debugging">. Nuova traduzione disponibile: Francese (si veda il link sopra). Abbandonata la versione tedesca. <tag>2002-09-19:</tag> Aggiornati i link relativi ad ebtables nella sezione "Argomenti Correlati". Aggiunta una nota sul <ref id="HINT_False_positive" name=""falso positivo" debugging output di br-nf">. <newline> <tag>2002-10-08:</tag> Aggiunta la sezione <ref id="TESTING_actual_configuration" name="Configurazione attuale"> e suggerimenti sull'instradamento in <ref id="BRIDGE_routing" name="Configurare l'instradamento">, <ref id="TESTING_routing" name="Pingalo Jim!"> </descrip> <newline>   <sect>Introduzione I bridge ethernet uniscono due o più differenti segmenti ethernet in maniera trasparente. <newline> Un bridge ethernet smista i pacchetti in ingresso sulle porte associate con l'interfaccia del bridge. Ciò viene realizzato in maniera ponderata: quando il bridge sa a quale porta corrisponde il MAC address del destinatario del pacchetto, questo viene instradato soltanto su quell'interfaccia invece di inquinare tutte le porte. Le interfacce ethernet possono essere aggiunte ad un'interfaccia bridge già esistente e divenire quindi porte (logiche) di quest'ultima. Aggiungere una struttura netfilter su di un'interfaccia bridge fornisce al sistema un meccanismo di filtraggio creato in modo trasparente che, inoltre, non necessita di un indirizzo IP per funzionare. In ogni caso è possibile assegnare un indirizzo IP all'interfaccia bridge per scopi amministrativi (chiaramente soltanto attraverso ssh ;-). I vantaggi di questo sistema sono evidenti. La trasparenza evita all'amministratore la pena di ristrutturare la topologia della rete. Gli utenti non noteranno l'esistenza del bridge anche se le loro connessioni verranno bloccate; inoltre non saranno disturbati mentre si effettua l'installazione (si consideri un'azienda dove la perdita della connettività si traduce in un alto costo). Un altro caso comune è quello del cliente connesso alla rete globale tramite un router concesso in uso. Poiché i provider raramente concedono privilegi di amministrazione sul loro hardware, il cliente non può cambiare la configurazione di connessione. Disponendo di una rete funzionante e nell'intento di spendere meno possibile, non è sua intenzione riconfigurarla interamente. Utilizzando un dispositivo di bridging non è costretto a farlo.      <sect>Software necessario Questa è la configurazione software necessaria sul computer che farà da bridge, secondo quanto descritto nella sezione <ref id="TESTING_Testing_grounds" name="Terreno di prova">. <sect1>Caratteristiche del kernel Linux<label id="kernel-2.6"> L'uso del kernel 2.6 non è ancora una buona idea. Sì, è strano. Il perchè e dove il codice di bridging non funzioni non è ancora saltato fuori. Non è raccomandato utilizzare questa serie. Si ha la soluzione? Si sia certi di poterlo dimostrare e la si invii per e-mail a me (l'indirizzo è nella pagina introduttiva). Si vedano anche le <ref id="kernel-notes" name="Note sul Kernel"> per le informazioni aggiuntive. Intanto si usino kernel della serie 2.4. <newline> A partire dalla versione <em/2.4.18/ del kernel, il supporto per l'Ethernet Bridge è già presente. Non è necessaria alcuna patch. A proposito delle versioni più recenti del kernel, bisogna precisare che la versione <em/2.4.23/ è la meno raccomandabile, in particolar modo se usata insieme a ebtables e netfilter-bridging. Sono raccomandate versioni più recenti. <newline> Il paragrafo che segue è sorpassato (12-07-2005) poichè tutto quello di cui si necessita è disponibile nel kernel. Lo si può tranquillamente saltare, viene mantenuto solo per ragioni storiche:<newline> Se si ha intenzione di usare le risorse netfilter, perché si vuole eseguire iptables sul nuovo router/firewall Linux, si rende necessario applicare una patch. Le patch possono essere scaricate dalla <ref id="LINK_Bridge-home" name="homepage del progetto Ethernet Bridge su sourceforge">. <tscreen> <verb> root@bridge:~> cd /usr/src/ root@bridge:~> wget -c http://bridge.sourceforge.net/devel/bridge-nf/bridge-nf-0.0.7-against-2.4.18.diff root@bridge:~> cd /usr/src/linux/ root@bridge:~> patch -p1 -i ../bridge-nf/bridge-nf-0.0.7-against-2.4.18.diff </verb> </tscreen> Supponendo di voler utilizzare netfilter sull'interfaccia bridge e di aver già applicato la patch al kernel, si dovranno ora attivare alcune opzioni di configurazione di quest'ultimo. Per i dettagli su come realizzare la propria immagine del kernel si veda <htmlurl url="http://www.think-future.de/DOCUMENTATION/CD-Net-Install-HOWTO/CD-Net-Install-HOWTO-4.html#Kernel_Configuration" name="CD-Net-Install-HOWTO, Toolbox">. Ah si, è ancora solo in tedesco. Ehm, dovrei metterlo a posto un giorno di questi, ma mi manca il tempo... Qualche volontario? (questo mortale silenzio è assordante.. ;) Per ora, in ogni caso: In <tscreen> <verb> Code maturity level options </verb> </tscreen> si attivi <tscreen> <verb> [*] Prompt for development and/or incomplete code/drivers </verb> </tscreen> e in <tscreen> <verb> Loadable module support </verb> </tscreen> <tscreen> <verb> [*] Enable loadable module support [*] Set version information on all module symbols [*] Kernel module loader </verb> </tscreen> Ok, per ora tutto bene. Quindi in <tscreen> <verb> Networking options </verb> </tscreen> si abiliterà <tscreen> <verb> [*] Network packet filtering (replaces ipchains) [ ] Network packet filtering debugging </verb> </tscreen> <label id="HINT_netfilter_debugging"> <descrip> <tag>Nota:</tag> In precedenza, la suindicata opzione di debugging era selezionata. Per ora, a meno che non si voglia che la propria partizione <tt>/var/log/</tt> venga riempita in breve tempo, la si disattivi. <newline> Se viene attivata, nel dmesg appariranno centinaia di messaggi in <tt>/var/log/{kern.log,debug,syslog,messages}</tt>simili al seguente: <tscreen> <verb> skb: pf=2 (unowned) dev=br0 len=52 PROTO=6 156.136.32.121:3709 192.168.101.2:112 L=52 S=0x00 I=35470 F=0x4000 T=51 nf_hook: hook 1 already set. skb: pf=2 (unowned) dev=br0 len=52 PROTO=6 156.136.32.121:3709 192.168.101.2:112 L=52 S=0x00 I=35470 F=0x4000 T=51 nf_hook: hook 0 already set. skb: pf=2 (unowned) dev=br0 len=52 PROTO=6 192.168.101.11:2828 192.168.101.2:202 L=52 S=0x10 I=63 F=0x4000 T=64 nf_hook: hook 1 already set. skb: pf=2 (unowned) dev=br0 len=52 PROTO=6 192.168.101.11:2828 192.168.101.2:202 L=52 S=0x10 I=63 F=0x4000 T=64 nf_hook: hook 3 already set. skb: pf=7 (owned) dev=eth1 len=1500 </verb> </tscreen> </descrip> Poi in <tscreen> <verb> IP: Netfilter Configuration ---> </verb> </tscreen> si selezionerà tutto quello di cui si necessita come modulo. Ed ora il campo tanto atteso: attivare <tscreen> <verb> <M> 802.1d Ethernet Bridging </verb> </tscreen> insieme a <tscreen> <verb> [*] netfilter (firewalling) support </verb> </tscreen> <descrip> <tag>Nota:</tag> La precedente opzione sarà presente solo se è stata applicata con successo la patch al kernel! </descrip> Infine si ha semplicemente bisogno di eseguire: <tscreen> <verb> root@bridge:~> make dep clean bzImage modules modules_install </verb> </tscreen> se il comando và a buon fine, tutto è a posto. Non ci si dimentichi di cambiare <tt>/etc/lilo.conf</tt> e di rilanciare <tscreen> <verb> root@bridge:~> lilo -t root@bridge:~> lilo root@bridge:~> reboot </verb> </tscreen> <descrip> <tag>Suggerimento:</tag> Si vuole evidenziare il nuovo kernel come bridge kernel? Si apra in un editor il Makefile che si trova nella directory dei sorgenti del kernel e si modifichi la linea di intestazione chiamata EXTRAVERSION =. Si potrebbe modificarla in, magari, bridge? ;-) Dopo il modules_install i nuovi moduli saranno in /lib/modules/2.4.18bridge <newline> Per gli utenti debian (si usi eventualmente prima <tt>export PATCH_THE_KERNEL=YES</tt> e --added_patches your_patches con make-kpkg): <tscreen> <verb> root@bridge:~> make-kpkg --revision=tf.1.0 kernel_image </verb> </tscreen> </descrip> <sect1>Strumento spazio utente: <tt/brctl/ Ora che il kernel è configurato con il supporto per l'Ethernet Bridge e netfilter, si prepara lo strumento spazio utente <tt/brctl/. Questo è lo strumento da utilizzare per <ref id="SETUP_Linux_brctl" name="configurare"> quanto necesario. Si scarichi <ref id="LINK_Bridge-home" name="il tarball del sorgente">, si decomprima e ci si posizioni nella directory appropriata. <tscreen> <verb> root@bridge:~> wget -c http://bridge.sourceforge.net/bridge-utils/bridge-utils-0.9.5.tar.gz root@bridge:~> tar xvzf bridge-utils-0.9.5.tar.gz root@bridge:~> cd bridge-utils-0.9.5 </verb> </tscreen> Si consultino il file <tt/README/ e quanto presente nella sottodirectory <tt>doc/</tt>. Quindi si compili con un semplice make e si copi il risultante eseguibile <tt>brctl/brctl</tt> in <tt>/sbin/</tt>. <tscreen> <verb> root@bridge:~> make root@bridge:~> cp -vi brctl/brctl /sbin/ </verb> </tscreen> Questo è tutto. Si può procedere con la <ref id="SETUP_Linux_brctl" name="Configurazione."> <sect1> Note sul Kernel <label id="kernel-notes"> Sintomo: Durante la configurazione funziona tutto, ma i pacchetti non attraversano più le interfacce del bridge come succedeva con il kernel 2.4. <newline> ipuk s (qasuari_ @ _yahoo.com) scrive (più o meno a giugno 2005): <tscreen> <verb> [...] Compilo il mio kernel dal 2.4.18-14 al 2.6.0 e attivo bridge-netfilter&ebtables. Dopo la compilazione, non riesco a pingare da un host verso l'interfaccia della linux box. La linux box ha semplicemente un interfaccia.Cosa ho sbagliato nella compilazione??? [...] </verb> </tscreen>     <sect>Configurare Linux<label id="SETUP_Linux_brctl"> <sect1>Configurare il bridge È necessario che il sistema riconosca il bridge. A questo proposito, prima di tutto deve essere indicato che si vuole un'interfaccia bridge Si veda <ref id="TESTING_Testing_grounds" name="Terreno di prova">). <tscreen> <verb> root@bridge:~> brctl addbr br0 </verb> </tscreen> Secondo, non si ha bisogno di STP (Spanning Tree Protocol). Nell'esempio proposto c'è un unico router, quindi un loop è molto improbabile. Si può quindi disabilitare questa funzionalità. (La rete risulterà anche meno congestionata): <tscreen> <verb> root@bridge:~> brctl stp br0 off </verb> </tscreen> Dopo questi preparativi, si possono finalmente eseguire i comandi effettivi. Si aggiungeranno le due (o più) interfacce fisiche, ciò significa che verranno associate all'interfaccia logica (virtuale) del bridge br0 appena creata. <tscreen> <verb> root@bridge:~> brctl addif br0 eth0 root@bridge:~> brctl addif br0 eth1 </verb> </tscreen> <label id="HINT_cutoff"> <descrip> <tag/Nota Importante:/ Molte persone mi hanno inviato email dicendo che li avrebbe aiutati parecchio se fossi stato più esaustivo e chiaro sul rischio di essere tagliati fuori. Per cui a questo punto si faccia attenzione ai miei ammonimenti: <newline> Se si sta leggendo questo, si è ad un (piccolo) passo dall'essere _isolati__ dalla macchina che si sta trasformando in un bridging device. <newline> Se vi piace vivere al limite del dissanguamento è il momento giusto per tirare fuori la cassetta del pronto soccorso. Ne avrete veramente bisogno. <newline> Se non avete l'accesso fisico e nessuno alla vostra portata lo ha: <newline> NON PROCEDERE A MENO CHE LE VOSTRE DITA NON ABBIANO LASCIATO LA TASTIERA CHE AVETE DI FRONTE E I VOSTRI OCCHI NON SIANO CONCENTRATI SU ALTRO CHE NON SIA LA CONSOLE SU CUI STATE LAVORANDO. <newline> Ora siete stati avvisati. Non mi assumo nessuna responsabilità. </descrip> Ora, le due interfacce fisiche sono diventate un'unica porta logica del bridge. Ehm, ok, avevamo ed avremo sempre due interfacce fisiche. Sono sempre lì, controllate ;-) Ma ora sono parte di un dispositivo bridge logico e quindi non c'è bisogno di alcuna assegnazione di IP. Dunque si possono rilasciare gli indirizzi: <tscreen> <verb> root@bridge:~> ifconfig eth0 down root@bridge:~> ifconfig eth1 down root@bridge:~> ifconfig eth0 0.0.0.0 up root@bridge:~> ifconfig eth1 0.0.0.0 up </verb> </tscreen> Grande! Ora abbiamo una linux box senza IP. Dunque se hai intenzione di configurare il tuo futuro firewall/router via TP, usa la tua console locale ;-)) Ne possiedi una seriale ? Buon per te :-) <newline> <descrip> <tag/Optional:/ Si può associare alla nuova interfaccia logica un IP in questo modo: <tscreen> <verb> root@bridge:~> ifconfig br0 10.0.3.129 up </verb> </tscreen> </descrip> <newline> Si confronti la sezione <ref id="TESTING_Important_note" name="Note Importanti">! <sect1>Configurare l'instradamento <label id="BRIDGE_routing"> Nel caso in cui si intenda configurare un gateway si dovrà abilitare l'inoltro (forwarding) nel kernel. <tscreen> <verb> root@bridge:~> echo "1" > /proc/sys/net/ipv4/ip_forward </verb> </tscreen> La macchina possiede già un IP, ma non una route di default. Si imposta con <tscreen> <verb> root@bridge:~> route add default gw 10.0.3.129 </verb> </tscreen> Alla fine si dovrebbe avere una rete funzionante da, verso e attraverso il gateway. <sect1>Facciamolo succedere di nuovo! <label id="reboot"> Meglio detto come: dobbiamo rendere le modifche permanenti al riavvio. <newline> Per ottenere questo, è necessario qualche tipo di script di shell messo nell'appropriata directory di boot-up: <tt>/etc/init.d/</tt> <newline> In seconda battuta, bisogna creare un link nella propria directory di runlevel. La directory giusta dipende dal proprio gusto e ovviamente dalla distribuzione Linux in uso. I valori di runlevel più comuni sulle workstation, sono: <tt/2/, <tt/3/ e <tt/5/. Degli esempi sono: <tt>/etc/rc?.d/</tt> (sostuire il ? con il giusto runlevel) <newline> Inoltre, bisogna farsi un idea di quando le proprie interfacce di rete devono essere attivate. Per ora si assume che le interfacce sono attivate alla priorità di sistema <tt/S/ per cui non dobbiamo tenerne conto. Se si ha la necessità di conoscere con esattezza il momento, si guardi in <tt>/etc/rcS.d/</tt>. Si vuole semplicemente che il bridge sia attivo il prima possibile per cui si imposta la priorità a <tt/10/. (Ci si assicuri che nessun servizio che richiede i dispositivi di bridging parta primai, che abbia cioè valore di priorità inferiore a <tt/10/) <newline> Per ora si assume che il proprio runlevel è <tt/5/: <tscreen> <verb> root@bridge:~> mv -i bridge.sh /etc/init.d/ root@bridge:~> cd /etc/rc5.d/ root@bridge:~> ln -s ../init.d/bridge.sh S10bridge.sh </verb> </tscreen> Di solito, tutte le distribuzioni forniscono qualche tipo di runlevel-checker o strumento equivalente che assiste nel noioso lavoro di amministrare i link di runlevel. Si consulti la documentazione della propria distribuzione su questo. <newline> Suggerimento: debian ha update-rc.d, redhat e successori hanno chkconfig. Infine, anche SuSE ha il suo (il nome del quale non riesco a ricordare facilmente..). <newline> Curiosità sul contenuto di bridge.sh? ;-) <tscreen> <verb> #!/bin/bash PATH="/sbin:/usr/sbin:/usr/local/sbin"; slaveIfs="1 2 3 4 6 7 8 9 10"; cmd="$1"; [ -z "$cmd" ] && cmd="start"; case "$cmd" in start) brctl addbr br0; brctl stp br0 on; brctl addif br0 eth0; brctl addif br0 eth1; (ifdown eth0 1>/dev/null 2>&1;); (ifdown eth1 1>/dev/null 2>&1;); ifconfig eth0 0.0.0.0 up; ifconfig eth1 0.0.0.0 up; ifconfig br0 10.0.3.129 broadcast 10.0.3.255 netmask 255.255.255.0 up ### Adapt to your needs. route add default gw 10.0.3.129; ### Adapt to your needs. for file in br0 eth0 eth1; do echo "1" > /proc/sys/net/ipv4/conf/${file}/proxy_arp; echo "1" > /proc/sys/net/ipv4/conf/${file}/forwarding; done; echo "1" > /proc/sys/net/ipv4/ip_forward; ;; stop) brctl delif br0 eth0; brctl delif br0 eth1; ifconfig br0 down; brctl delbr br0; #ifup eth0; ### Adapt to your needs. #ifup eth1; ### Adapt to your needs. ;; restart,reload) $0 stop; sleep 3; $0 start; ;; esac; </verb> </tscreen> E si, lo si renda eseguibile.. <tscreen> <verb> root@bridge:~> chmod 700 /etc/init.d/bridge.sh </verb> </tscreen> Dopo di questo, ci si assicuri che il bridge sopravviva a riavvii inattesi. È come per i backup: bisogna provarli prima che diventino necessari.     <sect>Provare il nuovo ambiente bridge! <label id="TESTING_Testing_grounds"> <sect1>Terreno di prova Si immagini uno scenario simile a questo: <tscreen> <verb> /\ Ethernet Ethernet ATM /-/ \ --------- --------- --------- /-/ | | Box |----------|Bridge |----------|Router |-----| Inter- \ --------- --------- --------- \ net ---| ^ ^ ^ ^ \ / | | | | \---/ eth0 eth0 eth1 if0 ^ | | | | | 10.0.3.2 none/10.0.3.1 195.137.15.7 anything else \ / \ / ^ \-br0-/ | ^ ^ | ^ | | | | | | own own foreign hostile </verb> </tscreen> Il proprio potere amministrativo si limita alle macchine contrassegnate con <tt/own/, il Router è completamente off-limits e così pure Internet, naturalmente. <newline> Se si vuole controllare il traffico da e per la rete si può decidere di integrare un firewall nel bridge. <newline> Il modo usuale di risolvere il problema consisterebbe nel cambiare il default gateway su tutti gli host della propria rete. Ma questo è un sistema piuttosto oneroso, nessuno vorrebbe cambiare più di 5 default route su 5 diversi host per più di una volta. Si tenga anche presente il dispendio di tempo. E non si dimentichi che questa soluzione potrebbe porre problematiche per quanto riguarda la sicurezza. <newline> L'altro sistema è più semplice, richiede meno tempo, è più sicuro e meno soggetto a errori. Più sicuro poiché non vi è necessità di assegnare alcun indirizzo IP. Niente IP, niente pericoli. Almeno in teoria, si spera, gli stack sono salvi. (In ogni caso sarebbe meglio non farci affidamento...). Il vantaggio quindi sta nell'avere un'installazione completamente trasparente, nessun IP e nessun MAC da cambiare. <newline> Ognuno sceglie il metodo che preferisce, qui verrà trattato solo il più elegante ;-) <sect1>Pingalo Jim! Si configurerà l'interfaccia eth0 della propria macchina come d'abitudine. Le interfacce del bridge saranno configurate come descritto nella sezione <ref id="SETUP_Linux_brctl" name="Configurazione">. <newline> <label id="TESTING_routing"> Se si desidera utilizzare l'inoltro (forwarding) si dovrà eseguire: <tscreen> <verb> root@bridge:~> echo "1" > /proc/sys/net/ipv4/ip_forward </verb> </tscreen> Opzionalmente si potrà configurare una default route: <tscreen> <verb> root@bridge:~> route add default gw 10.0.3.129 </verb> </tscreen> Quindi si imposteranno alcune regole di iptables sull' host <tt/bridge/: <label id="TESTING_iptables_listing"> <tscreen> <verb> root@bridge:~> iptables -P FORWARD DROP root@bridge:~> iptables -F FORWARD root@bridge:~> iptables -I FORWARD -j ACCEPT root@bridge:~> iptables -I FORWARD -j LOG root@bridge:~> iptables -I FORWARD -j DROP root@bridge:~> iptables -A FORWARD -j DROP root@bridge:~> iptables -x -v --line-numbers -L FORWARD </verb> </tscreen> L'ultima linea genera il seguente output: <tscreen> <verb> Chain FORWARD (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 1 0 0 DROP all -- any any anywhere anywhere 2 0 0 LOG all -- any any anywhere anywhere LOG level warning 3 0 0 ACCEPT all -- any any anywhere anywhere 4 0 0 DROP all -- any any anywhere anywhere </verb> </tscreen> Il <tt/LOG/ target inserisce fa il log di tutti i pacchetti attraverso <tt/syslogd/. Attenzione però, questo è da intendersi a solo scopo di testing, in un ambiente di produzione questa regola deve essere rimossa. Altrimenti si rischia di riempire i file di log e l'hard disk, oppure chiunque potrebbe usare questo sistema per un causare un Denial of Service. <newline> Per provare le regole si esegua un ping verso il router (195.137.15.7) sull'host <tt/box/: <tscreen> <verb> root@box:~> ping -c 3 195.137.15.7 PING router.provider.net (195.137.15.7) from 10.0.3.2 : 56(84) bytes of data. --- router.provider.net ping statistics --- 3 packets transmitted, 0 received, 100% loss, time 2020ms ^C root@box:~> </verb> </tscreen> Di default viene eseguito un <tt/DROP/ su ogni pacchetto. Nessuna risposta, nessun pacchetto nei log. Questa configurazione è progettata per scartare ogni pacchetto a meno che non si ometta la prima regola, subito prima di quella con il target <tt/LOG/: <tscreen> <verb> root@bridge:~> iptables -D FORWARD 1 root@bridge:~> iptables -x -v --line-numbers -L FORWARD </verb> </tscreen> Ora le regole diventano: <tscreen> <verb> Chain FORWARD (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination 2 0 0 LOG all -- any any anywhere anywhere LOG level warning 3 0 0 ACCEPT all -- any any anywhere anywhere 4 0 0 DROP all -- any any anywhere anywhere </verb> </tscreen> E tutti i pacchetti possono attraversare il bridge. Proviamo con un ping dall'host <tt/box/: <tscreen> <verb> root@box:~> ping -c 3 195.137.15.7 PING router.provider.net (195.137.15.7) from 10.0.3.2 : 56(84) bytes of data. 64 bytes from router.provider.net (195.137.15.7): icmp_seq=1 ttl=255 time=0.103 ms 64 bytes from router.provider.net (195.137.15.7): icmp_seq=2 ttl=255 time=0.082 ms 64 bytes from router.provider.net (195.137.15.7): icmp_seq=3 ttl=255 time=0.083 ms --- router.provider.net ping statistics --- 3 packets transmitted, 3 received, 0% loss, time 2002ms rtt min/avg/max/mdev = 0.082/0.089/0.103/0.012 ms root@box:~> </verb> </tscreen> Yippeah! il router è vivo e funzionante. <descrip> <tag/Nota Importante:/ <label id="TESTING_Important_note"> Quando viene attivata, l'interfaccia del bridge impiega circa 30 secondi per diventare completamente operativa. Questi 30 secondi sono la fase di apprendimento del bridge. Durante questo tempo il bridge esegue un test per stabilire quali indirizzi MAC esistono su quali porte. L'autore del codice, Lennert, dichiara nel suo TODO che la durata della fase di apprendimento verrà opportunatamente diminuita prima o poi. <newline> Si ricordi che durante la fase di test, nessun pacchetto attraverserà il bridge e nessun ping sarà possibile. </descrip> <sect1>Configurazione Attuale <label id="TESTING_actual_configuration"> Questa sezione vuole offrire alcuni suggerimenti relativi a come dovrebbe presentarsi il sistema dopo aver eseguito con successo quanto descritto in questo howto. <sect2>Configurazione dell'interfaccia L'output di <tt/ifconfig/ dovrebbe essere simile al seguente: <tscreen> <verb> root@bridge:~> ifconfig br0 Link encap:Ethernet HWaddr 00:04:75:81:D2:1D inet addr:10.0.3.129 Bcast:195.30.198.255 Mask:255.255.255.128 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:826 errors:0 dropped:0 overruns:0 frame:0 TX packets:737 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:161180 (157.4 Kb) TX bytes:66708 (65.1 Kb) eth0 Link encap:Ethernet HWaddr 00:04:75:81:ED:B7 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:5729 errors:0 dropped:0 overruns:0 frame:0 TX packets:3115 errors:0 dropped:0 overruns:0 carrier:656 collisions:0 txqueuelen:100 RX bytes:1922290 (1.8 Mb) TX bytes:298837 (291.8 Kb) Interrupt:11 Base address:0xe400 eth1 Link encap:Ethernet HWaddr 00:04:75:81:D2:1D UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:1 frame:0 TX packets:243 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:342 (342.0 b) TX bytes:48379 (47.2 Kb) Interrupt:7 Base address:0xe800 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:1034 errors:0 dropped:0 overruns:0 frame:0 TX packets:1034 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:82068 (80.1 Kb) TX bytes:82068 (80.1 Kb) </verb> </tscreen> <sect2>Configurazione del Routing L'output del proprio comando <tt/route/ dovrebbe assomigliare a: <tscreen> <verb> root@bridge:~> route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.3.129 0.0.0.0 255.255.255.128 U 0 0 0 br0 0.0.0.0 10.0.3.129 0.0.0.0 UG 0 0 0 br0 root@bridge:~> </verb> </tscreen> <sect2>Configurazione di Iptables Si legga la sezione <ref id="TESTING_iptables_listing" name="Pingalo Jim!">. <sect1>Nota finale (Importante!) <label id="final-note"> Mi piacerebbe avere vostre notizie! :-) <newline> Avete gradito il viaggio? <newline> Vi manca qualcosa? <newline> Avete bisogno di aiuto? (Chiedete al vostro assistente locale ;-) oppure rtfm. <newline> Siete ancora online? Allora mandatemi un messaggio via email. Mi farà contento. <newline> Volete mandarmi un assegno? Per favore non posso accettarli.. (Sto scherzando;) <newline> Date valore al mio tempo, semplicemente mandatemi qualche bella parola, è sufficiente. <newline> Niente motiva di più dei partecipanti felici che ti danno feedback positivi. <newline> Per cui, forza, spendete un minuto e scrivetemi un email! <newline> Grazie! <tscreen> <verb> Nils </verb> </tscreen> <sect1>Bug-Notes <label id="HINT_False_positive"> Pare vi sia un bug nel codice del br-nf: <tscreen> <verb> From: Bart De Schuymer <bart.de.schuymer_@_pandora.be> Date: Sun, 1 Sep 2002 21:52:46 +0200 To: Nils Radtke <Nils.Radtke_@_Think-Future.de> Subject: Re: Ethernet-Brigde-netfilter-HOWTO Ciao Nils, [...] Inoltre, il debugging del filtraggio dei pacchetti con la patch br-nf è in generale una cattiva idea. Possono essere segnalati molti falsi avvisi (relativi a presunti bug) nei log. [...] </verb> </tscreen> Personalmente non ho mai riscontrato falsi positivi nei miei log. Forse il bug è stato corretto. A questo proposito Bart ha scritto: <tscreen> <verb> From: Bart De Schuymer <bart.de.schuymer_@_pandora.be> Date: Mon, 2 Sep 2002 18:30:25 +0200 To: Nils Radtke <Nils.Radtke_@_Think-Future.de> Subject: Re: Ethernet-Brigde-netfilter-HOWTO On Monday 02 September 2002 00:39, Nils Radtke wrote: > La revisione del codice nf-debug nel br-nf sarà migliorata? Devo ammettere di non aver più fatto girare alcun kernel con il netfilter debugging attivo ultimamente. Di sicuro qualche mese fa generava dei falsi positivi (la mailing list sul bridge contiene diversi post su questo problema), mi è mancato il tempo di capire il motivo e se accade ancora. È nella mia lista delle cose da fare. [...] </verb> </tscreen> Ma (alla data attuale, 19-09-2002) non ho trovato un annuncio ufficiale che segnalasse la chiusura del bug. Si controlli costantemente la <ref id="LINK_Mailinglist" name="ethernet bridge mailinglist"> se si è interessati alla risoluzione del problema.     <sect>Esperienze degli utenti <label id="user-exp"> <sect1>Fedora Core 3 James Dinkel (jdinkel_ @ _gmail.com) ha scritto Martedi, 8 Mar 2005 10:59:22 -0600: <tscreen> <verb> [...] Sto usando Fedora Core 3 e tutto quello che ho dovuto fare è stato "yum install bridge-utils" per utilizzare il comando brctl. Non ho dovuto fare nessuna ricompilazione del kernel o configurazioni o giochetti con i moduli del kernel. E'stato molto facile. [...] </verb> </tscreen>     <sect>Links L'autore dell'howto può essere contattato via <htmlurl url="mailto:Ethernet-Bridge-netfilter-Howto_@_Think-Future.de" name="e-mail">. <newline> <htmlurl url="http://Think-Future.de/" name="Homepage dell'autore">. <sect1>Ethernet-Bridge <itemize> <item> <label id="LINK_Mailinglist"> <tt><htmlurl url="http://www.math.leidenuniv.nl/pipermail/bridge/" name="Ethernet Bridge Mailinglist"></tt> </item> <item> <label id="LINK_Bridge-home"> Utilità spazio utente, patch, ecc.: <tt><htmlurl url="http://bridge.sourceforge.net" name="Home of Linux kernel Ethernet Bridge"></tt> </item> <item> <label id="LINK_Bridge-stp-howto"> <tt><htmlurl url="http://www.tldp.org/HOWTO/BRIDGE-STP-HOWTO/index.html" name="Bridge-STP-HOWTO"></tt> </item> <item> <label id="LINK_Enterprise_fw"> <tt><htmlurl url="./additional_docs/Firewalling_for_Free.pdf" name="Firewalling for Free, Shawn Grimes"></tt> </item> </itemize> <sect1>Argomenti correlati: <itemize> <item> Filtraggio dei pacchetti, Ethernet-Bridging-Tables: <newline> <tt><htmlurl url="http://sourceforge.net/projects/ebtables" name="ebtables, sourceforge"></tt> <newline> <tt><htmlurl url="http://users.pandora.be/bart.de.schuymer/ebtables/properties.html" name="ebtables, caratteristiche supportate"></tt> <newline> <tt>ebtables, esempi: <htmlurl url="http://users.pandora.be/bart.de.schuymer/ebtables/examples.html" name="base">, <htmlurl url="http://users.pandora.be/bart.de.schuymer/ebtables/battlefield_examples.html" name="avanzati"></tt> </item> <item> IP mode, estensione Linux Bridge: <tt><htmlurl url="http://www.ssi.bg/~ja/" name="IP mode, LVS"></tt> </item> <item> Linux in ambienti High-Availability: <tt><htmlurl url="http://www.linux-ha.org/" name="High-Availability Linux"></tt> </item> <item> Linux Virtual Server: <tt><htmlurl url="http://www.linuxvirtualserver.org/" name="LVS"></tt> </item> </itemize>     </article>