Test di ZeroShell come Net Balancer

renato(dot)morano(at)gmail(dot)com

v. 1.0

1
Table of Contents
Premessa...............................................................................................................................................3
1.1 Creazione ZSP1.........................................................................................................................4
1.2 Configurazione ZSP1...............................................................................................................14
1.3 Creazione ZSP2.......................................................................................................................26
1.4 Configurazione ZSP2...............................................................................................................28
1.5 Creazione ZSNB......................................................................................................................34
1.5.1 Configurazione Net Balancer...........................................................................................48
1.5.2 Load Balancing and Fail over..........................................................................................48
1.5.3 Failover............................................................................................................................63
1.6 Conclusioni e ringraziamenti...................................................................................................67

2
Premessa

Scopo di questo documento è il test della funzionalità di zeroshell come net balancer 
avendo a disposizione un solo gateway Internet. Per le prove si è utilizzato insieme anche 
VirtualBox con la sua possibilità di utilizzare delle “internal network” che rendono possibile 
la comunicazione solo tra le macchine virtuali che le condividono. Lo schema di rete è di 
seguito raffigurato:

  192.168.1.0/24 Real Network

192.168.1.1

192.168.1.45 192.168.1.55

Internal ZSP1 ZSP2

Nework:Provider 1 Internal
192.168.10.0/24 192.168.10.1 192.168.20.1 Nework:Provider 2
192.168.20.0/24

192.168.10.75 192.168.20.75
ZSNB

192.168.30.75

Internal Nework:Client
192.168.30.1

PC2 PC3
PC1

3
1.1 Creazione ZSP1

Mediante l'interfaccia grafica di VirtualBox creiamo la macchina virtuale ZSP1

Procedura solita: nome, ram, creazione disco, configurazione di rete.

4
5
6
7
8
Nella sezione Network della macchina virtuale ZSP1 abilitiamo due Adapter ( schede di 
rete). La prima scheda di rete è in bridge con la macchina fisica (server host). Questa 
scelta ci consentirà di accedere alla macchina direttamente dal server host. Inoltre così la 
macchina virtuale avrà accesso al nostro UNICO gateway a disposizione.

9
La seconda scheda di rete è una “Internal Network” che denominiamo con lo stesso nome 
del provider virtuale

10
Dopo   aver   scaricato   l'immagine   di   ZeroShell   dalla   sezione   download   [ 
http://www.zeroshell.net/download/],   apriamo   la   gestione   delle   immagini   virtuali   “Virtual 
Media Manager”  e procediamo con la registrazione dell'immagine appena salvata

11
12
Ora   nella   sezione   Storage   avremo   la   possibilità   di   scegliere   il   tipo   di   Controller   IDE 
( master) e la sua corrispondente immagine .

Non ci rimane che avviare la macchina ZSP1 e cominciare la configurazione.

13
1.2 Configurazione ZSP1
Avviamo la macchina virtuale ZSP1 sempre tramite GUI Vbox

ottenendo dopo qualche istante la console

14
Accediamo in shell <S> ottenendo il prompt dei comandi

root@zeroshell root>
Eseguiamo una serie di comandi che faciliterà il nostro compito
•  root@zeroshell  root> loadkeys it
impostiamo la nostra amata tastiera, e ritorniamo al menu aggiungiamo un ip della stessa 
rete del  server host. Nel mio caso  l'host  è in 192.168.1.0/24 mentre  ZS  è  direttamente 
raggiungibile sulla 192.168.0.0/24.
Accediamo   a   IP   Manager   mediante   la   selezione   del   menu   corrispondente   <I>   e 
aggiungiamo un ip con il menu <A>

15
Interface [ETH00]: eth00 <invio>
IP: 192.168.1.45 <invio>
Netmask [255.255.255.0]:<invio>

­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ 
ETH00 ­ Intel Corporation 82540EM Gigabit Ethernet Controller (rev 02)   
        Status:  1000Mb/s Full Duplex 
        (1)  192.168.0.75 / 255.255.255.0 (up) 
        (2)  192.168.1.45 / 255.255.255.0 (up) 
­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ 
ETH01 ­ Intel Corporation 82540EM Gigabit Ethernet Controller (rev 02) 
        Status:  1000Mb/s Full Duplex 
­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­ 
                                                Default Gateway: none 

16
Colleghiamoci mediante browser all'indirizzo https://192.168.1.45; e ricordiamo di accettare 
il   certificato   e   di   utilizzare   user   e   password   di   default   impostati   nel   profilo   standard  
“admin/zeroshell”

Come prassi prima di creare il profilo
• abilito la possibilità di accedere in ssh a linea di comando 
• creo la partizione che ospiterà il profilo 
• sempre in “command line”  creo il filesystem ext3

