Various whitespaces and lines length fixes

PR:		docs/39510
Submitted by:	Alex Dupre <sysadmin@alexdupre.com>
Approved by:	keramida

it_IT.ISO8859-15/articles/filtering-bridges/article.sgml

@@ -24,15 +24,15 @@
     <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
+        per collegarli assieme.  Il dispositivo che collega due reti insieme in
-        questo modo &egrave; chiamato bridge. Un sistema FreeBSD con due
+        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
+        differenti.  Sotto molti punti di vista un brigde &egrave; simile a uno
         switch Ethernet con solo due porte.</para>
     </abstract>
   </articleinfo>
@@ -44,14 +44,14 @@
       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
+      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&eacute; il router &egrave; di propriet&agrave; del fornitore di
       accesso (<acronym>ISP</acronym>), vuoi perch&eacute; il router non
-      supporta tali funzionalit&agrave;. &Egrave; in questi casi che l'utilizzo
+      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
@@ -59,8 +59,9 @@
       alcun problema di assegnazione di indirizzi IP.</para>
     
     <note>
-      <para>La traduzione italiana di <quote>firewall</quote> &egrave; <quote>muro anti incendio</quote>,
+      <para>La traduzione italiana di <quote>firewall</quote> &egrave;
-        <emphasis>non</emphasis> <quote>muro di fuoco</quote> come molti pensano. Nel corso
+	<quote>muro anti incendio</quote>, <emphasis>non</emphasis>
+	<quote>muro di fuoco</quote> 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>
@@ -71,14 +72,14 @@
     <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
+      &egrave; difficile.  Dalla release 4.5 &egrave; possibile caricare tali
       funzionalit&agrave; come moduli anzich&eacute; dover ricompilare il
-      kernel, semplificando di gran lunga la procedura. Nelle prossime
+      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
+        procedure sono <emphasis>a esclusione</emphasis>.  Scegliete
         l'alternativa che meglio si adatta alle vostre esigenze e
         capacit&agrave;.</para>
     </important>
@@ -88,19 +89,20 @@
       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
+      tipo PCI bus mastering.  Le scelte migliori sono ancora le Intel
-      EtherExpress Pro seguite dalle 3Com 3c9xx subito dopo. Per comodit&agrave;
+      EtherExpress Pro seguite dalle 3Com 3c9xx subito dopo.  Per
-      nella configurazione del firewall pu&ograve; essere utile avere due schede
+      comodit&agrave; nella configurazione del firewall pu&ograve; essere
-      di marche differenti (che usino drivers differenti) in modo da distinguere
+      utile avere due schede di marche differenti (che usino drivers
-      chiaramente quale interfaccia sia collegata al router e quale alla rete
+      differenti) in modo da distinguere chiaramente quale interfaccia sia
-      interna.</para>
+      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 pi&ugrave; vecchio e
-        collaudato metodo di installazione. Per prima cosa bisogna aggiungere le
+        collaudato metodo di installazione.  Per prima cosa bisogna
-        seguenti righe al file di configurazione del kernel:</para>
+	aggiungere le seguenti righe al file di configurazione del
+	kernel:</para>
       
     <programlisting>options BRIDGE
 options IPFIREWALL
@@ -126,7 +128,7 @@ options IPFIREWALL_VERBOSE</programlisting>
       <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
+        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
@@ -139,12 +141,13 @@ options IPFIREWALL_VERBOSE</programlisting>
 
     <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
