<!doctype linuxdoc system>
<!-- $Id: Ethernet-Bridge-netfilter-HOWTO.sgml,v 1.2 2005/07/13 13:26:25 gferg Exp $  -->
<!-- Last checkout: $Date: 2002/11/13 20:59:40 $  -->
<!-- Created: 2002-06-08, 10:59:43 Nils.Radtke_@_Think-Future.de  -->
<!-- Last modified: Wed 2005-07-13, 01:54:03 CEST (+0200) -> radtkens
        -->
<!-- Email updated versions to:
Mendel told me to send new versions to submit@en.tldp.org and subscribe to
http://lists.tldp.org/
  gleu@wanadoo.fr, emmajane@tldp.org, joyg@us.ibm.com, discuss@en.tldp.org
  with Subject:
  UPDATE: Ethernet Bridge + netfilter HOWTO
  Greg told me to send it additionally to these:
  submit@en.tldp.org gferg@fergusontechgroup.com
-->

<article>

<title>Ethernet Bridge + netfilter Howto

<author><htmlurl url="mailto:Nils.Radtke_@_Think-Future.de" name="Nils Radtke">

<date>v0.8, luglio 2005

<!--
       send email to jdinkel_@_gmail.com James Dinkel, jdinkel_@_gmail.com
-->


<abstract>
Installare un ethernet bridge offre la possibilit&agrave; di integrare in
una rete gi&agrave; 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>

<p>

Questo Howto &egrave; 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&ograve; 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 &egrave; c'&egrave; 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'&egrave; nessuna nota dei traduttori nel documento, grazie agli sconosciuti: <url
url="http://ftp-ildp.httpdnet.com/Ethernet-Bridge-netfilter-HOWTO" name="versione italiana">.

<p> 
<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 &egrave; una versione non aggiornata
di questo documento, sul sito www.tldp.org. Si utilizzi invece il presente, se si vuole
avere la versione pi&ugrave; 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
&quot;Argomenti Correlati&quot;.  Aggiunta una nota sul
<ref id="HINT_False_positive" name="&quot;falso positivo&quot; 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>


<!--  #################### -->
<!-- ### introduction ### -->
<sect>Introduzione
<p>
I bridge ethernet uniscono due o pi&ugrave; differenti segmenti ethernet
in maniera
trasparente.
<newline>
Un bridge ethernet smista i pacchetti in ingresso sulle porte associate con
l'interfaccia del bridge. Ci&ograve; 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.
<p>
Le interfacce ethernet possono essere aggiunte ad un'interfaccia bridge
gi&agrave; esistente e divenire quindi porte (logiche) di quest'ultima.
<p>
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 &egrave; possibile assegnare un indirizzo IP all'interfaccia
bridge per scopi amministrativi (chiaramente soltanto attraverso ssh ;-).
<p>
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&agrave; si traduce
in un alto costo).
<p>
Un altro caso comune &egrave; quello del cliente connesso alla rete globale
tramite un router concesso in uso. Poich&eacute; i provider raramente
concedono privilegi di amministrazione sul loro hardware, il cliente non
pu&ograve; cambiare la configurazione di connessione. Disponendo di una
rete funzionante e nell'intento di spendere meno possibile, non &egrave;
sua intenzione riconfigurarla interamente. Utilizzando un dispositivo di
bridging non &egrave; costretto a farlo.

<!--Bridging: Legt die Ethernet frames eines Segmentes auf das Interface
eines anderen Segmentes. FW auf der Ethernet Bridge ermoeglicht die
Verbindungskontrolle.
Eine Ethernet Bridge ist fuer die verbundenen Netzwerke nicht sichtbar.
Sie kann 2 oder mehr Ethernet Segmente verbinden, ohne Eingriff in die
bestehende Netzwerk-Topologie. Ein weiterer Vorteil eroeffnet sich, wenn
der Router nach extern nicht der eigenen Administration angehoert und
somit eine Modifikation der Netzwerk-Topologie ausgeschlossen ist.
-->

