aboutsummaryrefslogtreecommitdiff
path: root/it_IT.ISO8859-15/articles/filtering-bridges/article.xml
diff options
context:
space:
mode:
Diffstat (limited to 'it_IT.ISO8859-15/articles/filtering-bridges/article.xml')
-rw-r--r--it_IT.ISO8859-15/articles/filtering-bridges/article.xml65
1 files changed, 28 insertions, 37 deletions
diff --git a/it_IT.ISO8859-15/articles/filtering-bridges/article.xml b/it_IT.ISO8859-15/articles/filtering-bridges/article.xml
index e6c7a87667..8b5a6fe2e5 100644
--- a/it_IT.ISO8859-15/articles/filtering-bridges/article.xml
+++ b/it_IT.ISO8859-15/articles/filtering-bridges/article.xml
@@ -1,31 +1,23 @@
<?xml version="1.0" encoding="iso-8859-15"?>
-<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V4.5-Based Extension//EN"
- "../../../share/xml/freebsd45.dtd">
-
+<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook XML V5.0-Based Extension//EN"
+ "../../../share/xml/freebsd50.dtd">
<!--
The FreeBSD Italian Documentation Project
$FreeBSD$
Original revision: 1.21
-->
-
-<article lang="it">
- <articleinfo>
- <title>Filtering Bridges</title>
+<article xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:lang="it">
+ <info><title>Filtering Bridges</title>
+
<authorgroup>
- <author>
- <firstname>Alex</firstname>
-
- <surname>Dupre</surname>
-
- <affiliation>
+ <author><personname><firstname>Alex</firstname><surname>Dupre</surname></personname><affiliation>
<address><email>ale@FreeBSD.org</email></address>
- </affiliation>
- </author>
+ </affiliation></author>
</authorgroup>
- <legalnotice id="trademarks" role="trademarks">
+ <legalnotice xml:id="trademarks" role="trademarks">
&tm-attrib.freebsd;
&tm-attrib.3com;
&tm-attrib.intel;
@@ -50,9 +42,9 @@
differenti. Sotto molti punti di vista un brigde è simile a uno
switch Ethernet con solo due porte.</para>
</abstract>
- </articleinfo>
+ </info>
- <sect1 id="filtering-bridges-why">
+ <sect1 xml:id="filtering-bridges-why">
<title>Perché usare un filtering bridge?</title>
<para>Sempre più frequentemente, grazie all'abbassamento dei costi
@@ -83,7 +75,7 @@
</note>
</sect1>
- <sect1 id="filtering-bridges-how">
+ <sect1 xml:id="filtering-bridges-how">
<title>Metodi d'installazione</title>
<para>Aggiungere le funzionalità di bridge a una macchina FreeBSD non
@@ -111,7 +103,7 @@
differenti) in modo da distinguere chiaramente quale interfaccia sia
collegata al router e quale alla rete interna.</para>
- <sect2 id="filtering-bridges-kernel">
+ <sect2 xml:id="filtering-bridges-kernel">
<title>Configurazione del Kernel</title>
<para>Così avete deciso di utilizzare il più vecchio e
@@ -128,12 +120,11 @@ options IPFIREWALL_VERBOSE</programlisting>
</para>
<para>Adesso è necessario compilare e installare il nuovo kernel.
- Si possono trovare le istruzioni nella sezione <ulink
- url="&url.books.handbook;/kernelconfig-building.html">
- Building and Installing a Custom Kernel</ulink> dell'handbook.</para>
+ Si possono trovare le istruzioni nella sezione <link xlink:href="&url.books.handbook;/kernelconfig-building.html">
+ Building and Installing a Custom Kernel</link> dell'handbook.</para>
</sect2>
- <sect2 id="filtering-bridges-modules">
+ <sect2 xml:id="filtering-bridges-modules">
<title>Caricamento dei Moduli</title>
<para>Se avete deciso di usare il nuovo e più semplice metodo di
@@ -151,7 +142,7 @@ options IPFIREWALL_VERBOSE</programlisting>
</sect2>
</sect1>
- <sect1 id="filtering-bridges-finalprep">
+ <sect1 xml:id="filtering-bridges-finalprep">
<title>Preparativi finali</title>
<para>Prima di riavviare per caricare il nuovo kernel o i moduli richiesti
@@ -190,9 +181,9 @@ firewall_logging="YES"</programlisting>
necessario assegnare un IP all'interfaccia esterna (quella collegata a
Internet, dove risiede il server <acronym>DNS</acronym>), visto che il
bridge verrà attivato alla fine della procedura di avvio. Questo
- vuol dire che l'interfaccia <devicename>fxp0</devicename> (nel nostro
+ vuol dire che l'interfaccia <filename>fxp0</filename> (nel nostro
caso) deve essere menzionata nella sezione ifconfig del file
- <filename>/etc/rc.conf</filename>, mentre la <devicename>xl0</devicename>
+ <filename>/etc/rc.conf</filename>, mentre la <filename>xl0</filename>
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>
@@ -220,12 +211,12 @@ firewall_logging="YES"</programlisting>
da cosa derivino e risolverli prima di continuare.</para>
</sect1>
- <sect1 id="filtering-bridges-enabling">
+ <sect1 xml:id="filtering-bridges-enabling">
<title>Attivazione del Bridge</title>
<para>A questo punto, per attivare il bridge, bisogna eseguire i seguenti
comandi (avendo l'accortezza di sostituire i nomi delle due interfacce di
- rete <devicename>fxp0</devicename> e <devicename>xl0</devicename> con i
+ rete <filename>fxp0</filename> e <filename>xl0</filename> con i
propri):</para>
<screen>&prompt.root; <userinput>sysctl net.link.ether.bridge.config=fxp0:0,xl0:0</userinput>
@@ -246,12 +237,12 @@ firewall_logging="YES"</programlisting>
due gruppi di host senza che venga compromessa qualsiasi
possibilità di comunicazione tra di loro. Se è così,
il prossimo passo è quello di aggiungere le parti
- <literal>net.link.ether.bridge.<replaceable>[blah]</replaceable>=<replaceable>[blah]</replaceable></literal>
+ <literal>net.link.ether.bridge.[blah]=[blah]</literal>
di queste righe al file <filename>/etc/sysctl.conf</filename>, in modo che
vengano eseguite all'avvio della macchina.</para>
</sect1>
- <sect1 id="filtering-bridges-ipfirewall">
+ <sect1 xml:id="filtering-bridges-ipfirewall">
<title>Configurazione del Firewall</title>
<para>Ora è arrivato il momento di creare il proprio file con le
@@ -294,7 +285,7 @@ firewall_logging="YES"</programlisting>
<para>Vediamo un esempio di configurazione. Bisogna notare che all'inizio
del file <filename>/etc/rc.firewall</filename> ci sono già delle
regole standard per l'interfaccia di loopback
- <devicename>lo0</devicename>, quindi non ce ne occuperemo più ora.
+ <filename>lo0</filename>, quindi non ce ne occuperemo più 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
@@ -309,10 +300,10 @@ firewall_logging="YES"</programlisting>
</important>
<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>).
+ <filename>fxp0</filename> collegata all'esterno (Internet) e la
+ <filename>xl0</filename> verso l'interno (<acronym>LAN</acronym>).
La macchina bridge ha assegnato l'IP
- <hostid role="ipaddr">1.2.3.4</hostid>
+ <systemitem class="ipaddress">1.2.3.4</systemitem>
(è impossibile che il vostro <acronym>ISP</acronym> vi assegni un
indirizzo simile a questo, ma per l'esempio va bene).</para>
@@ -418,13 +409,13 @@ add drop log all from any to any</programlisting>
rete interna passerà attraverso il bridge, mentre la macchina
locale userà il normale stack IP per le connessioni. Perciò
due regole per gestire due casi differenti. Le regole <literal>in via
- <devicename>fxp0</devicename></literal> funzionano in entrambi i casi.
+ fxp0</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">
+ <sect1 xml:id="filtering-bridges-contributors">
<title>Contributi</title>
<para>Alcune parti di questo articolo sono state prese, tradotte e