Various whitespaces and lines length fixes
PR: docs/39510 Submitted by: Alex Dupre <sysadmin@alexdupre.com> Approved by: keramida
This commit is contained in:
Marc Fonvieille
parent
77b67b247b
commit
f4128cc579
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=13463
1 changed files with 95 additions and 82 deletions
|
|
@ -24,15 +24,15 @@
|
|||
<abstract>
|
||||
<para>Spesso è 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 è chiamato bridge. Un sistema FreeBSD con due
|
||||
per collegarli assieme. Il dispositivo che collega due reti insieme in
|
||||
questo modo è chiamato bridge. Un sistema FreeBSD con due
|
||||
interfacce di rete è 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 è simile a uno
|
||||
differenti. Sotto molti punti di vista un brigde è 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à 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
|
||||
è 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à di packet filtering dei router può non
|
||||
essere applicabile, vuoi per problemi di suddivisione delle sottoreti,
|
||||
vuoi perché il router è di proprietà del fornitore di
|
||||
accesso (<acronym>ISP</acronym>), vuoi perché il router non
|
||||
supporta tali funzionalità. È in questi casi che l'utilizzo
|
||||
supporta tali funzionalità. È in questi casi che l'utilizzo
|
||||
di un filtering bridge diventa altamente consigliato.</para>
|
||||
|
||||
<para>Un firewall basato su bridge può essere configurato e inserito
|
||||
|
|
@ -59,8 +59,9 @@
|
|||
alcun problema di assegnazione di indirizzi IP.</para>
|
||||
|
||||
<note>
|
||||
<para>La traduzione italiana di <quote>firewall</quote> è <quote>muro anti incendio</quote>,
|
||||
<emphasis>non</emphasis> <quote>muro di fuoco</quote> come molti pensano. Nel corso
|
||||
<para>La traduzione italiana di <quote>firewall</quote> è
|
||||
<quote>muro anti incendio</quote>, <emphasis>non</emphasis>
|
||||
<quote>muro di fuoco</quote> come molti pensano. Nel corso
|
||||
dell'articolo, comunque, manterrò i termini tecnici nella loro
|
||||
lingua originale in modo da non creare confusione o
|
||||
ambiguità.</para>
|
||||
|
|
@ -71,14 +72,14 @@
|
|||
<title>Metodi d'installazione</title>
|
||||
|
||||
<para>Aggiungere le funzionalità di bridge a una macchina FreeBSD non
|
||||
è difficile. Dalla release 4.5 è possibile caricare tali
|
||||
è difficile. Dalla release 4.5 è possibile caricare tali
|
||||
funzionalità come moduli anziché dover ricompilare il
|
||||
kernel, semplificando di gran lunga la procedura. Nelle prossime
|
||||
kernel, semplificando di gran lunga la procedura. Nelle prossime
|
||||
sottosezioni spiegherò 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à.</para>
|
||||
</important>
|
||||
|
|
@ -88,19 +89,20 @@
|
|||
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à
|
||||
nella configurazione del firewall può 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à nella configurazione del firewall può 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ì avete deciso di utilizzare il più 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
|
||||
|
|
@ -126,7 +128,7 @@ options IPFIREWALL_VERBOSE</programlisting>
|
|||
<programlisting>bridge_load="YES"</programlisting>
|
||||
|
||||
<para>In questo modo all'avvio della macchina verrà caricato
|
||||
insieme al kernel anche il modulo <filename>bridge.ko</filename>. Non
|
||||
insieme al kernel anche il modulo <filename>bridge.ko</filename>. Non
|
||||
è necessario invece aggiungere una riga per il modulo
|
||||
<filename>ipfw.ko</filename> in quanto verrà caricato in
|
||||
automatico dallo script <filename>/etc/rc.network</filename> dopo aver
|
||||
|
|
@ -139,12 +141,13 @@ options IPFIREWALL_VERBOSE</programlisting>
|
|||
|
||||
<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 è di rifiutare tutti i pacchetti IP. Per
|
||||
iniziare attiviamo il firewall in modalità <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à di non rimanere erroneamente tagliati fuori dalla rete).
|
||||
alcune modifiche al file <filename>/etc/rc.conf</filename>. La regola di
|
||||
default del firewall è di rifiutare tutti i pacchetti IP. Per
|
||||
iniziare attiviamo il firewall in modalità <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à di non rimanere
|
||||
erroneamente tagliati fuori dalla rete).
|
||||
Inserite queste linee nel file <filename>/etc/rc.conf</filename>:</para>
|
||||
|
||||
<programlisting>firewall_enable="YES"
|
||||
|
|
@ -154,39 +157,40 @@ 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à compilato nel
|
||||
kernel), la seconda a impostarlo in modalità <option>open</option> (come descritto
|
||||
nel file <filename>/etc/rc.firewall</filename>), la terza a non
|
||||
kernel), la seconda a impostarlo in modalità
|
||||
<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ù utilizzato è 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à ancora più nascosta in quanto
|
||||
inaccessibile dalla rete: per configurarla occorrerà 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 è
|
||||
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
|
||||
bridge verrà 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'è un'altra cosa importante da sapere. Quando si utilizza IP
|
||||
<para>C'è un'altra cosa importante da sapere. Quando si utilizza IP
|
||||
sopra Ethernet ci sono due protocolli Ethernet in uso: uno è IP,
|
||||
l'altro è <acronym>ARP</acronym>. <acronym>ARP</acronym> permette
|
||||
l'altro è <acronym>ARP</acronym>. <acronym>ARP</acronym> permette
|
||||
la conversione dell'indirizzo IP di una macchina nel suo indirizzo
|
||||
Ethernet (livello <acronym>MAC</acronym>). Affinché due macchine
|
||||
Ethernet (livello <acronym>MAC</acronym>). Affinché due macchine
|
||||
separate dal bridge riescano a comunicare tra loro è 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 è 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 è configurato per non lasciar passare nulla.</para>
|
||||
|
|
@ -194,7 +198,8 @@ firewall_logging="YES"</programlisting>
|
|||
<para>Ora è 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à attivato e il firewall, essendo in
|
||||
modalità <option>open</option>, non impedirà nessuna operazione.</para>
|
||||
modalità <option>open</option>, non impedirà nessuna
|
||||
operazione.</para>
|
||||
|
||||
<para>Se ci dovessero essere dei problemi, è il caso di scoprire ora
|
||||
da cosa derivino e risolverli prima di continuare.</para>
|
||||
|
|
@ -218,7 +223,7 @@ firewall_logging="YES"</programlisting>
|
|||
|
||||
<para>A questo punto dovrebbe essere possibile inserire la macchina tra
|
||||
due gruppi di host senza che venga compromessa qualsiasi
|
||||
possibilità di comunicazione tra di loro. Se è così,
|
||||
possibilità di comunicazione tra di loro. Se è così,
|
||||
il prossimo passo è 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,38 +234,43 @@ firewall_logging="YES"</programlisting>
|
|||
<title>Configurazione del Firewall</title>
|
||||
|
||||
<para>Ora è 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é non tutte le
|
||||
regole per il firewall, in modo da rendere sicura la rete interna.
|
||||
Ci sono delle complicazioni nel fare questo, perché non tutte le
|
||||
funzionalità del firewall sono disponibili sui pacchetti inoltrati
|
||||
dal bridge. Inoltre, c'è una differenza tra i pacchetti che stanno
|
||||
dal bridge. Inoltre, c'è 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 <option>out</option> oppure <option>xmit</option> non
|
||||
verrà mai eseguita. Personalmente uso <option>in via</option> che è una
|
||||
sintassi più antica, ma che ha un senso quando la si legge.
|
||||
Un'altra limitazione è 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>
|
||||
solo in ingresso, quindi qualsiasi regola che usi <option>out</option>
|
||||
oppure <option>xmit</option> non verrà mai eseguita. Personalmente
|
||||
uso <option>in via</option> che è una sintassi più antica,
|
||||
ma che ha un senso quando la si legge.
|
||||
Un'altra limitazione è 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 è il concetto di stateful filtering.
|
||||
Questo è 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'è modo di gestire questo breve scambio di dati come una
|
||||
sessione unica. Ma con un firewall che può <quote>ricordarsi</quote> di un
|
||||
pacchetto <acronym>UDP</acronym> in uscita e permette una risposta nei
|
||||
minuti successivi, gestire i servizi <acronym>UDP</acronym> è
|
||||
semplice. L'esempio seguente mostra come fare. La stessa cosa è
|
||||
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ò
|
||||
<quote>ricordarsi</quote> di un pacchetto <acronym>UDP</acronym> in
|
||||
uscita e permette una risposta nei minuti successivi, gestire i
|
||||
servizi <acronym>UDP</acronym> è semplice.
|
||||
L'esempio seguente mostra come fare. La stessa cosa è
|
||||
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à delle
|
||||
regole standard per l'interfaccia di loopback
|
||||
<devicename>lo0</devicename>, quindi non ce ne occuperemo più ora.
|
||||
|
|
@ -279,8 +289,9 @@ firewall_logging="YES"</programlisting>
|
|||
|
||||
<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
|
||||
macchina bridge ha assegnato l'IP <hostid role="ipaddr">1.2.3.4</hostid>
|
||||
<devicename>xl0</devicename> verso l'interno (<acronym>LAN</acronym>).
|
||||
La macchina bridge ha assegnato l'IP
|
||||
<hostid role="ipaddr">1.2.3.4</hostid>
|
||||
(è 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 +343,63 @@ add pass icmp from any to any icmptypes 11
|
|||
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 è una cosa che solitamente viene fatta
|
||||
dalla rete interna. Questa è 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
|
||||
è che c'è <emphasis>almeno</emphasis> un host
|
||||
sull'interfaccia esterna che non si può ignorare: il router.
|
||||
Solitamente, però, 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à c'è una differenza: tutto il traffico sospetto
|
||||
verrà 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 è altro che uno specifico
|
||||
esempio (il formato delle regole è spiegato dettagliatamente nella
|
||||
man page &man.ipfw.8;). Bisogna notare che, affinché <quote>relay</quote> e <quote>ns</quote>
|
||||
man page &man.ipfw.8;). Bisogna notare che, affinché
|
||||
<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 è un
|
||||
<emphasis>prima</emphasis> che il bridge sia attivato. Questo è un
|
||||
chiaro esempio che dimostra l'importanza di settare l'IP sulla corretta
|
||||
scheda di rete. In alternativa è possibile specificare direttamente
|
||||
l'indirizzo IP anziché il nome host (cosa necessaria se la macchina
|
||||
è IP-less).</para>
|
||||
scheda di rete. In alternativa è possibile specificare
|
||||
direttamente l'indirizzo IP anziché il nome host (cosa necessaria
|
||||
se la macchina è IP-less).</para>
|
||||
|
||||
<para>Le persone che sono solite configurare un firewall probabilmente
|
||||
avranno sempre usato una regola <option>reset</option> o <option>forward</option> per i pacchetti
|
||||
ident (porta 113 <acronym>TCP</acronym>). Sfortunatamente, questa non
|
||||
avranno sempre usato una regola <option>reset</option> o
|
||||
<option>forward</option> per i pacchetti
|
||||
ident (porta 113 <acronym>TCP</acronym>). Sfortunatamente, questa non
|
||||
è una scelta applicabile con il bridge, quindi la cosa migliore
|
||||
è lasciarli passare fino alla destinazione. Finché la
|
||||
è lasciarli passare fino alla destinazione. Finché la
|
||||
macchina di destinazione non ha un demone ident attivo, questa tecnica
|
||||
è relativamente sicura. L'alternativa è proibire le
|
||||
è relativamente sicura. L'alternativa è 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 è
|
||||
che c'è una regola per lasciar comunicare la macchina bridge e
|
||||
un'altra per gli host della rete interna. Ricordate che questo è
|
||||
un'altra per gli host della rete interna. Ricordate che questo è
|
||||
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à 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. 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>
|
||||
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.
|
||||
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">
|
||||
|
|
|
|||
Loading…
Reference in a new issue