Netkit: laboratorio di rete virtuale: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
mNessun oggetto della modifica
 
(7 versioni intermedie di 5 utenti non mostrate)
Riga 1: Riga 1:
= Introduzione =
{{Versioni compatibili|Squeeze|Wheezy|Jessie}}
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
==Introduzione ==
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.


Questo viene utile sia per motivi didattici che per sperimentare configurazioni particolari da applicare, eventualmente, in
Questo viene utile sia per motivi didattici che per sperimentare configurazioni particolari da applicare, eventualmente, in
Riga 9: Riga 9:




= Installazione =
== Installazione ==
I pacchetti necessari all'installazione sono scaricabili da: http://wiki.netkit.org/index.php/Download_Official.
I pacchetti necessari all'installazione sono scaricabili da: http://wiki.netkit.org/index.php/Download_Official.
Allo stato attuale:
Allo stato attuale:
Riga 17: Riga 17:
$ wget http://www.netkit.org/download/netkit-kernel/netkit-kernel-i386-K2.7.tar.bz2
$ wget http://www.netkit.org/download/netkit-kernel/netkit-kernel-i386-K2.7.tar.bz2
</pre>
</pre>
scompattiamo gli archivi
scompattiamo gli archivi:
<pre>
<pre>
$ tar xvfj netkit/netkit-2.6.tar.bz2
$ tar xvfj netkit/netkit-2.6.tar.bz2
Riga 24: Riga 24:
</pre>
</pre>


spostiamo la directory netkit appena creata
spostiamo la directory <code>netkit</code> appena creata:
<pre>
<pre>
$ mv netkit /home/utente/opt
$ mv netkit /home/utente/opt
Riga 31: Riga 31:


= Configurazione =
= Configurazione =
Settiamo il path aggiungendo a '''.bashrc''' le righe
Settiamo il path aggiungendo a <code>'''.bashrc'''</code> le righe:


<pre>
<pre>
Riga 80: Riga 80:
</pre>
</pre>


Il file di configurazione di netkit è '''netkit.conf''' presente nella directory del programma.
Il file di configurazione di netkit è <code>'''netkit.conf'''</code> presente nella directory del programma.


Per aumentare la memoria riservata ad ogni macchina, editiamo questo file e sostituiamo
Per aumentare la memoria riservata ad ogni macchina, editiamo questo file e sostituiamo:
<pre>
<pre>
VM_MEMORY=16
VM_MEMORY=16
</pre>
</pre>


con
con:
<pre>
<pre>
VM_MEMORY=64
VM_MEMORY=64
Riga 96: Riga 96:


= Comandi principali =
= Comandi principali =
* '''vstart''': avvia una macchina virtuale
* <code>'''vstart'''</code>: avvia una macchina virtuale
* '''vhalt''': spegne una macchina virtuale
* <code>'''vhalt'''</code>: spegne una macchina virtuale
* '''vcrash''': chiude una macchina virtuale
* <code>'''vcrash'''</code>: chiude una macchina virtuale
* '''vlist''': ottiene informazioni dettagliate sulle macchine virtuali attive
* <code>'''vlist'''</code>: ottiene informazioni dettagliate sulle macchine virtuali attive




