Bunch of SGML and typo fixes.

Submitted by:	Alex Dupre <sysadmin@alexdupre.com>
PR:		docs/35430

1 files changed, 226 insertions, 214 deletions

diff --git a/it_IT.ISO8859-15/articles/filtering-bridges/article.sgml b/it_IT.ISO8859-15/articles/filtering-bridges/article.sgml
index f2f946136f..95934191f6 100644
--- a/it_IT.ISO8859-15/articles/filtering-bridges/article.sgml
+++ b/it_IT.ISO8859-15/articles/filtering-bridges/article.sgml
@@ -13,7 +13,6 @@
       <author>
         <firstname>Alex</firstname>
         <surname>Dupre</surname>
-        
         <affiliation>
           <address><email>sysadmin@alexdupre.com</email></address>
         </affiliation>
@@ -24,17 +23,17 @@
 
     <abstract>
       <para>Spesso &egrave; utile dividere una rete fisica (come una Ethernet)
-      in due segmenti separati, senza dover creare sottoreti e usare un router
-      per collegarli assieme. Il dispositivo che collega due reti insieme in
-      questo modo &egrave; chiamato bridge. Un sistema FreeBSD con due
-      interfacce di rete &egrave; sufficiente per raggiungere lo scopo.</para>
-
-      <para>Un bridge funziona individuando gli indirizzi del livello MAC
-      (indirizzi Ethernet) dei dispositivi collegati ad ognuna delle sue
-      interfacce di rete e inoltrando il traffico tra le due reti solo se il
-      mittente e il destinatario si trovano su segmenti differenti. Sotto
-      molti punti di vista un brigde &egrave; simile a uno switch Ethernet con
-      solo due porte.</para>
+        in due segmenti separati, senza dover creare sottoreti e usare un router
+        per collegarli assieme. Il dispositivo che collega due reti insieme in
+        questo modo &egrave; chiamato bridge. Un sistema FreeBSD con due
+        interfacce di rete &egrave; sufficiente per raggiungere lo scopo.</para>
+
+      <para>Un bridge funziona individuando gli indirizzi del livello
+        <acronym>MAC</acronym> (indirizzi Ethernet) dei dispositivi collegati ad
+        ognuna delle sue interfacce di rete e inoltrando il traffico tra le due
+        reti solo se il mittente e il destinatario si trovano su segmenti
+        differenti. Sotto molti punti di vista un brigde &egrave; simile a uno
+        switch Ethernet con solo due porte.</para>
     </abstract>
   </articleinfo>
 
@@ -42,29 +41,29 @@
     <title>Perch&egrave; usare un filtering bridge?</title>
 
     <para>Sempre pi&ugrave; frequentemente, grazie all'abbassamento dei costi
-    delle connessioni a banda larga (xDSL) e a causa della riduzione del numero
-    di indirizzi IPv4 disponibili, molte societ&agrave; si ritrovano collegate
-    ad Internet 24 ore su 24 e con un numero esiguo (a volte nemmeno una
-    potenza di 2) di indirizzi IP. In situazioni come queste spesso &egrave;
-    desiderabile avere un firewall che regoli i permessi di ingresso e uscita
-    per il traffico da e verso Internet, ma una soluzione basata sulle
-    funzionalit&agrave; di packet filtering dei router pu&ograve; non essere
-    applicabile, vuoi per problemi di suddivisione delle sottoreti, vuoi
-    perch&egrave; il router &egrave; di propriet&agrave; del fornitore di
-    accesso (ISP), vuoi perch&egrave; il router non supporta tali
-    funzionalit&agrave;. E' in questi casi che l'utilizzo di un filtering bridge
-    diventa altamente consigliato.</para>
+      delle connessioni a banda larga (xDSL) e a causa della riduzione del
+      numero di indirizzi IPv4 disponibili, molte societ&agrave; si ritrovano
+      collegate ad Internet 24 ore su 24 e con un numero esiguo (a volte nemmeno
+      una potenza di 2) di indirizzi IP. In situazioni come queste spesso
+      &egrave; desiderabile avere un firewall che regoli i permessi di ingresso
+      e uscita per il traffico da e verso Internet, ma una soluzione basata
+      sulle funzionalit&agrave; di packet filtering dei router pu&ograve; non
+      essere applicabile, vuoi per problemi di suddivisione delle sottoreti,
+      vuoi perch&egrave; il router &egrave; di propriet&agrave; del fornitore di
+      accesso (<acronym>ISP</acronym>), vuoi perch&egrave; il router non
+      supporta tali funzionalit&agrave;. &Egrave; in questi casi che l'utilizzo
+      di un filtering bridge diventa altamente consigliato.</para>
     
     <para>Un firewall basato su bridge pu&ograve; essere configurato e inserito
