MFen --> 1.11

PR:	docs/39510
Approved by:	keramida

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

@@ -59,8 +59,8 @@
       alcun problema di assegnazione di indirizzi IP.</para>
     
     <note>
-      <para>La traduzione italiana di "firewall" &egrave; "muro anti incendio",
+      <para>La traduzione italiana di <quote>firewall</quote> &egrave; <quote>muro anti incendio</quote>,
-        <emphasis>non</emphasis> "muro di fuoco" come molti pensano. Nel corso
+        <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>
@@ -141,7 +141,7 @@ options IPFIREWALL_VERBOSE</programlisting>
       (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
+      iniziare attiviamo il firewall in modalit&agrave; <option>open</option>, 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).
@@ -154,7 +154,7 @@ 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
+      kernel), la seconda a impostarlo in modalit&agrave; <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>
@@ -194,7 +194,7 @@ 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; 'open', 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>
@@ -236,12 +236,12 @@ firewall_logging="YES"</programlisting>
       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
+      solo in ingresso, quindi qualsiasi regola che usi <option>out</option> oppure <option>xmit</option> non
-      verr&agrave; mai eseguita. Personalmente uso 'in via' che &egrave; una
+      verr&agrave; mai eseguita. Personalmente uso <option>in via</option> 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
+      Un'altra limitazione &egrave; che si possono usare solo i comandi <option>pass</option> e
-      'drop' per i pacchetti filtrati dal bridge. Cose avanzate come 'divert',
+      <option>drop</option> per i pacchetti filtrati dal bridge. Cose avanzate come <option>divert</option>,
-      'forward' o 'reject' non sono disponibili. Queste opzioni possono ancora
+      <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>
 
@@ -252,7 +252,7 @@ firewall_logging="YES"</programlisting>
       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
+      sessione unica. Ma con un firewall che pu&ograve; <quote>ricordarsi</quote> 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;
@@ -267,7 +267,7 @@ firewall_logging="YES"</programlisting>
       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>
+      stata definita la modalit&agrave; <option>open</option> con:</para>
 
     <programlisting>firewall_type="/etc/rc.firewall.local"</programlisting>
 
@@ -356,7 +356,7 @@ add drop log all from any to any</programlisting>
       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; 'relay' e 'ns'
+      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
       chiaro esempio che dimostra l'importanza di settare l'IP sulla corretta
@@ -365,7 +365,7 @@ add drop log all from any to any</programlisting>
       &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
+      avranno sempre usato una regola <option>reset</option> o <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
@@ -382,9 +382,9 @@ add drop log all from any to any</programlisting>
       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
+      due regole per gestire due casi differenti. Le regole <literal>in via
-      <devicename>fxp0</devicename>' funzionano in entrambi i casi. In generale,
+      <devicename>fxp0</devicename></literal> funzionano in entrambi i casi. In generale,
-      se usate regole 'in via' attraverso il packet filter, dovrete fare
+      se usate regole <option>in via</option> attraverso il packet filter, dovrete fare
       un'eccezione per i pacchetti generati localmente, in quanto non entrano
       tramite nessuna interfaccia.</para>
   </sect1>