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. - La traduzione italiana di "firewall" è "muro anti incendio", - non "muro di fuoco" come molti pensano. Nel corso + La traduzione italiana di firewall è muro anti incendio, + non muro di fuoco come molti pensano. Nel corso dell'articolo, comunque, manterrò i termini tecnici nella loro lingua originale in modo da non creare confusione o ambiguità. @@ -141,7 +141,7 @@ options IPFIREWALL_VERBOSE (a seconda del metodo che avete scelto in precedenza), bisogna effettuare alcune modifiche al file /etc/rc.conf. La regola di default del firewall è di rifiutare tutti i pacchetti IP. Per - iniziare attiviamo il firewall in modalità 'open', in modo da + iniziare attiviamo il firewall in modalità , 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). @@ -154,7 +154,7 @@ firewall_logging="YES" La prima riga serve ad attivare il firewall (e a caricare il modulo ipfw.ko nel caso non fosse già compilato nel - kernel), la seconda a impostarlo in modalità 'open' (come descritto + kernel), la seconda a impostarlo in modalità (come descritto nel file /etc/rc.firewall), la terza a non visualizzare il caricamento delle regole e la quarta ad abilitare il supporto per il logging. @@ -194,7 +194,7 @@ firewall_logging="YES" 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à 'open', non impedirà nessuna operazione. + modalità , non impedirà nessuna operazione. Se ci dovessero essere dei problemi, è il caso di scoprire ora da cosa derivino e risolverli prima di continuare. @@ -236,12 +236,12 @@ firewall_logging="YES" 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à mai eseguita. Personalmente uso 'in via' che è una + solo in ingresso, quindi qualsiasi regola che usi oppure non + verrà mai eseguita. Personalmente uso che è una sintassi più antica, ma che ha un senso quando la si legge. - Un'altra limitazione è 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 è che si possono usare solo i comandi e + per i pacchetti filtrati dal bridge. Cose avanzate come , + o 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). @@ -252,7 +252,7 @@ firewall_logging="YES" 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'è modo di gestire questo breve scambio di dati come una - sessione unica. Ma con un firewall che può "ricordarsi" di un + sessione unica. Ma con un firewall che può ricordarsi di un pacchetto UDP in uscita e permette una risposta nei minuti successivi, gestire i servizi UDP è semplice. L'esempio seguente mostra come fare. La stessa cosa è @@ -267,7 +267,7 @@ firewall_logging="YES" Le regole personalizzate andrebbero messe in un file a parte (per esempio /etc/rc.firewall.local) e caricate all'avvio modificando la riga del file /etc/rc.conf dove era - stata definita la modalità 'open' con: + stata definita la modalità con: firewall_type="/etc/rc.firewall.local" @@ -356,7 +356,7 @@ add drop log all from any to any 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é 'relay' e 'ns' + man page &man.ipfw.8;). Bisogna notare che, affinché relay e ns siano interpretati correttamente, la risoluzione dei nomi deve funzionare prima che il bridge sia attivato. Questo è 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 è IP-less). 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 o per i pacchetti ident (porta 113 TCP). Sfortunatamente, questa non è una scelta applicabile con il bridge, quindi la cosa migliore è lasciarli passare fino alla destinazione. Finché la @@ -382,9 +382,9 @@ add drop log all from any to any 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 'in via - fxp0' 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 in via + fxp0 funzionano in entrambi i casi. In generale, + se usate regole attraverso il packet filter, dovrete fare un'eccezione per i pacchetti generati localmente, in quanto non entrano tramite nessuna interfaccia.