Configurazione del laboratorio virtuale Netkit4TIC
Configurazione del laboratorio virtuale Netkit4TIC |
|
La distribuzione GNU/Linux della macchina reale (Download live-{CD,USB}) |
|
Quando ho iniziato nel 2003 a utilizzare Netkit come strumento base di laboratorio di reti ho avuto parecchie difficoltà nella installazione poichè in alcune distribuzioni GNU/Linux il sistema era particolarmente instabile o addirittura inusabile. Questo era un problema ancora più grave per quei corsisti con poca dimestichezza con Linux. La soluzione a un certo punto è affiorata con la distribuzione Knoppix che ha reso disponibile una piattaforma per la costruzione di un sistema specializzato per Netkit. L'impacchettamento di Netkit su Knoppix è stato inizialmente realizzato da Giovanni Coffaro corsista C2 dell'Istituto Gramsci di Padova.
Netkit4TIC è composto da due parti:
bug.it).Come nelle migliori storie per bambini, l'anatroccolo si dimostra un cigno, e dalla release v2.3 il live-CD si trasforma in una USB key con tempi di boot e di esecuzione uguali a una distribuzione installata su disco fisso.
La configurazione della rete |
|
La capacità
di scambiare pacchetti tra la macchina virtuale e la
macchina reale è resa disponibile dal modulo
tun.o (altrimenti già presente nel kernel).
Riportiamo dalla FAQ su openvpn la differenza tra
TUN device e TAP device:
"A TAP device is a virtual ethernet adapter, while
a TUN device is a virtual point-to-poin IP link".
Per prima cosa verifica quindi se al boot della tua
Linux box è già presente nel kernel il
sopracitato modulo:
realHost$ dmesg | grep TUN
dovrebbe essere visualizzato un messaggio del tipo:
Universal TUN/TAP device driver X.Y (C)1999-2002 Maxim Krasnyansky
In caso negativo prova a vedere se è possibile caricare il modulo (da utente root):
realHost# modprobe tun
Nel caso in cui venga visualizzata una diagnostica di errore
non è possibile usare il meccanismo che
stiamo per spiegare;
esistono altri sistemi, quali il multicast.
Nel caso invece che il modulo sia stato caricato correttamente (lo
puoi verificare con lsmod)
controlla se esiste già il
device /dev/net/tun altrimenti occorre una tantum crearlo e
definirne i permessi con:
realHost# mkdir /dev/net; \
mknod /dev/net/tun c 10 200; \
chmod 666 /dev/net/tun
Ci sono svariati modi di interconnettere la macchina reale con una macchina virtuale. Ne elenchiamo di seguito cinque facendo l'ipotesi che la macchina reale sia nella LIS 192.168.100.0/24:
+---- eth0
|
realHost + + virtualHost
| |
+---- tap0 eth0 ----+
Sono mostrati di seguito la costruzione di tap0, del
routing e l'assegnazione dell'IP address alla virtual machine:
realHost$ sudo tunctl -u `whoami`
Set 'tap0' persistent and owned by uid 1000
realHost# ifconfig tap0 192.168.77.1; \
echo "1" > /proc/sys/net/ipv4/ip_forward
virtualHost# ifconfig eth0 192.168.77.2 up; \
route add default gateway 192.168.77.1
+---- eth0
|
realHost +--- br0 -----+ + virtualHost
| |
+---- tap0 eth0 ----+
Sono mostrati di seguito la costruzione di tap0, del bridge
con eth0 e tap0 e l'assegnazione dell'IP address alla virtual machine:
realHost$ sudo tunctl -u `whoami`
Set 'tap0' persistent and owned by uid 1000
realHost# ifconfig eth0 0.0.0.0 up; \
ifconfig tap0 0.0.0.0 up; \
brctl addbr br0; \
brctl addif br0 eth0; \
brctl addif br0 tap0; \
ifconfig br0 0.0.0.0 up
virtualHost# ifconfig eth0 REAL-IP up; \
route add default gateway REAL-GATEWAY
realHost$ sudo tunctl -u `whoami`
Set 'tap0' persistent and owned by uid 1000
realHost# ifconfig tap0 192.168.100.254; \
echo "1" > /proc/sys/net/ipv4/ip_forward; \
route add -host 192.168.100.253 dev tap0; \
echo "1" > /proc/sys/net/ipv4/conf/tap0/proxy_arp; \
arp -Ds 192.168.100.253 eth0 pub
virtualHost# ifconfig eth0 192.168.100.253 up
realHost$ sudo tunctl -u `whoami`
Set 'tap0' persistent and owned by uid 1000
realHost# ifconfig tap0 192.168.77.1; \
echo "1" > /proc/sys/net/ipv4/ip_forward; \
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
virtualHost# ifconfig eth0 192.168.77.2 up
route add default gateway 192.168.77.1
+---- eth0.2
|
realHost +--- br2 -----+ + virtualHost
(VLAN-aware) | | (VLAN-unaware)
+---- tap2 eth0 ----+
Sono mostrati di seguito la costruzione della
VLAN, del bridge e l'assegnazione dell'IP address alla vm
(VLAN-unaware):
realHost$ sudo tunctl -u `whoami` -t tap2
Set 'tap2' persistent and owned by uid X
realHost# modprobe 8021q; \
vconfig add eth0 2
realHost# ifconfig eth0.2 0.0.0.0 up; \
realHost# ifconfig tap2 0.0.0.0 up
realHost# brctl addbr br2; \
brctl addif br2 eth0.2; \
brctl addif br2 tap2; \
ifconfig br2 0.0.0.0 up
virtualHost# ifconfig eth0 192.168.77.2 up
La specializzazione di Netkit per i corsi TIC |
|
Il nostro scopo è quello di mettere a disposizione un
ambiente virtuale che sia il più simile all'ambiente
reale su cui andremo ad operare.
Per questo motivo
proponiamo server virtuali e reali con distribuzione Debian Sarge
e proponiamo firewall/router/"packet filter" virtuali e reali con distribuzione
LEAF/Bering uClibc.
In rispetto alle versioni di kernel presenti in Debian Sarge e in
Bering uClibc sono stati costruiti i relativi kernel uml della
serie 2.4.
Il guest kernel per Debian Sarge è il 2.4.27 e in futuro
vedremo se possibile di produrre anche il 2.6.8. Il guest kernel
per Bering uClibc è il 2.4.32.
Il kernel di default è quello originale di Netkit.
È stato modificato un unico file del "core" di netkit
bin/script_utils per aggiungere la "specializzazione"
Netkit4TIC. Questa consiste semplicemente in una serie di
variabili d'ambiente che influenzano il comportamento
degli script rimasti immodificati:
NETKIT_VM_TYPE è valorizzabile con
sarge o con bering
e pilota la scelta del kernel che viene lanciato dal comando
vstart. Nel caso di scelta bering viene anche
scelto il filesystem della bering e vengono impostati i parametri
per il boot.NETKIT_BERING_FD è valorizzabile con
il nome del file che contiene il boot floppy per bering.Per la costruzione di una vm in modo che l'interfaccia eth0 sia connessa con l'interfaccia tap0 del mondo reale per questioni legate alla compatibilità con le esperienze già realizzate abbiamo deciso di realizzarla con il comando:
realHost$ vstart test --append="eth0=tuntap,tap0"
I filesystem inclusi sono due:
Debian Sarge con tutti packages
necessari per le esercitazioni (in rari casi sono stati usati i sorgenti
di alcuni pacchetti).LEAF/Bering uClibc completo.
Nella realtà il firewall è contenuto
in un singolo floppy da cui la macchina fa il boot e che in seguito
viene caricato in RAM.
Nel mondo virtuale compie gli stessi passi e quindi usa
un "initial root file-system" presente in initrd.
Da questa modalità di caricamento ne segue che il filesystem
montati sono in read-only e viene mantenuta una stretta corrispondenza
tra sistema virtuale e sistema reale.
La specializzazione di QEMU |
|
La versione attualmente installata è la 0.8.2 e le istruzioni per il suo uso sono in approfondimento.
|
|
Sandro Doro (email me)