-    direttamente tra il router xDSL e il vostro hub/switch Ethernet senza alcun
-    problema di assegnazione di indirizzi IP.</para>
+      direttamente tra il router xDSL e il vostro hub/switch Ethernet senza
+      alcun problema di assegnazione di indirizzi IP.</para>
     
     <note>
       <para>La traduzione italiana di "firewall" &egrave; "muro anti incendio",
-      <emphasis>non</emphasis> "muro di fuoco" come molti pensano. Nel corso
-      dell'articolo, comunque, manterr&ograve; i termini tecnici nella loro
-      lingua originale in modo da non creare confusione o
-      ambiguit&agrave;.</para>
+        <emphasis>non</emphasis> "muro di fuoco" come molti pensano. Nel corso
+        dell'articolo, comunque, manterr&ograve; i termini tecnici nella loro
+        lingua originale in modo da non creare confusione o
+        ambiguit&agrave;.</para>
     </note>
   </sect1>
 
@@ -72,63 +71,66 @@
     <title>Metodi d'installazione</title>
     
     <para>Aggiungere le funzionalit&agrave; di bridge a una macchina FreeBSD non
-    &egrave; difficile. Dalla release 4.5 &egrave; possibile caricare tali
-    funzionalit&agrave; come moduli anzich&egrave; dover ricompilare il kernel,
-    semplificando di gran lunga la procedura. Nelle prossime sottosezioni
-    spiegher&ograve; entrambi i metodi di installazione.</para>
+      &egrave; difficile. Dalla release 4.5 &egrave; possibile caricare tali
+      funzionalit&agrave; come moduli anzich&egrave; dover ricompilare il
+      kernel, semplificando di gran lunga la procedura. Nelle prossime
+      sottosezioni spiegher&ograve; entrambi i metodi di installazione.</para>
     
     <important>
       <para><emphasis>Non</emphasis> seguite entrambe le istruzioni: le
-      procedure sono <emphasis>a esclusione</emphasis>. Scegliete l'alternativa
-      che meglio si adatta alle vostre esigenze e capacit&agrave;.</para>
+        procedure sono <emphasis>a esclusione</emphasis>. Scegliete
+        l'alternativa che meglio si adatta alle vostre esigenze e
+        capacit&agrave;.</para>
     </important>
     
     <para>Prima di continuare &egrave; necessario assicurarsi di avere almeno
-    due schede di rete Ethernet che supportino la modalit&agrave; promiscua sia
-    in ricezione che in trasmissione, difatti devono essere in grado di inviare
-    pacchetti Ethernet con qualunque indirizzo, non solo il loro. Inoltre, per
-    avere un buon rendimento, le schede dovrebbero essere di tipo PCI bus
-    mastering. Le scelte migliori sono ancora le Intel EtherExpress Pro seguite
-    dalle 3Com 3c9xx subito dopo. Per comodit&agrave; nella configurazione del
-    firewall pu&ograve; essere utile avere due schede di marche differenti (che
-    usino drivers differenti) in modo da distinguere chiaramente quale
-    interfaccia sia collegata al router e quale alla rete interna.</para>
+      due schede di rete Ethernet che supportino la modalit&agrave; promiscua
+      sia in ricezione che in trasmissione, difatti devono essere in grado di
+      inviare pacchetti Ethernet con qualunque indirizzo, non solo il loro.
+      Inoltre, per avere un buon rendimento, le schede dovrebbero essere di
+      tipo PCI bus mastering. Le scelte migliori sono ancora le Intel
+      EtherExpress Pro seguite dalle 3Com 3c9xx subito dopo. Per comodit&agrave;
+      nella configurazione del firewall pu&ograve; essere utile avere due schede
+      di marche differenti (che usino drivers differenti) in modo da distinguere
+      chiaramente quale interfaccia sia collegata al router e quale alla rete
+      interna.</para>
     
     <sect2 id="filtering-bridges-kernel">
       <title>Configurazione del Kernel</title>
           
-      <para>Cos&igrave; avete deciso di utilizzare il piu' vecchio e collaudato
-      metodo di installazione. Per prima cosa bisogna aggiungere le seguenti
-      righe al file di configurazione del kernel:</para>
+      <para>Cos&igrave; avete deciso di utilizzare il pi&ugrave; vecchio e
+        collaudato metodo di installazione. Per prima cosa bisogna aggiungere le
+        seguenti righe al file di configurazione del kernel:</para>
       
-<programlisting>options BRIDGE
+    <programlisting>options BRIDGE
 options IPFIREWALL
 options IPFIREWALL_VERBOSE</programlisting>
       
       <para>La prima riga serve a compilare il supporto per il bridge, la
-      seconda il firewall e la terza le funzioni di logging del firewall.</para>
+        seconda il firewall e la terza le funzioni di logging del firewall.
+      </para>
       
       <para>Adesso &egrave; necessario compilare e installare il nuovo kernel.