Riga 113: Riga 113:
$ vhalt v1
$ vhalt v1
</pre>
</pre>
spegne la macchina '''v1''' (stesso effetto di dare halt all'interno della macchina virtuale
spegne la macchina '''v1''' (stesso effetto di dare halt all'interno della macchina virtuale)




Riga 122: Riga 122:




= Comunicazione con l'host =
== 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 files saranno visibili nel pc host e potranno essere gestiti a nostro piacere.
Per trasferire files al PC host basterà inserirli all'interno della directory <code>'''/hosthome'''</code>, presente nel filesystem di ogni macchina virtuale. I file saranno visibili nel PC host e potranno essere gestiti a nostro piacere.




= Collegamento ad internet =
== 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.
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.


Riga 135: Riga 135:


dove
dove
* 192.168.232.1 è l'ip che sul pc host consente il collegamento ad internet
* 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
* 192.168.232.2 è l'IP da assegnare alla macchina virtuale


Verrà richiesta la password di root.
Verrà richiesta la password di root.
Riga 149: Riga 149:




= Installazione applicazioni =
== Installazione applicazioni ==
Per aggiungere nuove applicazioni ad una macchina virtuale:
Per aggiungere nuove applicazioni ad una macchina virtuale:
<pre>
<pre>
Riga 155: Riga 155:
</pre>
</pre>


dove
dove:
* '''-W''' fa in modo che i pacchetti aggiunti su v1 risultino disponibili anche sulle altre macchine virtuali
* <code>'''-W'''</code> fa in modo che i pacchetti aggiunti su <code>v1</code> 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.
* <code>'''–mem 256'''</code> 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:
Fatto questo, basterà lanciare i classici comandi:
Riga 164: Riga 164:
# apt-get install nomepacchetto
# apt-get install nomepacchetto
</pre>
</pre>
per l'installazione, come in una normalissima macchina debian-based.
per l'installazione, come in una normalissima macchina Debian-based.




= Netkit labs =
== 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.
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 clients, un firewall ed un pc server, si procederebbe come segue:
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:
creiamo lo scheletro del laboratorio:
Riga 186: Riga 186:
</pre>
</pre>


in questo modo sonostate create delle directory aventi i nomi dell macchine virtuali che comporranno il nostro lab e i relativi script di avvio di ognuna di esse.
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:
Inoltre è stato creato il file <code>'''lab.conf'''</code> che conterrà le impostazioni di base del network:
<pre>
<pre>
LAB_DESCRIPTION="A simple network with firewall, server and two clients"
LAB_DESCRIPTION="A simple network with firewall, server and two clients"
LAB_VERSION=1.0
LAB_VERSION=1.0
LAB_AUTHOR="pmate"
LAB_AUTHOR="pmate"
LAB_EMAIL=pmatehome[ at ]gmail.com
LAB_EMAIL=pmate[ at ]fsfe.org
LAB_WEB=http://pmate.altervista.org
LAB_WEB=http://pmate.altervista.org
   
   
Riga 207: Riga 207:


dove:
dove:
* '''pc1[0]=“A”''' —→ la scheda eth0 del pc1 si appoggia allo switch virtuale A
* <code>'''pc1[0]=“A”'''</code> —→ 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
* <code>'''pc2[0]=“A”'''</code> —→ 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
* <code>'''fw[0]=“A”'''</code> —→ 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
* <code>'''fw[1]=“B”'''</code> —→ la scheda eth1 del fw si appoggia allo switch virtuale B
* '''server1[0]=“A”''' —→ la scheda eth0 del server1 si appoggia allo switch virtuale A
* <code>'''server1[0]=“A”'''</code> —→ la scheda eth0 del server1 si appoggia allo switch virtuale A


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


file fw.startup:
file fw.startup:
Riga 221: Riga 221:
</pre>
</pre>


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


Se quindi volessimo impostare per le macchine di quel lab un determinato server dns:
Se quindi volessimo impostare per le macchine di quel lab un determinato server DNS:
<pre>
<pre>
$ mkdir foo-lab/pc1/etc
$ mkdir foo-lab/pc1/etc
Riga 240: Riga 240:
le macchine virtuali facenti parte del lab si apriranno una dopo l'altra automaticamente.
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 files relativi alle macchine virtuali ed ai loro logs.
Nella directory in cui viene lanciato il comando <code>lstart</code> 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.
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[http://list.dia.uniroma3.it/pipermail/netkit.users/attachments/20090525/cb061526/attachment.bin] al file '''lcommon''':
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 <code>'''-d'''</code> a meno di non applicare questa patch [http://list.dia.uniroma3.it/pipermail/netkit.users/attachments/20090525/cb061526/attachment.bin] al file <code>'''lcommon'''</code>:
<pre>
<pre>
$ wget http://list.dia.uniroma3.it/pipermail/netkit.users/attachments/20090525/cb061526/attachment.bin
$ wget http://list.dia.uniroma3.it/pipermail/netkit.users/attachments/20090525/cb061526/attachment.bin
Riga 251: Riga 251:
</pre>
</pre>


Un'alternativa sempre valida è quella di startare il lab da “dentro” la propria directory:
Un'alternativa sempre valida è quella di avviare il lab da “dentro” la propria directory:
<pre>
<pre>
$ cd foo-lab
$ cd foo-lab
Riga 257: Riga 257:
</pre>
</pre>


La versione 2.6 di netkit è affeta da un bug [http://list.dia.uniroma3.it/pipermail/netkit.users/2008-February/000342.html] [http://list.dia.uniroma3.it/pipermail/netkit.users/2008-February/000349.html] 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 [http://list.dia.uniroma3.it/pipermail/netkit.users/attachments/20080202/f21faaa6/tap-not-first.obj]:
La versione 2.6 di netkit è affetta da un bug [http://list.dia.uniroma3.it/pipermail/netkit.users/2008-February/000342.html] [http://list.dia.uniroma3.it/pipermail/netkit.users/2008-February/000349.html] 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 [http://list.dia.uniroma3.it/pipermail/netkit.users/attachments/20080202/f21faaa6/tap-not-first.obj]:
<pre>
<pre>
$ wget http://list.dia.uniroma3.it/pipermail/netkit.users/attachments/20080202/f21faaa6/tap-not-first.obj
$ wget http://list.dia.uniroma3.it/pipermail/netkit.users/attachments/20080202/f21faaa6/tap-not-first.obj
Riga 275: Riga 275:
* http://list.dia.uniroma3.it/pipermail/netkit.users/ : la mailing list
* http://list.dia.uniroma3.it/pipermail/netkit.users/ : la mailing list


{{Autori
|Autore= [[Utente:Pmate|pmate]]
}}


----
[[Categoria:Virtualizzazione]]
Autore: [[Utente:Pmate|pmate]]
 
[[Categoria:Networking]]

Versione attuale delle 09:50, 17 mag 2015

Edit-clear-history.png Attenzione. Questa guida è da considerarsi abbandonata, per via del tempo trascorso dall'ultima verifica.

Potrà essere resa obsoleta, previa segnalazione sul forum, se nessuno si propone per l'adozione.


Debian-swirl.png Versioni Compatibili

Debian 6 "squeeze"
Debian 7 "wheezy"
Debian 8 "jessie"

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=pmate[ at ]fsfe.org
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 eth1 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




Guida scritta da: pmate Swirl-auth20.png Debianized 20%
Estesa da:
Verificata da:

Verificare ed estendere la guida | Cos'è una guida Debianized