morano@asterix:~$ ssh admin@192.168.1.45 
admin@192.168.1.45's password: 

17
<S>
root@zeroshell root> 
Individiuiamo il device 
root@zeroshell root> fdisk ­l 
Disk /dev/sda: 1073 MB, 1073741824 bytes 
255 heads, 63 sectors/track, 130 cylinders 
Units = cylinders of 16065 * 512 = 8225280 bytes 
Disk /dev/sda doesn't contain a valid partition table 
root@zeroshell root> 

18
Creiamo la partizione ed evidenziamo i comandi dati all'interno di fdisk con il carattere 
“italic bold”
 
root@zeroshell root> fdisk /dev/sda 
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel 
Building a new DOS disklabel. Changes will remain in memory only, 
until you decide to write them. After that, of course, the previous 
content won't be recoverable. 
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite) 
Command (m for help): n 
Command action 
   e   extended 
   p   primary partition (1­4) 
p 
Partition number (1­4): 1 
First cylinder (1­130, default 1): 
Using default value 1 
Last cylinder or +size or +sizeM or +sizeK (1­130, default 130): 
Using default value 130 

Command (m for help): w 
The partition table has been altered! 

Calling ioctl() to re­read partition table.
Syncing disks. 
root@zeroshell root>

Dobbiamo ora creare il filesystem ext3
 

19
root@zeroshell root> mkfs.ext3 /dev/sda1
mke2fs 1.41.1 (01­Sep­2008) 
Filesystem label= 
OS type: Linux 
Block size=4096 (log=2) 
Fragment size=4096 (log=2) 
65280 inodes, 261048 blocks 
13052 blocks (5.00%) reserved for the super user 
First data block=0 
Maximum filesystem blocks=268435456 
8 block groups 
32768 blocks per group, 32768 fragments per group 
8160 inodes per group 
Superblock backups stored on blocks: 
32768, 98304, 163840, 229376 

Writing inode tables: done                            
Creating journal (4096 blocks): done 
Writing superblocks and filesystem accounting information: done 

This filesystem will be automatically checked every 28 mounts or 
180 days, whichever comes first.  Use tune2fs ­c or ­i to override. 
root@zeroshell root> exit

20
A questo punto creiamo il nuovo profilo mediante l'accesso web

Importante notare che abbiamo assegnato all'interfaccia ETH00, in bridge con il server 
host e con il vero gateway, l'indirizzo 192.168.1.45.

192.168.1.0/24

192.168.1.45

Internal ZSP1
Nework:Provider 1
192.168.10.0/24

21
Ora attiviamo il profilo e completiamo la configurazione

Ora che abbiamo il profilo permanente ci colleghiamo al''indirizzo https://192.168.1.45

22
e   proseguiamo   con   la   configurazione   della   rete.   Assegniamo   all'interfaccia   ETH01 
l'indirizzo   192.168.10.1.   Notiamo   che   questa   interfaccia   sarà   raggiungibile   dalle  SOLE 
virtual machines che condividono il nome della internal network TIM.
Il risultato sarà la configurazione di ZSP1 come gateway di un provider virtuale.

23
Affinché la ZSP1 risulti pari ad un gateway virtuale occorre:

• abilitare il fowarding tra le interfacce, abilitato di default

• abilitare   il   NAT   verso   il   gateway   “reale”   attraverso   l'interfaccia   ETH00.   Tutte   le 
connessioni   verso   l'esterno   verranno   ora   mascherate   con   l'ip   presente 
sull'interfaccia ETH00

24
La   macchina   virtuale   ZSP1   da   ora   svolge   la   funzionalità   di   gateway   per   tutta   la   rete 
192.168.10.0/24

192.168.1.0/24

192.168.1.45
ZSP1

Internal
Nework:Provider 1
192.168.10.0/24

25
1.3 Creazione ZSP2
Questa macchina è creata come la ZSP1 e le uniche variazioni sono nel suo nome 

26
e nella configurazione della rete interna legata al  secondo network adapter, dove ora il 
nome è VODAFONE

27
1.4 Configurazione ZSP2
La configurazione della ZSP2 è analoga alla ZSP1 ma se ne si differenzia 
• nell'ip da assegnare ad ETH00 in bridge con il server host, nel nostro esempio 
scegliamo il 192.168.1.55
• nella   internal   network   è   VODAFONE   e   su   questa   assegneremo   la   rete 
192.168.20.0/24

192.168.1.0/24 Real Network

192.168.1.1

192.168.1.55

ZSP2

192.168.20.1

Internal Nework:
Provider 2 (VODAFONE)
192.168.20.0/24

28
Creiamo il nuovo profilo permanente ZSP2;

29
  
Attiviamo il nuovo profilo;

30
Configuriamo l'indirizzo ip da  assegnare a ETH01: 192.168.20.1

