Avanti Indietro Indice

4. Provare il nuovo ambiente bridge!

4.1 Terreno di prova

Si immagini uno scenario simile a questo: 

                                                          /\
          Ethernet           Ethernet           ATM    /-/  \
---------          ---------          ---------     /-/      |
|  Box  |----------|Bridge |----------|Router |-----| Inter-  \
---------          ---------          ---------     \  net  ---|
         ^        ^         ^        ^               \     /
         |        |         |        |                \---/
        eth0     eth0      eth1     if0                 ^
         |        |         |        |                  |
      10.0.3.2   none/10.0.3.1      195.137.15.7    anything else
                  \         /
                   \       /
   ^                \-br0-/
   |                                      ^             ^
   |                   ^                  |             |
   |                   |                  |             |
  own                 own              foreign        hostile
Il proprio potere amministrativo si limita alle macchine contrassegnate con own, il Router è completamente off-limits e così pure Internet, naturalmente.
Se si vuole controllare il traffico da e per la rete si può decidere di integrare un firewall nel bridge.
Il modo usuale di risolvere il problema consisterebbe nel cambiare il default gateway su tutti gli host della propria rete. Ma questo è un sistema piuttosto oneroso, nessuno vorrebbe cambiare più di 5 default route su 5 diversi host per più di una volta. Si tenga anche presente il dispendio di tempo. E non si dimentichi che questa soluzione potrebbe porre problematiche per quanto riguarda la sicurezza.
L'altro sistema è più semplice, richiede meno tempo, è più sicuro e meno soggetto a errori. Più sicuro poiché non vi è necessità di assegnare alcun indirizzo IP. Niente IP, niente pericoli. Almeno in teoria, si spera, gli stack sono salvi. (In ogni caso sarebbe meglio non farci affidamento...). Il vantaggio quindi sta nell'avere un'installazione completamente trasparente, nessun IP e nessun MAC da cambiare.
Ognuno sceglie il metodo che preferisce, qui verrà trattato solo il più elegante ;-)

4.2 Pingalo Jim!

Si configurerà l'interfaccia eth0 della propria macchina come d'abitudine. Le interfacce del bridge saranno configurate come descritto nella sezione Configurazione.
Se si desidera utilizzare l'inoltro (forwarding) si dovrà eseguire: 

root@bridge:~> echo "1" > /proc/sys/net/ipv4/ip_forward
Opzionalmente si potrà configurare una default route: 
root@bridge:~> route add default gw 10.0.3.129
Quindi si imposteranno alcune regole di iptables sull' host bridge: 
root@bridge:~> iptables -P FORWARD DROP
root@bridge:~> iptables -F FORWARD
root@bridge:~> iptables -I FORWARD -j ACCEPT
root@bridge:~> iptables -I FORWARD -j LOG
root@bridge:~> iptables -I FORWARD -j DROP
root@bridge:~> iptables -A FORWARD -j DROP
root@bridge:~> iptables -x -v --line-numbers -L FORWARD
L'ultima linea genera il seguente output: 
Chain FORWARD (policy DROP 0 packets, 0 bytes)
num      pkts      bytes target   prot opt in     out     source   destination
1           0        0 DROP       all  --  any    any     anywhere anywhere
2           0        0 LOG        all  --  any    any     anywhere anywhere      LOG level warning
3           0        0 ACCEPT     all  --  any    any     anywhere anywhere
4           0        0 DROP       all  --  any    any     anywhere anywhere
Il LOG target inserisce fa il log di tutti i pacchetti attraverso syslogd. Attenzione però, questo è da intendersi a solo scopo di testing, in un ambiente di produzione questa regola deve essere rimossa. Altrimenti si rischia di riempire i file di log e l'hard disk, oppure chiunque potrebbe usare questo sistema per un causare un Denial of Service.
Per provare le regole si esegua un ping verso il router (195.137.15.7) sull'host box: 
root@box:~> ping -c 3 195.137.15.7
PING router.provider.net (195.137.15.7) from 10.0.3.2 : 56(84) bytes of data.
--- router.provider.net ping statistics ---
3 packets transmitted, 0 received, 100% loss, time 2020ms
^C
root@box:~>
Di default viene eseguito un DROP su ogni pacchetto. Nessuna risposta, nessun pacchetto nei log. Questa configurazione è progettata per scartare ogni pacchetto a meno che non si ometta la prima regola, subito prima di quella con il target LOG: 
root@bridge:~> iptables -D FORWARD 1
root@bridge:~> iptables -x -v --line-numbers -L FORWARD
Ora le regole diventano: 
Chain FORWARD (policy DROP 0 packets, 0 bytes)
num      pkts      bytes target   prot opt in     out     source   destination
2           0        0 LOG        all  --  any    any     anywhere anywhere      LOG level warning
3           0        0 ACCEPT     all  --  any    any     anywhere anywhere
4           0        0 DROP       all  --  any    any     anywhere anywhere
E tutti i pacchetti possono attraversare il bridge. Proviamo con un ping dall'host box: 
root@box:~> ping -c 3 195.137.15.7
PING router.provider.net (195.137.15.7) from 10.0.3.2 : 56(84) bytes of data.
64 bytes from router.provider.net (195.137.15.7): icmp_seq=1 ttl=255 time=0.103 ms
64 bytes from router.provider.net (195.137.15.7): icmp_seq=2 ttl=255 time=0.082 ms
64 bytes from router.provider.net (195.137.15.7): icmp_seq=3 ttl=255 time=0.083 ms

