Netkit: laboratorio di rete virtuale: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
Nessun oggetto della modifica
Nessun oggetto della modifica
Riga 1: Riga 1:
{{Versioni compatibili|Tutte le versioni di Debian}}
==Introduzione ==
==Introduzione ==
Netkit[http://wiki.netkit.org/index.php/Main_Page] è un software, sviluppato dall'Università Roma3, che permette di realizzare veri e propri laboratori virtuali di rete a basso costo e con estrema facilità di gestione.
Netkit[http://wiki.netkit.org/index.php/Main_Page] è un software, sviluppato dall'Università Roma3, che permette di realizzare veri e propri laboratori virtuali di rete a basso costo e con estrema facilità di gestione.

Versione delle 22:02, 15 feb 2010

Debian-swirl.png Versioni Compatibili

ERRORE: valore non valido ( Tutte le versioni di Debian )! Vedi qui.

Introduzione

Netkit[1] è un software, sviluppato dall'Università Roma3, che permette di realizzare veri e propri laboratori virtuali di rete a basso costo e con estrema facilità di gestione.

Questo viene utile sia per motivi didattici che per sperimentare configurazioni particolari da applicare, eventualmente, in ambienti di produzione senza il bisogno di ricorrere ad onerose infrastrutture di test (siano esse fisiche o anche virtuali). Le risorse richieste, infatti, sono minime e il fatto che la virtualizzazione sia destinata esclusivamente a console testuali (non è prevista nessuna possibilità di virtualizzare ambienti grafici) facilita di molto l'implementazione di tale soluzione.


Installazione

I pacchetti necessari all'installazione sono scaricabili da: http://wiki.netkit.org/index.php/Download_Official. Allo stato attuale:

$ wget http://www.netkit.org/download/netkit/netkit-2.6.tar.bz2
$ wget http://www.netkit.org/download/netkit-filesystem/netkit-filesystem-i386-F5.0.tar.bz2
$ wget http://www.netkit.org/download/netkit-kernel/netkit-kernel-i386-K2.7.tar.bz2

scompattiamo gli archivi:

$ tar xvfj netkit/netkit-2.6.tar.bz2
$ tar xvfj netkit-filesystem-i386-F5.0.tar.bz2
$ tar xvfj netkit-kernel-i386-K2.7.tar.bz2

spostiamo la directory netkit appena creata:

$ mv netkit /home/utente/opt


Configurazione

Settiamo il path aggiungendo a .bashrc le righe:

export NETKIT_HOME=/home/utente/opt/netkit
export MANPATH=:$NETKIT_HOME/man
export PATH=$NETKIT_HOME/bin:$PATH

chiudiamo il terminale e riapriamolo per rendere effettive le modifiche.

Verifichiamo

$ cd /home/utente/opt/netkit
$ ./check_configuration.sh
>  Checking path correctness... passed.
>  Checking environment... passed.
>  Checking for availability of man pages... passed.
>  Checking for proper directories in the PATH... passed.
>  Checking for availability of auxiliary tools:
    awk          : ok
    basename     : ok
    date         : ok
    dirname      : ok
    find         : ok
    getopt       : ok
    grep         : ok
    head         : ok
    id           : ok
    kill         : ok
    ls           : ok
    lsof         : ok
    ps           : ok
    readlink     : ok
    wc           : ok
    port-helper  : ok
    tunctl       : ok
    uml_mconsole : ok
    uml_switch   : ok
passed.
>  Checking for availability of terminal emulator applications:
    xterm          : found
    konsole        : not found
    gnome-terminal : not found
passed.

[ READY ] Congratulations! Your Netkit setup is now complete!
          Enjoy Netkit!

Il file di configurazione di netkit è netkit.conf presente nella directory del programma.

Per aumentare la memoria riservata ad ogni macchina, editiamo questo file e sostituiamo:

VM_MEMORY=16

con:

VM_MEMORY=64

A questo punto Netkit è stato configurato correttamente.


Comandi principali

  • vstart: avvia una macchina virtuale
  • vhalt: spegne una macchina virtuale
  • vcrash: chiude una macchina virtuale
  • vlist: ottiene informazioni dettagliate sulle macchine virtuali attive


Ad esempio:

$ vstart v1 --eth0=hub0
$ vstart v2 --eth0=hub0

avvia le macchine virtuali v1 e v2 con le interfacce di rete (eth0) sul dominio hub0.


$ vhalt v1

spegne la macchina v1 (stesso effetto di dare halt all'interno della macchina virtuale)


$ vcrash v2

arresta "brutalmente" la macchina virtuale v2.


Comunicazione con l'host

Per trasferire files al PC host basterà inserirli all'interno della directory /hosthome, presente nel filesystem di ogni macchina virtuale. I file saranno visibili nel PC host e potranno essere gestiti a nostro piacere.


Collegamento ad internet

Per collegare ad internet una macchina virtuale, bisogna avviarla inserendo tap come dominio di collisione e scegliendo una classe di rete differente da quella della macchina host.

Ponendo il caso che la macchina host abbia ip 192.168.1.250:

$ vstart v1 --eth0=tap,192.168.232.1,192.168.232.2

dove

  • 192.168.232.1 è l'IP che sul PC host consente il collegamento ad internet
  • 192.168.232.2 è l'IP da assegnare alla macchina virtuale

Verrà richiesta la password di root.

Dopo aver chiuso le macchine virtuali, le informazioni relative al dominio di collisione tap rimangono attive.

Per ripristinare le impostazioni di sistema iniziali:

$ vclean -T

con relativa richiesta della password di root.


Installazione applicazioni

Per aggiungere nuove applicazioni ad una macchina virtuale:

$ vstart v1 --eth0=tap,192.168.232.1,192.168.232.2 -W --mem 256

dove:

  • -W fa in modo che i pacchetti aggiunti su v1 risultino disponibili anche sulle altre macchine virtuali;
  • –mem 256 aumenta la RAM di v1 fino a 256Mb in modo che l'installazione dei pacchetti non si blocchi a causa della poca memoria disponibile.

Fatto questo, basterà lanciare i classici comandi:

# apt-get update
# apt-get install nomepacchetto

per l'installazione, come in una normalissima macchina Debian-based.


Netkit labs

Settare un lab in netkit significa predisporre, con pochi passaggi, lo “scheletro” di una infrastruttura di rete completa, avviabile (per intero) con un unico comando.

Se ad esempio si volesse realizzare un network composto da due client, un firewall ed un PC server, si procederebbe come segue:

creiamo lo scheletro del laboratorio:

$ mkdir foo-lab
$ mkdir foo-lab/pc1
$ mkdir foo-lab/pc2
$ mkdir foo-lab/fw
$ mkdir foo-lab/server1
$ touch foo-lab/lab.conf
$ touch foo-lab/pc1.startup
$ touch foo-lab/pc2.startup
$ touch foo-lab/fw.startup
$ touch foo-lab/server1.startup

in questo modo sono state create delle directory aventi i nomi delle macchine virtuali che comporranno il nostro lab e i relativi script di avvio di ognuna di esse.

Inoltre è stato creato il file lab.conf che conterrà le impostazioni di base del network:

LAB_DESCRIPTION="A simple network with firewall, server and two clients"
LAB_VERSION=1.0
LAB_AUTHOR="pmate"
LAB_EMAIL=pmatehome[ at ]gmail.com
LAB_WEB=http://pmate.altervista.org
 
pc1[0]="A"
 
pc2[0]="A"
 
fw[0]="A"
fw[1]="B"
 
server1[0]="A"

dove:

  • pc1[0]=“A” —→ la scheda eth0 del pc1 si appoggia allo switch virtuale A
  • pc2[0]=“A” —→ la scheda eth0 del pc2 si appoggia allo switch virtuale A
  • fw[0]=“A” —→ la scheda eth0 del fw si appoggia allo switch virtuale A
  • fw[1]=“B” —→ la scheda eth0 del fw si appoggia allo switch virtuale B
  • server1[0]=“A” —→ la scheda eth0 del server1 si appoggia allo switch virtuale A

Nei file .startup, invece, andranno tutti quei comandi che si volessero eseguire dopo l'avvio della macchina virtuale. Ad esempio:

file fw.startup:

ifconfig eth0 192.168.1.1 netmask 255.255.255.0 up
ifconfig eth1 192.168.232.1 netmask 255.255.255.0 up

Le directory aventi il nome delle macchine virtuali saranno l'equivalente della directory / per ognuna di esse.

Se quindi volessimo impostare per le macchine di quel lab un determinato server DNS:

$ mkdir foo-lab/pc1/etc
$ mkdir foo-lab/pc2/etc
$ mkdir foo-lab/server1/etc
$ echo "nameserver 192.168.1.1" > foo-lab/pc1/etc/resolv.conf
$ echo "nameserver 192.168.1.1" > foo-lab/pc2/etc/resolv.conf
$ echo "nameserver 192.168.1.1" > foo-lab/server1/etc/resolv.conf

Impostati tutti i settaggi necessari, il lab potrà essere avviato con:

$ lstart -d foo-lab

le macchine virtuali facenti parte del lab si apriranno una dopo l'altra automaticamente.

Nella directory in cui viene lanciato il comando lstart verranno creati i file relativi alle macchine virtuali ed ai loro log. Questo, ovviamente, permette di mantenere una “indipendenza” tra le macchine e lo scheletro dell'infrastruttura.


P.S. al momento di scrivere questa guida è presente (ma già segnalato agli sviluppatori) un bug che impedisce di avviare il lab con il flag -d a meno di non applicare questa patch [2] al file lcommon:

$ wget http://list.dia.uniroma3.it/pipermail/netkit.users/attachments/20090525/cb061526/attachment.bin
$ cd opt/netkit/bin
$ patch lcommon /path/to/attachment.bin

Un'alternativa sempre valida è quella di avviare il lab da “dentro” la propria directory:

$ cd foo-lab
$ lstart

La versione 2.6 di netkit è affetta da un bug [3] [4] che si manifesta quando si dichiara una vm con più dispositivi di rete ed uno di questi ha tap come dominio di collisione, gli sviluppatori hanno rilasciato la patch [5]:

$ wget http://list.dia.uniroma3.it/pipermail/netkit.users/attachments/20080202/f21faaa6/tap-not-first.obj
$ cd opt/netkit
$ patch -p1 < /path/to/tap-not-first.obj


Esiste anche un tool grafico per "disegnare" i propri labs, disponibile per il download all'indirizzo: http://code.google.com/p/visual-netkit/ .


Happy virtual-networking!

Links



Autore: pmate