-      Si possono trovare le istruzioni nella sezione <ulink
-      url="../../../en_US.ISO8859-1/books/handbook/kernelconfig-building.html">
-      Building and Installing a Custom Kernel</ulink> dell'handbook.</para>
+        Si possono trovare le istruzioni nella sezione <ulink
+          url="../../../en_US.ISO8859-1/books/handbook/kernelconfig-building.html">
+        Building and Installing a Custom Kernel</ulink> dell'handbook.</para>
     </sect2>
 
     <sect2 id="filtering-bridges-modules">
       <title>Caricamento dei Moduli</title>
       
       <para>Se avete deciso di usare il nuovo e pi&ugrave; semplice metodo di
-      installazione, l'unica cosa da fare &egrave; aggiungere la seguente riga
-      al file <filename>/boot/loader.conf</filename>:</para>
+        installazione, l'unica cosa da fare &egrave; aggiungere la seguente riga
+        al file <filename>/boot/loader.conf</filename>:</para>
           
       <programlisting>bridge_load="YES"</programlisting>
       
       <para>In questo modo all'avvio della macchina verr&agrave; caricato
-      insieme al kernel anche il modulo <filename>bridge.ko</filename>. Non
-      &egrave; necessario invece aggiungere una riga per il modulo
-      <filename>ipfw.ko</filename> in quanto verr&agrave; caricato in automatico
-      dallo script <filename>/etc/rc.network</filename> dopo aver seguito i
-      passi della prossima sezione.</para>
+        insieme al kernel anche il modulo <filename>bridge.ko</filename>. Non
+        &egrave; necessario invece aggiungere una riga per il modulo
+        <filename>ipfw.ko</filename> in quanto verr&agrave; caricato in
+        automatico dallo script <filename>/etc/rc.network</filename> dopo aver
+        seguito i passi della prossima sezione.</para>
     </sect2>
   </sect1>
 
@@ -136,145 +138,153 @@ options IPFIREWALL_VERBOSE</programlisting>
     <title>Preparativi finali</title>
 
     <para>Prima di riavviare per caricare il nuovo kernel o i moduli richiesti
-    (a seconda del metodo che avete scelto in precedenza), bisogna effettuare
-    alcune modifiche al file <filename>/etc/rc.conf</filename>. La regola di
-    default del firewall &egrave; di rifiutare tutti i pacchetti IP. Per
-    iniziare attiviamo il firewall in modalit&agrave; 'open', in modo da
-    verificare il suo funzionamento senza alcun problema di filtraggio pacchetti
-    (nel caso stiate eseguendo questa procedura da remoto, tale accorgimento vi
-    consentir&agrave; di non rimanere erroneamente tagliati fuori dalla rete).
-    Inserite queste linee nel file <filename>/etc/rc.conf</filename>:</para>
-
-<programlisting>firewall_enable="YES"
+      (a seconda del metodo che avete scelto in precedenza), bisogna effettuare
+      alcune modifiche al file <filename>/etc/rc.conf</filename>. La regola di
+      default del firewall &egrave; di rifiutare tutti i pacchetti IP. Per
+      iniziare attiviamo il firewall in modalit&agrave; 'open', in modo da
+      verificare il suo funzionamento senza alcun problema di filtraggio pacchetti
+      (nel caso stiate eseguendo questa procedura da remoto, tale accorgimento vi
+      consentir&agrave; di non rimanere erroneamente tagliati fuori dalla rete).
+      Inserite queste linee nel file <filename>/etc/rc.conf</filename>:</para>
+
+    <programlisting>firewall_enable="YES"
 firewall_type="open"
 firewall_quiet="YES"
 firewall_logging="YES"</programlisting>
 
     <para>La prima riga serve ad attivare il firewall (e a caricare il modulo
-    <filename>ipfw.ko</filename> nel caso non fosse gi&agrave; compilato nel
-    kernel), la seconda a impostarlo in modalit&agrave; 'open' (come descritto
-    nel file <filename>/etc/rc.firewall</filename>), la terza a non visualizzare
-    il caricamento delle regole e la quarta ad abilitare il supporto per il
-    logging.</para>
+      <filename>ipfw.ko</filename> nel caso non fosse gi&agrave; compilato nel
+      kernel), la seconda a impostarlo in modalit&agrave; 'open' (come descritto
+      nel file <filename>/etc/rc.firewall</filename>), la terza a non
+      visualizzare il caricamento delle regole e la quarta ad abilitare il
+      supporto per il logging.</para>
 
     <para>Per quanto riguarda la configurazione delle interfacce di rete, il