<!-- ### introduction ### -->
<!--  #################### -->


<!--  ############ -->
<!-- ### make ### -->
<sect>Software necessario
<p>
Questa &egrave; la configurazione software necessaria sul computer che
far&agrave; 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">
<p>
L'uso del kernel 2.6 non &egrave; ancora una buona idea. S&igrave, &egrave; 
strano. Il perch&egrave; e dove il codice di bridging
non funzioni non &egrave; ancora saltato fuori. Non
&egrave; 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 &egrave; 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 &egrave; gi&agrave; presente. Non &egrave; necessaria alcuna patch.
A proposito delle versioni pi&ugrave; recenti del kernel, bisogna precisare che la versione <em/2.4.23/  &egrave; la meno raccomandabile, in particolar modo se usata insieme a ebtables e netfilter-bridging. Sono raccomandate versioni pi&ugrave; recenti.
<newline>
Il paragrafo che segue &egrave; sorpassato (12-07-2005) poich&egrave; tutto 
quello di cui si necessita &egrave; disponibile nel kernel. Lo si pu&ograve;
tranquillamente saltare, viene mantenuto solo per ragioni storiche:<newline>
Se si ha intenzione di usare le risorse netfilter, perch&eacute; 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&agrave; 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, &egrave; ancora solo in tedesco. Ehm, dovrei metterlo a posto un giorno di questi, ma mi manca il tempo... Qualche volontario? (questo mortale silenzio &egrave; 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&agrave;
<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&agrave;  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&agrave; presente solo se &egrave; 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&agrave; a buon fine, tutto &egrave; 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/
<p>
Ora che il kernel &egrave; configurato con il supporto per l'Ethernet Bridge
e netfilter, si prepara lo strumento spazio utente <tt/brctl/. Questo &egrave;
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 &egrave; tutto. Si pu&ograve; procedere con la <ref
id="SETUP_Linux_brctl" name="Configurazione.">

<sect1> Note sul Kernel <label id="kernel-notes">
<p>
Sintomo: Durante la configurazione funziona tutto, ma i pacchetti non attraversano pi&ugrave; le interfacce del bridge come succedeva con il kernel 2.4.
<newline>
ipuk s (qasuari_ @ _yahoo.com) scrive (pi&ugrave; o meno a giugno 2005):
<tscreen>
        <verb>
[...]
Compilo il mio kernel dal 2.4.18-14 al 2.6.0 e attivo
bridge-netfilter&amp;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>

<!-- ### make ### -->
<!--  ############ -->

<!--  ############# -->
<!-- ### Setup ### -->
<sect>Configurare Linux<label id="SETUP_Linux_brctl">
<p>

<sect1>Configurare il bridge
<p>
&Egrave; 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'&egrave; un unico router, quindi un loop &egrave; molto
improbabile. Si pu&ograve; quindi disabilitare questa funzionalit&agrave;.
(La rete risulter&agrave; 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&ugrave;) interfacce fisiche, ci&ograve; 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&ugrave; 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 &egrave; 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 &egrave; 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&agrave;.
</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&igrave;, controllate ;-) Ma ora sono parte di un dispositivo bridge logico
e quindi non c'&egrave; 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&ograve; 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
<p>
<label id="BRIDGE_routing">
Nel caso in cui si intenda configurare un gateway si dovr&agrave; abilitare
l'inoltro (forwarding) nel kernel.
<tscreen>
	<verb>
root@bridge:~> echo "1" > /proc/sys/net/ipv4/ip_forward
	</verb>