31
Verifichiamo che il forwarding tra le interfacce sia abilitato e abilitiamo il NAT 
sull'interfaccia ETH00

32
Infine la macchina virtuale ZSP2 da ora svolge la funzionalità di gateway per tutta la rete 
192.168.20.0/24

192.168.1.0/24 Real Network

192.168.1.1

192.168.1.55

ZSP2

192.168.20.1

Internal Nework:
Provider 2 (VODAFONE)
192.168.20.0/24

33
1.5 Creazione ZSNB
La creazione della macchina che farà da net balancer è analoga alla precedenti ma se ne 
differenzia per
• nome della virtual machines ZSNB; ZSroshell Net Balancer
• avremo quattro network adapter abilitati
◦ uno sulla rete interna TIM
◦ uno sulla rete interna VODAFONE
◦ uno sulla rete interna CLIENT
◦ uno sulla rete host only
Una tale suddivisione assicura una separazione tra le reti. 
Osserviamo che la separazione è data sia dalle tre reti differenti sia dalla scelta all'interno 
del   virtualizzatore   di   tre   rete   isolate   anche   dallo   stesso   host.   Motivo   per   cui   abbiamo 
aggiunto una quarta  rete host only è per poter amministrare la stessa macchina virtuale 
anche non in console.
Cominciamo 

34
35
36
37
Avviamo la virtual machines e ritroviamo il menu:

Modifichiamo gli ip associati al profilo di DEFAULT; questo per poter accedere via web 

38
Nel dettaglio possiamo accedere dalla sola “host­only” e assegneremo alla ETH03 
l'indirizzo 192.168.56.75. Questo perché Virtualbox assegna la rete 192.168.56.0./24 alla 
rete host only.

Finalmente possiamo accedere via web ed infatti ritroviamo la richiesta di certificato non 
verificato.

39
40
Accediamo sempre con user e password del profilo di default 

41
Ora possiamo creare il nuovo profilo e attivarlo !

42
Accediamo al nuovo profilo e cominciamo a rendere la sezione Network funzionale ai 
nostri scopi

192.168.10.75 192.168.20.75
ZSNB ETH01
ETH00

192.168.30.75
ETH02

il risultato è mostrato di seguito

43
44
Abilitiamo l'accesso in SSH attraverso la rete host only e proviamo ad accedere in console

45
Facciamo la prova del nove, verifichiamo la raggiungibilità dei nostri gateway virtuali 
( ZSP1, ZSP2)

Come vedete la rete 192.168.1.0/24 al momento non è direttamente raggiungibile

46
Abilitiamo il NAT  da entrambe le interfacce connesse direttamente ai due gateway virtuali

47
1.5.1 Configurazione Net Balancer
Il net balancer ci permette due configurazioni, nella prima abbiamo sia un 
bilanciamento del traffico tra  due ( o più  ) gateway sia una ridondanza in caso di fault di 
uno dei due. In caso di fault “tutto” il traffico  viene dirottato verso il gateway funzionante.
La seconda configurazione non prende in considerazione il bilanciamento del traffico ma 
considera un  gateway  sempre attivo mentre l'altro interviene solo in caso di fault del 
principale.
L'assegnazione sia del ruolo ( principale, spare ) sia di quanto traffico deve attraversare il 
singolo gateway è dato dal peso associato a ciascun gateway.   

1.5.2 Load Balancing and Fail over

La configurazione comincia selezionando il menu corrispondente e ottenendo il 
menu seguente:

Definiamo il primo gateway, con il pulsante Add 

48
La compilazione è immediata :
• una descrizione
• lo stato; enabled naturalmente
• il peso; maggiore è questo numero maggiore sarà il suo peso nell'instradamento dei 
pacchetti. Il valore 90 indica la volontà di fare di questo, il gateway  preferenziale.
• indirizzo ip del gateway
• un coefficiente di velocità nella risposta ICMP

Definiamo il secondo gateway:
• una descrizione, 
• lo stato; enabled naturalmente
• il peso;  Il valore 10 indica la volontà di fare di questo, il gateway secondario
• indirizzo ip del gateway
• un coefficiente di velocità nella risposta ICMP

49
Il risultato finale  è rappresentato in figura

Osserviamo l'attivazione del Failover Monitor e la definizione del Failover IP Addresses. 
La scelta degli ip è ricaduta sui dns server di Google ( 8.8.8.8 e 8.8.4.4) e il dns server di 
OpenDns.
Il tocco finale è abilitare e salvare la configurazione, ottenendo 

50
Verifichiamo   ora   la   raggiungibilità   sia   della   rete   192.168.1.0/24   sia   della   grande   rete   e 
vediamo se ora le cose sono cambiate:

!!!INCREDIBILE !!!!!
Sembra tutto funzionare, ma che strada percorrono i pacchetti ? Ci serve sapere la strada 
che percorrono per capire come il net balancer instrada i pacchetti;
Il comando che ci viene in aiuto è  tracepath  aggiungiamo il parametro  ­n  per evitare la 
risoluzione dei nomi.

51
è

Come previsto il primo GW è quello con il peso maggiore e nelle statistiche abbiamo la 
conferma con un maggiore traffico registrato

Facciamo la prova di invertire i pesi e vediamo se otteniamo il viceversa

ripetiamo il tracepath e osserviamo:

52
Il “salto” ora passa attraverso il gw Vodafone. 

Confrontiamo la tabella di routing  nei due casi, ponendo attenzione alla colonna metrica [ 
Metric ] dove compaiono i pesi w.90 e w.10

53
54
 Verificare   la   variazione   di   tracepath   con   i   pesi   90   e   10   diventa   pesante   da 
dimostrare allora li modifichiamo rendendoli uguali e impostando la probabilità al 50%. Il 
tutto si traduce in  immagini:

ed infatti osserviamo il “round robin” in azione 

CTRL ^C

55
Proviamo a  simulare delle interruzioni di rete, per esempio  una  disconnessione di una 
interfaccia,   nel   dettaglio   interrompiamo   la   raggiungibilità   attraverso   il   primo   gateway 
[ ZSP1]. La simulazione la otteniamo da Virtualbox

ancora più drastici simuliamo una interruzione anche della rete interna 

56
e vediamo come i log del Net Balancer riportano le variazioni 

Attivando   i   codici   di   sblocco   per   i   grafici   MRTG   vediamo   come   il   traffico   viene 
rappresentato in caso di fault 

57
Ora non ci resta che verificare il comportamento in caso di ripristino della connettività del 
gateway TIM

58
Utilizziamo   la   funzionalità   di   test   del   net   balancer   per   forzare   la   verifica   della 
raggiungibilità attraverso i due gateway. 

Mediante il tasto Test e visualizzando il log 

Il test credo venga effettuato mediante un comando del tipo 
ping ­I ETH00 8.8.8.8 
e 
ping ­I ETH01 8.8.8.8

59
Possiamo verificare “l'inerzia” alle variazioni di stato anche mediante il suggerimento dato 
da Mirko Mare nel su contributo alla documentazione Creazione script per gestione 3G in 
failover 
( La sua documentazione mi è stata molto utile, e il suo suggerimento ha risolto la mia 
necessità di abilitare e disabilitare una connessione 3G via cron, questo per garantire una 
connessione solo nelle ore lavorative 09­18 dal lunedì al sabato; evitando uno “spreco” di 
tempo di connessione. Devo solo aggiungere che per farlo funzionare e far risalire PPP0 in 
cron ho riscontrato la necessità di alcune modifiche. In particolare lo script eseguito a cron 
richiama un secondo script.

Script in cron
#!/bin/sh -x
su - -c "/Database/mscripts/startppp0"
exit 0

script richiamato

# startppp0
#!/bin/sh -x
. /etc/kerbynet.conf
. _SCRIPTS/net.inc

echo "/root/kerbynet.cgi/scripts/net_updown IF,ppp0 true"

while [ "_( /sbin/ifconfig -a | grep ppp0 )X" == "X" ]
do
/root/kerbynet.cgi/scripts/net_updown IF,ppp0 true
sleep 5
done

exit 0

Allora proviamo subito a console 

60
Le prove sono state eseguite mentre ascoltavo i podcast della BBC e non ho avuto 
nessuna interruzione dell'audio.

61
62
1.5.3 Failover
La configurazione  avviene cambiando la modalità ( Mode) in Failover e confermando con 
Save.

Osserviamo che lo status dei gateway è passato da Active/Active  a Active/Spare

63
Verifichiamo anche la tabella di routing

che riporta come default il gateway quello con peso maggiore.
Provochiamo un fault della ETH00 e vediamo

riportiamo la ETH00 up

64
Dai test eseguiti il default gateway cambia a secondo dello stato della ETH00.  Lo stesso 
accade se il gateway non risulta più raggiungibile. 

65
Riattiviamo la VM e vediamo se il routing viene ripristinato

66
1.6 Conclusioni e ringraziamenti
La guida rende possibile il test di una funzionalità “chiavi in mano” di ZeroShell.
Il mio contributo vuole essere di aiuto a chi si avvicina a questa opera di ingegno e vuole 
restituire un po di quello che grazie a Fulvio Ricciardi e alla comunità sono riuscito ad 
imparare   e   realizzare.   Se   avete   osservazioni   suggerimenti   o   correzioni   non   esitate   a 
scrivere a renato(dot)morano(at)gmail(dot)com

67