-    metodo pi&ugrave; utilizzato &egrave; quello di assegnare un IP a solo una
-    delle schede di rete, ma il bridge funziona egualmente anche se entrambe o
-    nessuna delle interfacce ha IP settati. In quest'ultimo caso (IP-less) la
-    macchina bridge sar&agrave; ancora pi&ugrave; nascosta in quanto
-    inaccessibile dalla rete: per configurarla occorrer&agrave; quindi entrare
-    da console o tramite una terza interfaccia di rete separata dal bridge. A
-    volte all'avvio della macchina qualche programma richiede di accedere alla
-    rete, per esempio per una risoluzione di dominio: in questo caso &egrave;
-    necessario assegnare un IP all'interfaccia esterna (quella collegata a
-    Internet, dove risiede il server DNS), visto che il bridge verr&agrave;
-    attivato alla fine della procedura di avvio. Questo vuol dire che
-    l'interfaccia fxp0 (nel nostro caso) deve essere menzionata nella sezione
-    ifconfig del file <filename>/etc/rc.conf</filename>, mentre la xl0 no.
-    Assegnare IP a entrambe le schede di rete non ha molto senso, a meno che
-    durante la procedura di avvio non si debba accedere a servizi presenti su
-    entrambi i segmenti Ethernet.</para>
+      metodo pi&ugrave; utilizzato &egrave; quello di assegnare un IP a solo una
+      delle schede di rete, ma il bridge funziona egualmente anche se entrambe o
+      nessuna delle interfacce ha IP settati. In quest'ultimo caso (IP-less) la
+      macchina bridge sar&agrave; ancora pi&ugrave; nascosta in quanto
+      inaccessibile dalla rete: per configurarla occorrer&agrave; quindi entrare
+      da console o tramite una terza interfaccia di rete separata dal bridge. A
+      volte all'avvio della macchina qualche programma richiede di accedere alla
+      rete, per esempio per una risoluzione di dominio: in questo caso &egrave;
+      necessario assegnare un IP all'interfaccia esterna (quella collegata a
+      Internet, dove risiede il server <acronym>DNS</acronym>), visto che il
+      bridge verr&agrave; attivato alla fine della procedura di avvio. Questo
+      vuol dire che l'interfaccia <devicename>fxp0</devicename> (nel nostro
+      caso) deve essere menzionata nella sezione ifconfig del file
+      <filename>/etc/rc.conf</filename>, mentre la <devicename>xl0</devicename>
+      no. Assegnare IP a entrambe le schede di rete non ha molto senso, a meno
+      che durante la procedura di avvio non si debba accedere a servizi presenti
+      su entrambi i segmenti Ethernet.</para>
     
     <para>C'&egrave; un'altra cosa importante da sapere. Quando si utilizza IP
-    sopra Ethernet ci sono due protocolli Ethernet in uso: uno &egrave; IP,
-    l'altro &egrave; ARP. ARP permette la conversione dell'indirizzo IP di una
-    macchina nel suo indirizzo Ethernet (livello MAC). Affinch&egrave; due
-    macchine separate dal bridge riescano a comunicare tra loro &egrave;
-    necessario che il bridge lasci passare i pacchetti ARP. Tale protocollo non
-    fa parte del livello IP, visto che &egrave; presente solo con IP sopra
-    Ethernet. Il firewall di FreeBSD agisce esclusivamente sul livello IP e
-    quindi tutti i pacchetti non IP (compreso ARP) verranno inoltrati senza
-    essere filtrati, anche se il firewall &egrave; configurato per non lasciar
-    passare nulla.</para>
+      sopra Ethernet ci sono due protocolli Ethernet in uso: uno &egrave; IP,
+      l'altro &egrave; <acronym>ARP</acronym>. <acronym>ARP</acronym> permette
+      la conversione dell'indirizzo IP di una macchina nel suo indirizzo
+      Ethernet (livello <acronym>MAC</acronym>). Affinch&egrave; due macchine
+      separate dal bridge riescano a comunicare tra loro &egrave; necessario che
+      il bridge lasci passare i pacchetti <acronym>ARP</acronym>. Tale
+      protocollo non fa parte del livello IP, visto che &egrave; presente solo
+      con IP sopra Ethernet. Il firewall di FreeBSD agisce esclusivamente sul
+      livello IP e quindi tutti i pacchetti non IP (compreso
+      <acronym>ARP</acronym>) verranno inoltrati senza essere filtrati, anche se
+      il firewall &egrave; configurato per non lasciar passare nulla.</para>
     
     <para>Ora &egrave; arrivato il momento di riavviare la macchina e usarla
-    come in precedenza: appariranno dei nuovi messaggi riguardo al bridge e al
-    firewall, ma il bridge non sar&agrave; attivato e il firewall, essendo in
-    modalit&agrave; 'open', non impedir&agrave; nessuna operazione.</para>
+      come in precedenza: appariranno dei nuovi messaggi riguardo al bridge e al
+      firewall, ma il bridge non sar&agrave; attivato e il firewall, essendo in
+      modalit&agrave; 'open', non impedir&agrave; nessuna operazione.</para>
     
     <para>Se ci dovessero essere dei problemi, &egrave; il caso di scoprire ora