+      alcune modifiche al file <filename>/etc/rc.conf</filename>.  La regola di
-      default del firewall &egrave; di rifiutare tutti i pacchetti IP. Per
+      default del firewall &egrave; di rifiutare tutti i pacchetti IP.  Per
-      iniziare attiviamo il firewall in modalit&agrave; <option>open</option>, in modo da
+      iniziare attiviamo il firewall in modalit&agrave; <option>open</option>,
-      verificare il suo funzionamento senza alcun problema di filtraggio pacchetti
+      in modo da verificare il suo funzionamento senza alcun problema di
-      (nel caso stiate eseguendo questa procedura da remoto, tale accorgimento vi
+      filtraggio pacchetti (nel caso stiate eseguendo questa procedura da
-      consentir&agrave; di non rimanere erroneamente tagliati fuori dalla rete).
+      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"
@@ -154,39 +157,40 @@ 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; <option>open</option> (come descritto
+      kernel), la seconda a impostarlo in modalit&agrave;
-      nel file <filename>/etc/rc.firewall</filename>), la terza a non
+      <option>open</option> (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
+      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
+      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
+      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
+      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
+    <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; <acronym>ARP</acronym>. <acronym>ARP</acronym> permette
+      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&eacute; due macchine
+      Ethernet (livello <acronym>MAC</acronym>).  Affinch&eacute; due macchine
       separate dal bridge riescano a comunicare tra loro &egrave; necessario che
-      il bridge lasci passare i pacchetti <acronym>ARP</acronym>. Tale
+      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
+      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>
@@ -194,7 +198,8 @@ firewall_logging="YES"</programlisting>
     <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; <option>open</option>, non impedir&agrave; nessuna operazione.</para>
+      modalit&agrave; <option>open</option>, 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>
@@ -218,7 +223,7 @@ firewall_logging="YES"</programlisting>
 
     <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;,
+      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
@@ -229,38 +234,43 @@ firewall_logging="YES"</programlisting>
     <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
+      regole per il firewall, in modo da rendere sicura la rete interna.
-      delle complicazioni nel fare questo, perch&eacute; non tutte le
+      Ci sono delle complicazioni nel fare questo, perch&eacute; non tutte le
       funzionalit&agrave; del firewall sono disponibili sui pacchetti inoltrati
-      dal bridge. Inoltre, c'&egrave; una differenza tra i pacchetti che stanno
+      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 <option>out</option> oppure <option>xmit</option> non
+      solo in ingresso, quindi qualsiasi regola che usi <option>out</option>
-      verr&agrave; mai eseguita. Personalmente uso <option>in via</option> che &egrave; una
+      oppure <option>xmit</option> non verr&agrave; mai eseguita.  Personalmente
-      sintassi pi&ugrave; antica, ma che ha un senso quando la si legge.
+      uso <option>in via</option> che &egrave; una sintassi pi&ugrave; antica,
-      Un'altra limitazione &egrave; che si possono usare solo i comandi <option>pass</option> e
+      ma che ha un senso quando la si legge.
-      <option>drop</option> per i pacchetti filtrati dal bridge. Cose avanzate come <option>divert</option>,
+      Un'altra limitazione &egrave; che si possono usare solo i comandi
-      <option>forward</option> o <option>reject</option> non sono disponibili. Queste opzioni possono ancora
+      <option>pass</option> e <option>drop</option> per i pacchetti filtrati
-      essere usate, ma solo per il traffico da e verso la macchina bridge stessa
+      dal bridge.  Cose avanzate come <option>divert</option>,
-      (sempre che le sia stato assegnato un IP).</para>
+      <option>forward</option> o <option>reject</option> 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
       <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,
+      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; <quote>ricordarsi</quote> di un
+      sessione unica.  Ma con un firewall che pu&ograve;
-      pacchetto <acronym>UDP</acronym> in uscita e permette una risposta nei
+      <quote>ricordarsi</quote> di un pacchetto <acronym>UDP</acronym> in
-      minuti successivi, gestire i servizi <acronym>UDP</acronym> &egrave;
+      uscita e permette una risposta nei minuti successivi, gestire i
-      semplice. L'esempio seguente mostra come fare. La stessa cosa &egrave;
+      servizi <acronym>UDP</acronym> &egrave; semplice.
-      possibile farla con i pacchetti <acronym>TCP</acronym>. Questo permette di
+      L'esempio seguente mostra come fare.  La stessa cosa &egrave;
-      evitare qualche tipo di attacco denial of service e altri sporchi trucchi,
+      possibile farla con i pacchetti <acronym>TCP</acronym>.  Questo
-      ma tipicamente fa anche crescere velocemente la tabella di stato.</para>
+      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
+    <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
       <devicename>lo0</devicename>, quindi non ce ne occuperemo pi&ugrave; ora.
@@ -279,8 +289,9 @@ firewall_logging="YES"</programlisting>
 
     <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
+      <devicename>xl0</devicename> verso l'interno (<acronym>LAN</acronym>).
-      macchina bridge ha assegnato l'IP <hostid role="ipaddr">1.2.3.4</hostid>
+      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>
 
@@ -332,61 +343,63 @@ 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
+      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>
 
     <para>Ovvero, non far entrare dall'esterno pacchetti che affermano di venire
-      dalla rete interna. Questa &egrave; una cosa che solitamente viene fatta
+      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
+      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
+      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
+      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&eacute; <quote>relay</quote> e <quote>ns</quote>
+      man page &man.ipfw.8;).  Bisogna notare che, affinch&eacute;
+      <quote>relay</quote> e <quote>ns</quote>
       siano interpretati correttamente, la risoluzione dei nomi deve funzionare
-      <emphasis>prima</emphasis> che il bridge sia attivato. Questo &egrave; un
+      <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
+      scheda di rete.  In alternativa &egrave; possibile specificare
-      l'indirizzo IP anzich&eacute; il nome host (cosa necessaria se la macchina
+      direttamente l'indirizzo IP anzich&eacute; il nome host (cosa necessaria
-      &egrave; IP-less).</para>
+      se la macchina &egrave; IP-less).</para>
 
     <para>Le persone che sono solite configurare un firewall probabilmente
-      avranno sempre usato una regola <option>reset</option> o <option>forward</option> per i pacchetti
+      avranno sempre usato una regola <option>reset</option> o
-      ident (porta 113 <acronym>TCP</acronym>). Sfortunatamente, questa non
+      <option>forward</option> 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&eacute; la
+      &egrave; lasciarli passare fino alla destinazione.  Finch&eacute; la
       macchina di destinazione non ha un demone ident attivo, questa tecnica
-      &egrave; relativamente sicura. L'alternativa &egrave; proibire le
+      &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;
+      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
+      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;
+      locale user&agrave; il normale stack IP per le connessioni.  Perci&ograve;
-      due regole per gestire due casi differenti. Le regole <literal>in via
+      due regole per gestire due casi differenti.  Le regole <literal>in via
-      <devicename>fxp0</devicename></literal> funzionano in entrambi i casi. In generale,
+      <devicename>fxp0</devicename></literal> funzionano in entrambi i casi.
-      se usate regole <option>in via</option> attraverso il packet filter, dovrete fare
+      In generale, se usate regole <option>in via</option> attraverso il
-      un'eccezione per i pacchetti generati localmente, in quanto non entrano
+      packet filter, dovrete fare un'eccezione per i pacchetti generati
-      tramite nessuna interfaccia.</para>
+      localmente, in quanto non entrano tramite nessuna interfaccia.</para>
   </sect1>
 
   <sect1 id="filtering-bridges-contributors">