os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

MFen --> 1.11

Browse source 
PR:	docs/39510
Approved by:	keramida
This commit is contained in:
Marc Fonvieille 2002-06-22 10:34:09 +00:00
parent d705a8ef12
commit 2a361e6b84
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=13451
1 changed files with 17 additions and 17 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

34
it_IT.ISO8859-15/articles/filtering-bridges/article.sgml
View file

@ -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>