-    da cosa derivino e risolverli prima di continuare.</para>
+      da cosa derivino e risolverli prima di continuare.</para>
   </sect1>
 
   <sect1 id="filtering-bridges-enabling">
     <title>Attivazione del Bridge</title>
     
     <para>A questo punto, per attivare il bridge, bisogna eseguire i seguenti
-    comandi (avendo l'accortezza di sostituire i nomi delle due interfacce di
-    rete fxp0 e xl0 con i propri):</para>
+      comandi (avendo l'accortezza di sostituire i nomi delle due interfacce di
+      rete <devicename>fxp0</devicename> e <devicename>xl0</devicename> con i
+      propri):</para>
 
-<screen>&prompt.root; <userinput>sysctl net.link.ether.bridge_cfg=fxp0:0,xl0:0</userinput>
+    <screen>&prompt.root; <userinput>sysctl net.link.ether.bridge_cfg=fxp0:0,xl0:0</userinput>
 &prompt.root; <userinput>sysctl net.link.ether.bridge_ipfw=1</userinput>
 &prompt.root; <userinput>sysctl net.link.ether.bridge=1</userinput></screen>
 
     <para>La prima riga specifica tra quali interfacce va attivato il bridge,
-    la seconda abilita il firewall sul bridge ed infine la terza attiva il
-    bridge.</para>
+      la seconda abilita il firewall sul bridge ed infine la terza attiva il
+      bridge.</para>
 
     <para>A questo punto dovrebbe essere possibile inserire la macchina tra
-    due gruppi di host senza che venga compromessa qualsiasi possibilit&agrave;
-    di comunicazione tra di loro. Se &egrave; cos&igrave;, il prossimo passo
-    &egrave; quello di aggiungere le parti net.link.ether.[blah]=[blah] di
-    queste righe al file <filename>/etc/sysctl.conf</filename>, in modo che
-    vengano eseguite all'avvio della macchina.</para>
+      due gruppi di host senza che venga compromessa qualsiasi
+      possibilit&agrave; di comunicazione tra di loro. Se &egrave; cos&igrave;,
+      il prossimo passo &egrave; quello di aggiungere le parti
+      <literal>net.link.ether.<replaceable>[blah]</replaceable>=<replaceable>[blah]</replaceable></literal>
+      di queste righe al file <filename>/etc/sysctl.conf</filename>, in modo che
+      vengano eseguite all'avvio della macchina.</para>
   </sect1>
   
   <sect1 id="filtering-bridges-ipfirewall">
     <title>Configurazione del Firewall</title>
     
     <para>Ora &egrave; arrivato il momento di creare il proprio file con le
-    regole per il firewall, in modo da rendere sicura la rete interna. Ci sono
-    delle complicazioni nel fare questo, perch&egrave; non tutte le
-    funzionalit&agrave; del firewall sono disponibili sui pacchetti inoltrati
-    dal bridge. Inoltre, c'&egrave; una differenza tra i pacchetti che stanno
-    per essere inoltrati dal bridge e quelli indirizzati alla macchina locale.
-    In generale, i pacchetti che entrano nel bridge vengono processati dal
-    firewall solo una volta, non due come al solito; infatti vengono filtrati
-    solo in ingresso, quindi qualsiasi regola che usi 'out' oppure 'xmit' non
-    verr&agrave; mai eseguita. Personalmente uso 'in via' che &egrave; una
-    sintassi pi&ugrave; antica, ma che ha un senso quando la si legge. Un'altra
-    limitazione &egrave; che si possono usare solo i comandi 'pass' e 'drop' per
-    i pacchetti filtrati dal bridge. Cose avanzate come 'divert', 'forward' o
-    'reject' non sono disponibili. Queste opzioni possono ancora essere usate,
-    ma solo per il traffico da e verso la macchina bridge stessa (sempre che le
-    sia stato assegnato un IP).</para>
+      regole per il firewall, in modo da rendere sicura la rete interna. Ci sono
+      delle complicazioni nel fare questo, perch&egrave; non tutte le
+      funzionalit&agrave; del firewall sono disponibili sui pacchetti inoltrati
+      dal bridge. Inoltre, c'&egrave; una differenza tra i pacchetti che stanno
+      per essere inoltrati dal bridge e quelli indirizzati alla macchina locale.
+      In generale, i pacchetti che entrano nel bridge vengono processati dal
+      firewall solo una volta, non due come al solito; infatti vengono filtrati
+      solo in ingresso, quindi qualsiasi regola che usi 'out' oppure 'xmit' non
+      verr&agrave; mai eseguita. Personalmente uso 'in via' che &egrave; una
+      sintassi pi&ugrave; antica, ma che ha un senso quando la si legge.
+      Un'altra limitazione &egrave; che si possono usare solo i comandi 'pass' e
+      'drop' per i pacchetti filtrati dal bridge. Cose avanzate come 'divert',
+      'forward' o 'reject' non sono disponibili. Queste opzioni possono ancora
+      essere usate, ma solo per il traffico da e verso la macchina bridge stessa
+      (sempre che le sia stato assegnato un IP).</para>
 
     <para>Nuovo in FreeBSD 4.0 &egrave; il concetto di stateful filtering.
