aboutsummaryrefslogtreecommitdiff
path: root/it_IT.ISO8859-15/articles
diff options
context:
space:
mode:
authorMarc Fonvieille <blackend@FreeBSD.org>2002-06-22 10:34:09 +0000
committerMarc Fonvieille <blackend@FreeBSD.org>2002-06-22 10:34:09 +0000
commit2a361e6b84be75d6cddf56463d7ffeac87292750 (patch)
tree49122dbae3e9c48cbb062b63a71dc1c3dd764558 /it_IT.ISO8859-15/articles
parentd705a8ef124c4524358d86c2546671cd11e6138d (diff)
downloaddoc-2a361e6b84be75d6cddf56463d7ffeac87292750.tar.gz
doc-2a361e6b84be75d6cddf56463d7ffeac87292750.zip
MFen --> 1.11
PR: docs/39510 Approved by: keramida
Notes
Notes: svn path=/head/; revision=13451
Diffstat (limited to 'it_IT.ISO8859-15/articles')
-rw-r--r--it_IT.ISO8859-15/articles/filtering-bridges/article.sgml34
1 files changed, 17 insertions, 17 deletions
diff --git a/it_IT.ISO8859-15/articles/filtering-bridges/article.sgml b/it_IT.ISO8859-15/articles/filtering-bridges/article.sgml
index 7b1c050f63..ffcd2104e7 100644
--- a/it_IT.ISO8859-15/articles/filtering-bridges/article.sgml
+++ b/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",
- <emphasis>non</emphasis> "muro di fuoco" come molti pensano. Nel corso
+ <para>La traduzione italiana di <quote>firewall</quote> &egrave; <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>
@@ -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
- verr&agrave; mai eseguita. Personalmente uso 'in via' che &egrave; una
+ solo in ingresso, quindi qualsiasi regola che usi <option>out</option> oppure <option>xmit</option> non
+ 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
- 'drop' per i pacchetti filtrati dal bridge. Cose avanzate come 'divert',
- 'forward' o 'reject' non sono disponibili. Queste opzioni possono ancora
+ Un'altra limitazione &egrave; che si possono usare solo i comandi <option>pass</option> e
+ <option>drop</option> per i pacchetti filtrati dal bridge. Cose avanzate come <option>divert</option>,
+ <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
- <devicename>fxp0</devicename>' funzionano in entrambi i casi. In generale,
- se usate regole 'in via' attraverso il packet filter, dovrete fare
+ due regole per gestire due casi differenti. Le regole <literal>in via
+ <devicename>fxp0</devicename></literal> funzionano in entrambi i casi. In generale,
+ 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>