--- router.provider.net ping statistics ---
3 packets transmitted, 3 received, 0% loss, time 2002ms
rtt min/avg/max/mdev = 0.082/0.089/0.103/0.012 ms
root@box:~>
Yippeah! il router è vivo e funzionante.

Nota Importante:

Quando viene attivata, l'interfaccia del bridge impiega circa 30 secondi per diventare completamente operativa. Questi 30 secondi sono la fase di apprendimento del bridge. Durante questo tempo il bridge esegue un test per stabilire quali indirizzi MAC esistono su quali porte. L'autore del codice, Lennert, dichiara nel suo TODO che la durata della fase di apprendimento verrà opportunatamente diminuita prima o poi.
Si ricordi che durante la fase di test, nessun pacchetto attraverserà il bridge e nessun ping sarà possibile.

4.3 Configurazione Attuale

Questa sezione vuole offrire alcuni suggerimenti relativi a come dovrebbe presentarsi il sistema dopo aver eseguito con successo quanto descritto in questo howto.

Configurazione dell'interfaccia

L'output di ifconfig dovrebbe essere simile al seguente: 

root@bridge:~> ifconfig
br0       Link encap:Ethernet  HWaddr 00:04:75:81:D2:1D
          inet addr:10.0.3.129  Bcast:195.30.198.255  Mask:255.255.255.128
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:826 errors:0 dropped:0 overruns:0 frame:0
          TX packets:737 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:161180 (157.4 Kb)  TX bytes:66708 (65.1 Kb)

eth0      Link encap:Ethernet  HWaddr 00:04:75:81:ED:B7
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:5729 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3115 errors:0 dropped:0 overruns:0 carrier:656
          collisions:0 txqueuelen:100
          RX bytes:1922290 (1.8 Mb)  TX bytes:298837 (291.8 Kb)
          Interrupt:11 Base address:0xe400

eth1      Link encap:Ethernet  HWaddr 00:04:75:81:D2:1D
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:1 frame:0
          TX packets:243 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:342 (342.0 b)  TX bytes:48379 (47.2 Kb)
          Interrupt:7 Base address:0xe800

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:1034 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1034 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:82068 (80.1 Kb)  TX bytes:82068 (80.1 Kb)

Configurazione del Routing

L'output del proprio comando route dovrebbe assomigliare a: 

root@bridge:~> route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.0.3.129      0.0.0.0         255.255.255.128 U     0      0        0 br0
0.0.0.0         10.0.3.129      0.0.0.0         UG    0      0        0 br0
root@bridge:~>

Configurazione di Iptables

Si legga la sezione Pingalo Jim!.

4.4 Nota finale (Importante!)

Mi piacerebbe avere vostre notizie! :-)
Avete gradito il viaggio?
Vi manca qualcosa?
Avete bisogno di aiuto? (Chiedete al vostro assistente locale ;-) oppure rtfm.
Siete ancora online? Allora mandatemi un messaggio via email. Mi farà contento.
Volete mandarmi un assegno? Per favore non posso accettarli.. (Sto scherzando;)
Date valore al mio tempo, semplicemente mandatemi qualche bella parola, è sufficiente.
Niente motiva di più dei partecipanti felici che ti danno feedback positivi.
Per cui, forza, spendete un minuto e scrivetemi un email!
Grazie!

Nils

4.5 Bug-Notes

Pare vi sia un bug nel codice del br-nf: 

From: Bart De Schuymer <bart.de.schuymer_@_pandora.be>
Date: Sun, 1 Sep 2002 21:52:46 +0200
To: Nils Radtke <Nils.Radtke_@_Think-Future.de>
Subject: Re: Ethernet-Brigde-netfilter-HOWTO

Ciao Nils,

[...]
Inoltre, il debugging del filtraggio dei pacchetti con la patch br-nf è
in generale una cattiva idea. Possono essere segnalati molti falsi avvisi
(relativi a presunti bug) nei log.
[...]

Personalmente non ho mai riscontrato falsi positivi nei miei log. Forse il bug è stato corretto. A questo proposito Bart ha scritto: 

From: Bart De Schuymer <bart.de.schuymer_@_pandora.be>
Date: Mon, 2 Sep 2002 18:30:25 +0200
To: Nils Radtke <Nils.Radtke_@_Think-Future.de>
Subject: Re: Ethernet-Brigde-netfilter-HOWTO

On Monday 02 September 2002 00:39, Nils Radtke wrote:
> La revisione del codice nf-debug nel br-nf sarà migliorata?

Devo ammettere di non aver più fatto girare alcun kernel con il
netfilter debugging attivo ultimamente. Di sicuro qualche mese
fa generava dei falsi positivi (la mailing list sul bridge contiene
diversi post su questo problema), mi è mancato il tempo di capire
il motivo e se accade ancora. È nella mia lista delle cose da fare.
[...]
Ma (alla data attuale, 19-09-2002) non ho trovato un annuncio ufficiale che segnalasse la chiusura del bug. Si controlli costantemente la ethernet bridge mailinglist se si è interessati alla risoluzione del problema.

Avanti Indietro Indice