-    Questo &egrave; un grande miglioramento per il traffico UDP, che consiste
-    tipicamente di una richiesta in uscita, seguita a breve termine da una
-    risposta con la stessa coppia di indirizzi IP e numeri di porta (ma con
-    mittente e destinatario invertiti, ovviamente). Per i firewall che non
-    supportano il mantenimento di stato, non c'&egrave; modo di gestire questo
-    breve scambio di dati come una sessione unica. Ma con un firewall che
-    pu&ograve; "ricordarsi" di un pacchetto UDP in uscita e permette una
-    risposta nei minuti successivi, gestire i servizi UDP &egrave; semplice.
-    L'esempio seguente mostra come fare. La stessa cosa &egrave; possibile farla
-    con i pacchetti TCP. Questo permette di evitare qualche tipo di attacco
-    denial of service e altri sporchi trucchi, ma tipicamente fa anche crescere
-    velocemente la tabella di stato.</para>
+      Questo &egrave; un grande miglioramento per il traffico
+      <acronym>UDP</acronym>, che consiste tipicamente di una richiesta in
+      uscita, seguita a breve termine da una risposta con la stessa coppia di
+      indirizzi IP e numeri di porta (ma con mittente e destinatario invertiti,
+      ovviamente). Per i firewall che non supportano il mantenimento di stato,
+      non c'&egrave; modo di gestire questo breve scambio di dati come una
+      sessione unica. Ma con un firewall che pu&ograve; "ricordarsi" di un
+      pacchetto <acronym>UDP</acronym> in uscita e permette una risposta nei
+      minuti successivi, gestire i servizi <acronym>UDP</acronym> &egrave;
+      semplice. L'esempio seguente mostra come fare. La stessa cosa &egrave;
+      possibile farla con i pacchetti <acronym>TCP</acronym>. Questo permette di
+      evitare qualche tipo di attacco denial of service e altri sporchi trucchi,
+      ma tipicamente fa anche crescere velocemente la tabella di stato.</para>
 
     <para>Vediamo un esempio di configurazione. Bisogna notare che all'inizio
