Attachment 22831 Details for Bug 39510 – article_it.diff

[patch] article_it.diff

article_it.diff (text/plain), 23.87 KB, created by Alex Dupre on 2002-06-19 13:30:11 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Alex Dupre

Created: 2002-06-19 13:30:11 UTC

Size: 23.87 KB

patch

obsolete

>--- it_IT.ISO8859-15/articles/filtering-bridges/article.sgml.orig	Wed Jun 19 11:43:37 2002
>+++ it_IT.ISO8859-15/articles/filtering-bridges/article.sgml	Wed Jun 19 14:34:10 2002
>@@ -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
>-        questo modo &egrave; chiamato bridge. Un sistema FreeBSD con due
>+        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
>+        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
>@@ -60,7 +60,7 @@
>     
>     <note>
>       <para>La traduzione italiana di "firewall" &egrave; "muro anti incendio",
>-        <emphasis>non</emphasis> "muro di fuoco" come molti pensano. Nel corso
>+        <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>
>@@ -71,14 +71,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,27 +88,27 @@
>       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>
>+      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 pi&ugrave; vecchio e
>-        collaudato metodo di installazione. Per prima cosa bisogna aggiungere le
>-        seguenti righe al file di configurazione del kernel:</para>
>+        collaudato metodo di installazione.  Per prima cosa bisogna aggiungere
>+        le seguenti righe al file di configurazione del kernel:</para>
>       
>     <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
>@@ -126,7 +126,7 @@
>       <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,13 +139,14 @@
> 
>     <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>
>+      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; <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).  Inserite queste linee nel file
>+      <filename>/etc/rc.conf</filename>:</para>
> 
>     <programlisting>firewall_enable="YES"
> firewall_type="open"
>@@ -154,39 +155,39 @@
> 
>     <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
>+      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>
> 
>     <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 +195,8 @@
>     <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>
>@@ -218,7 +220,7 @@
> 
>     <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,45 +231,48 @@
>     <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&eacute; non tutte le
>+      regole per il firewall, in modo da rendere sicura la rete interna.  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 '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>
>+      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 <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>
> 
>     <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; "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>
>+      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; 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
>+    <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.
>       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>
> 
>@@ -279,7 +284,7 @@
> 
>     <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>).  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 +337,62 @@
> 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; '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&eacute; il nome host (cosa necessaria se la macchina
>-      &egrave; IP-less).</para>
>+      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 scheda di rete.  In
>+      alternativa &egrave; possibile specificare direttamente l'indirizzo IP
>+      anzich&eacute; 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 <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
>-      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>
>+      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 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;
>+      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;
>-      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>
>+      locale user&agrave; il normale stack IP per le connessioni.  Perci&ograve;
>+      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>
> 
>   <sect1 id="filtering-bridges-contributors">

Actions: View | Diff

Attachments on bug 39510: 22831