</tscreen>
La macchina possiede gi&agrave; 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">
<p>
Meglio detto come: dobbiamo rendere le modifche permanenti al riavvio.
<newline>
Per ottenere questo, &egrave; 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&ugrave; 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&agrave; di sistema
<tt/S/ per cui non dobbiamo tenerne conto.
Se si ha la necessit&agrave; 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&agrave; a 
<tt/10/. (Ci si assicuri che nessun servizio che richiede i dispositivi di bridging
parta primai, che abbia cio&egrave; valore di priorit&agrave; inferiore a <tt/10/)
<newline>
Per ora si assume che il proprio runlevel &egrave; <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&agrave; 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. 
&Egrave; come per i backup: bisogna provarli prima che diventino necessari.


<!-- ### Setup ### -->
<!--  ############# -->

<!--  ############### -->
<!-- ### Testing ### -->
<sect>Provare il nuovo ambiente bridge! <label id="TESTING_Testing_grounds">
<p>



<sect1>Terreno di prova
<p>
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 &egrave; completamente off-limits
e cos&igrave; pure Internet, naturalmente.
<newline>
Se si vuole controllare il traffico da e per la rete si pu&ograve; 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 &egrave; un sistema
piuttosto oneroso, nessuno vorrebbe cambiare pi&ugrave; di 5 default route
su 5 diversi host per pi&ugrave; 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 &egrave; pi&ugrave; semplice, richiede meno tempo, &egrave;
pi&ugrave; sicuro e meno soggetto a errori.
Pi&ugrave; sicuro poich&eacute; non vi &egrave; necessit&agrave; 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&agrave; trattato solo il
pi&ugrave; elegante ;-)


<sect1>Pingalo Jim!
<p>
Si configurer&agrave; 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&agrave; eseguire:
<tscreen>
	<verb>
root@bridge:~> echo "1" > /proc/sys/net/ipv4/ip_forward
	</verb>
</tscreen>
Opzionalmente si potr&agrave; 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&ograve;, questo &egrave; 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 &egrave; 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 &egrave; 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&agrave; 
        opportunatamente diminuita prima o poi.
	<newline>
	Si ricordi che durante la fase di test, nessun pacchetto
	attraverser&agrave; il bridge e nessun ping sar&agrave; possibile.

</descrip>

<sect1>Configurazione Attuale
<p>
<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
<p>
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
<p>
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
<p>
Si legga la sezione
<ref id="TESTING_iptables_listing" name="Pingalo Jim!">.

<sect1>Nota finale (Importante!) <label id="final-note">
<p>
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&agrave; contento.
<newline>
Volete mandarmi un assegno? Per favore non posso accettarli.. (Sto scherzando;)
<newline>
Date valore al mio tempo, semplicemente mandatemi qualche bella parola, &egrave; sufficiente.
<newline>
Niente motiva di pi&ugrave; dei partecipanti felici che ti danno feedback positivi.
<newline>
Per cui, forza, spendete un minuto e scrivetemi un email!
<newline>
Grazie!
<p>
<tscreen>
        <verb>
Nils
        </verb>
</tscreen>


<sect1>Bug-Notes
<p>
<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 &egrave;
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 &egrave; 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&agrave; migliorata?

Devo ammettere di non aver pi&ugrave; 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 &egrave; mancato il tempo di capire
il motivo e se accade ancora. &Egrave 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 &egrave; interessati alla risoluzione del problema.

<!-- ### Testing ### -->
<!--  ############### -->

<!--  ######################## -->
<!-- ### user experiences ### -->
<sect>Esperienze degli utenti <label id="user-exp">
<p>
<sect1>Fedora Core 3
<p>
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 &egrave; 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>

<!-- ### user experiences ### -->
<!--  ######################## -->


<!--  ############# -->
<!-- ### links ### -->
<sect>Links
<p>
L'autore dell'howto pu&ograve; 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
<p>
<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&agrave; 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:
<p>
<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>

<!-- ### links ### -->
<!--  ############# -->


<!-- ### inf.misc_make ### -->
<!--  ###################### -->

</article>
<!-- EOF -->
<!-- vim:tw=256:et:sts=2:st=2:sw=2:com+=b\:###:fo+=cqtr:tags=ctags: 
-->