-    del file <filename>/etc/rc.firewall</filename> ci sono gi&agrave; delle
-    regole standard per l'interfaccia di loopback (lo0), quindi non ce ne
-    occuperemo pi&ugrave; ora. Le regole personalizzate andrebbero messe in un
-    file a parte (per esempio <filename>/etc/rc.firewall.local</filename>) e
-    caricate all'avvio modificando la riga del file
-    <filename>/etc/rc.conf</filename> dove era stata definita la modalit&agrave;
-    'open' con:</para>
-
-<programlisting>firewall_type="/etc/rc.firewall.local"</programlisting>
-
-    <important><para>Bisogna specificare il path <emphasis>completo</emphasis>
-    del file, altrimenti non verr&agrave; caricato con il rischio di rimanere
-    tagliati fuori dalla rete.</para></important>
-
-    <para>Per il nostro esempio immaginiamo di avere l'interfaccia fxp0
-    collegata all'esterno (Internet) e la xl0 verso l'interno (LAN). La macchina
-    bridge ha assegnato l'IP 1.2.3.4 (&egrave; impossibile che il vostro ISP vi
-    assegni un indirizzo di classe A di questo tipo, ma per l'esempio va
-    bene).</para>
-
-<programlisting># Le connessioni di cui abbiamo mantenuto lo stato vengono fatte passare subito
+      del file <filename>/etc/rc.firewall</filename> ci sono gi&agrave; delle
+      regole standard per l'interfaccia di loopback
+      <devicename>lo0</devicename>, quindi non ce ne occuperemo pi&ugrave; ora.
+      Le regole personalizzate andrebbero messe in un file a parte (per esempio
+      <filename>/etc/rc.firewall.local</filename>) e caricate all'avvio
+      modificando la riga del file <filename>/etc/rc.conf</filename> dove era
+      stata definita la modalit&agrave; 'open' con:</para>
+
+    <programlisting>firewall_type="/etc/rc.firewall.local"</programlisting>
+
+    <important>
+      <para>Bisogna specificare il path <emphasis>completo</emphasis>
+        del file, altrimenti non verr&agrave; caricato con il rischio di
+        rimanere tagliati fuori dalla rete.</para>
+    </important>
+
+    <para>Per il nostro esempio immaginiamo di avere l'interfaccia
+      <devicename>fxp0</devicename> collegata all'esterno (Internet) e la
+      <devicename>xl0</devicename> verso l'interno (<acronym>LAN</acronym>). La
+      macchina bridge ha assegnato l'IP <hostid role="ipaddr">1.2.3.4</hostid>
+      (&egrave; impossibile che il vostro <acronym>ISP</acronym> vi assegni un
+      indirizzo di classe A di questo tipo, ma per l'esempio va bene).</para>
+
+    <programlisting># Le connessioni di cui abbiamo mantenuto lo stato vengono fatte passare subito
 add check-state
 
 # Esclude le reti locali definite nell'RFC 1918
@@ -298,9 +308,9 @@ add pass ip from any to any in via xl0
 add pass tcp from any to any 22 in via fxp0 setup keep-state
 # Permette SMTP solo verso il mail server
 add pass tcp from any to relay 25 in via fxp0 setup keep-state
-# Permette i trasferimenti di zona solo dal name server secondario
+# Permette i trasferimenti di zona solo dal name server secondario [dns2.nic.it]
 add pass tcp from 193.205.245.8 to ns 53 in via fxp0 setup keep-state
-# Lascia passare le richieste ident: &egrave; meglio piuttosto che aspettare che vadano in timeout
+# Lascia passare i controlli ident: &egrave; meglio che aspettare che vadano andare in timeout
 add pass tcp from any to any 113 in via fxp0 setup keep-state
 # Permette connessioni nel range di "quarantena".
 add pass tcp from any to any 49152-65535 in via fxp0 setup keep-state
@@ -322,70 +332,72 @@ add pass icmp from any to any icmptypes 11
 add drop log all from any to any</programlisting>
 
     <para>Coloro che hanno configurato un firewall in precedenza potrebbero aver
-    notato che manca qualcosa. In particolare, non ci sono regole contro lo
-    spoofing, difatti <emphasis>non</emphasis> abbiamo aggiunto:</para>
+      notato che manca qualcosa. In particolare, non ci sono regole contro lo
+      spoofing, difatti <emphasis>non</emphasis> abbiamo aggiunto:</para>
 
-<programlisting>add deny all from 1.2.3.4/8 to any in via fxp0</programlisting>
+    <programlisting>add deny all from 1.2.3.4/8 to any in via fxp0</programlisting>
 
     <para>Ovvero, non far entrare dall'esterno pacchetti che affermano di venire
-    dalla rete interna. Questa &egrave; una cosa che solitamente viene fatta per
-    essere sicuri che qualcuno non provi a eludere il packet filter, generando
-    falsi pacchetti che sembrano venire dall'interno. Il problema &egrave; che
-    c'&egrave; <emphasis>almeno</emphasis> un host sull'interfaccia esterna che
-    non si pu&ograve; ignorare: il router. Solitamente, per&ograve;, gli ISP
-    eseguono il controllo anti-spoof sui loro router e quindi non ce ne dobbiamo
-    preoccupare.</para>
+      dalla rete interna. Questa &egrave; una cosa che solitamente viene fatta
+      per essere sicuri che qualcuno non provi a eludere il packet filter,
+      generando falsi pacchetti che sembrano venire dall'interno. Il problema
+      &egrave; che c'&egrave; <emphasis>almeno</emphasis> un host
+      sull'interfaccia esterna che non si pu&ograve; ignorare: il router.
+      Solitamente, per&ograve;, gli <acronym>ISP</acronym> eseguono il controllo
+      anti-spoof sui loro router e quindi non ce ne dobbiamo preoccupare.</para>
 
     <para>L'ultima riga sembra un duplicato della regola di default, ovvero non
-    far passare nulla che non sia stato specificatamente permesso. In
-    verit&agrave; c'&egrave; una differenza: tutto il traffico sospetto
-    verr&agrave; loggato.</para>
-
-    <para>Ci sono due regole per permettere il traffico SMTP e DNS verso il mail
-    server e il name server, se ne avete. Ovviamente l'intero set di regole deve
-    essere personalizzato per le proprie esigenze, questo non &egrave; altro che
-    uno specifico esempio (il formato delle regole &egrave; spiegato
-    dettagliatamente nella man page &man.ipfw.8;). Bisogna notare che,
-    affinch&egrave; 'relay' e 'ns' siano interpretati correttamente, la
-    risoluzione dei nomi deve funzionare PRIMA che il bridge sia attivato.
-    Questo &egrave; un chiaro esempio che dimostra l'importanza di settare l'IP
-    sulla corretta scheda di rete. In alternativa &egrave; possibile specificare
-    direttamente l'indirizzo IP anzich&egrave; il nome host (cosa necessaria se
-    la macchina &egrave; IP-less).</para>
+      far passare nulla che non sia stato specificatamente permesso. In
+      verit&agrave; c'&egrave; una differenza: tutto il traffico sospetto
+      verr&agrave; loggato.</para>
+
+    <para>Ci sono due regole per permettere il traffico <acronym>SMTP</acronym>
+      e <acronym>DNS</acronym> verso il mail server e il name server, se ne
+      avete. Ovviamente l'intero set di regole deve    essere personalizzato
+      per le proprie esigenze, questo non &egrave; altro che uno specifico
+      esempio (il formato delle regole &egrave; spiegato dettagliatamente nella
+      man page &man.ipfw.8;). Bisogna notare che, affinch&egrave; 'relay' e 'ns'
+      siano interpretati correttamente, la risoluzione dei nomi deve funzionare
+      <emphasis>prima</emphasis> che il bridge sia attivato. Questo &egrave; un
+      chiaro esempio che dimostra l'importanza di settare l'IP sulla corretta
+      scheda di rete. In alternativa &egrave; possibile specificare direttamente
+      l'indirizzo IP anzich&egrave; il nome host (cosa necessaria se la macchina
+      &egrave; IP-less).</para>
 
     <para>Le persone che sono solite configurare un firewall probabilmente
