Test di ZeroShell come Net Balancer renato… · 2011-12-28 · Premessa Scopo di questo documento...

Test di ZeroShell come Net Balancer renato(dot)morano(at)gmail(dot)com

v. 1.0

1

mailto:[email protected]

Table of ContentsPremessa...............................................................................................................................................3

1.1 Creazione ZSP1.........................................................................................................................41.2 Configurazione ZSP1...............................................................................................................141.3 Creazione ZSP2.......................................................................................................................261.4 Configurazione ZSP2...............................................................................................................281.5 Creazione ZSNB......................................................................................................................34

1.5.1 Configurazione Net Balancer...........................................................................................481.5.2 Load Balancing and Fail over..........................................................................................481.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:

3

192.168.1.0/24

ZSP1 ZSP2

ZSNB

Internal Nework:Provider 1192.168.10.0/24


Real Network

Internal Nework:Client192.168.30.1

PC1PC2 PC3

192.168.1.45

192.168.1.1

192.168.1.55

192.168.10.1 192.168.20.1

192.168.10.75 192.168.20.75

192.168.30.75

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

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

http://www.zeroshell.net/download/

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

mailto:root@zeroshell

mailto:root@zeroshell

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 [email protected]

[email protected]'s password:

17

https://192.168.1.45/

<S>


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


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 (14)

p

Partition number (14): 1

First cylinder (1130, default 1):

Using default value 1

Last cylinder or +size or +sizeM or +sizeK (1130, default 130):

Using default value 130

Command (m for help): w

The partition table has been altered!

Calling ioctl() to reread partition table.

Syncing disks.


Dobbiamo ora creare il filesystem ext3

19

root@zeroshell root> mkfs.ext3 /dev/sda1

mke2fs 1.41.1 (01Sep2008)

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.

21

192.168.1.0/24

ZSP1Internal Nework:Provider 1192.168.10.0/24

192.168.1.45

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

25

192.168.1.0/24

ZSP1


192.168.1.45

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

28

192.168.1.0/24

ZSP2

Real Network

192.168.1.1

192.168.1.55

192.168.20.1

Internal Nework:Provider 2 (VODAFONE)192.168.20.0/24

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

33

192.168.1.0/24

ZSP2

Real Network

192.168.1.1

192.168.1.55

192.168.20.1

Internal Nework:Provider 2 (VODAFONE)192.168.20.0/24

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

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 “hostonly” 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

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

il risultato è mostrato di seguito

43

ZSNB192.168.10.75 ETH00

192.168.20.75 ETH01

192.168.30.75 ETH02

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

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

55

CTRL ^C

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 0918 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

http://www.zeroshell.net/listing/3G-failover.pdf

http://www.zeroshell.net/listing/3G-failover.pdf

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

61

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

Test di ZeroShell come Net Balancer renato… · 2011-12-28 · Premessa Scopo di questo documento...

Documents

Transcript of Test di ZeroShell come Net Balancer renato… · 2011-12-28 · Premessa Scopo di questo documento...