Test di ZeroShell come Net Balancer renato(dot)

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
ZSP1
Internal
Nework:Provider 1
192.168.10.0/24
192.168.10.1
192.168.10.75
ZSP2
192.168.20.1
ZSNB
Internal
Nework:Provider 2
192.168.20.0/24
192.168.20.75
192.168.30.75
Internal Nework:Client
192.168.30.1
PC1
PC2
PC3
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
Nework:Provider 1
192.168.10.0/24
ZSP1
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
ETH00
ZSNB
192.168.20.75
ETH01
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
exit 0
"/Database/mscripts/startppp0"
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