-    avranno sempre usato una regola 'reset' o 'forward' per i pacchetti
-    ident (porta 113 TCP). Sfortunatamente, questa non &egrave; una scelta
-    applicabile con il bridge, quindi la cosa migliore &egrave; lasciarli
-    passare fino alla destinazione. Finch&egrave; la macchina di destinazione
-    non ha un demone ident attivo, questa tecnica &egrave; relativamente
-    sicura. L'alternativa &egrave; proibire le connessioni sulla porta 113,
-    creando qualche problema con servizi tipo IRC (le richieste ident devono
-    andare in timeout).</para>
+      avranno sempre usato una regola 'reset' o 'forward' per i pacchetti
+      ident (porta 113 <acronym>TCP</acronym>). Sfortunatamente, questa non
+      &egrave; una scelta applicabile con il bridge, quindi la cosa migliore
+      &egrave; lasciarli passare fino alla destinazione. Finch&egrave; la
+      macchina di destinazione non ha un demone ident attivo, questa tecnica
+      &egrave; relativamente sicura. L'alternativa &egrave; proibire le
+      connessioni sulla porta 113, creando qualche problema con servizi tipo
+      <acronym>IRC</acronym> (le richieste ident devono andare in
+      timeout).</para>
 
     <para>L'unica altra cosa un po' particolare che potete aver notato &egrave;
-    che c'&egrave; una regola per lasciar comunicare la macchina bridge e
-    un'altra per gli host della rete interna. Ricordate che questo &egrave;
-    dovuto al fatto che i due tipi di traffico prendono percorsi differenti
-    attraverso il kernel e di conseguenza anche dentro il packet filter. La
-    rete interna passer&agrave; attraverso il bridge, mentre la macchina
-    locale user&agrave; il normale stack IP per le connessioni. Perci&ograve;
-    due regole per gestire due casi differenti. Le regole 'in via fxp0'
-    funzionano in entrambi i casi. In generale, se usate regole 'in via'
-    attraverso il packet filter, dovrete fare un'eccezione per i pacchetti
-    generati localmente, in quanto non entrano tramite nessuna
-    interfaccia.</para>
+      che c'&egrave; una regola per lasciar comunicare la macchina bridge e
+      un'altra per gli host della rete interna. Ricordate che questo &egrave;
+      dovuto al fatto che i due tipi di traffico prendono percorsi differenti
+      attraverso il kernel e di conseguenza anche dentro il packet filter. La
+      rete interna passer&agrave; attraverso il bridge, mentre la macchina
+      locale user&agrave; il normale stack IP per le connessioni. Perci&ograve;
+      due regole per gestire due casi differenti. Le regole 'in via
+      <devicename>fxp0</devicename>' funzionano in entrambi i casi. In generale,
+      se usate regole 'in via' attraverso il packet filter, dovrete fare
+      un'eccezione per i pacchetti generati localmente, in quanto non entrano
+      tramite nessuna interfaccia.</para>
   </sect1>
 
   <sect1 id="filtering-bridges-contributors">
     <title>Contributi</title>
 
     <para>Alcune parti di questo articolo sono state prese, tradotte e
-    adattate da testi sui bridge, appartenenti alla documentazione di FreeBSD
-    in lingua inglese, a cura di Nick Sayer e Steve Peterson.</para>
+      adattate da testi sui bridge, appartenenti alla documentazione di FreeBSD
+      in lingua inglese, a cura di Nick Sayer e Steve Peterson.</para>
     
     <para>Un grosso ringraziamento va a Luigi Rizzo per l'implementazione
-    delle funzionalit&agrave; di bridging in FreeBSD e per il tempo che mi ha
-    dedicato rispondendo ad alcune mie domande a riguardo.</para>
-    </sect1>
+      delle funzionalit&agrave; di bridging in FreeBSD e per il tempo che mi ha
+      dedicato rispondendo ad alcune mie domande a riguardo.</para>
+  </sect1>
 </article>
\ No newline at end of file