Per la prima volta ho scoperto la piattaforma vyatta, alternativa opensource a cisco. Vyatta è disponibile sia come macchina virtuale (Xen e VMware) sia come ISO oltre ai due appliance. Devo ammettere che il non essere user friendly e il prediligere una programmazione CLI a primo impatto mi ha spaventato, tuttavia dopo averci preso la mano (in brevissimo tempo) vyatta si rivela una piattaforma estremamente performante e versatile.  Vediamo ora un paio di cenni generali su questi prodotti, ricordo che è possibile trovare una documentazione molto esaudiente sul sito ufficiale.

Per prima cosa la configurazione della piattaforma vyatta è basata sui file conf, quindi per ogni comando si deve dare un commit ed infine un save per scrivere la nostra configurazione nel file e renderla operativa anche dopo il riavvio della piattaforma stessa. Vediamo ora la configurazione di un router vyatta nel classico scenario dove c’è una LAN e il router deve svolgere la funzione di default gateway, all’interno c’è un server terminal da pubblicare sulla wan. vedremo quindi le seguenti tematiche:

• Modello di routing della piattaforma vyatta
• Customizzazione del router e primo avvio
• Configurazione IP delle interfacce sotto la piattaforma vyatta
• Configurazione del NAT

Note di lettura: Nomi specifici di componenti, tecnologie e credenziali saranno indicate in grassetto mentre i comandi saranno indicati in grassetto corsivo il simbolo << indica “dare invio”

Modello di routing della piattaforma vyatta

Vyatta gestisce i pacchetti in base al tipo di NAT configurato, il routing di un pacchetto soggetto a dnat (mascheramento dell’indirizzo di destinazione) sarà diverso da quello di un pacchetto soggetto a snat (mascheramento dell’indirizzo di provenienza). Per la precisione è la catena vyatta che deve essere considerata in maniera diversa a seconda del tipo di nat. La catena vyatta prevede 4 blocchi di “lavorazione del pacchetto, essi sono: DNAT, Routing, Firewall e SNAT. Un pacchetto soggetto a DNAT subisce il mascheramento dell’indirizzo di destinazione all’inizio della catena, quindi il processo dirouting ed il firewall valutano l’indirizzo di destinazione già mascherato (ad esempio un pacchetto con destinazione 85.37.17.16 subisce un dnat e viene mascherato con l’indirizzo 10.10.10.4. il processo di routing e il firewall avranno come destination address del pacchetto il 10.10.10.4) mentre i pacchetti sogetti a snat subiscono il mascheramento a termine della catena, quindi routing e firewall analizzeranno l’indirizzo sorgente “originale”. L’importanza di questi concetti si rileva vitale durante lo sviluppo delle regole di firewalling.

Customizzazione del router e primo avvio

La piattaforma vyatta è dotata di una CLI molto comoda, al primo avvio ci troveremo dinnanzi alla richiesta di login, si può entrare sia con lo username root sia con l’utente vyatta ovviamente per entrambi è settata una password di default che è vyatta. Di solito per ragioni di sicurezza si predilige lavorare con l’utente vyatta, quindi eseguiamo il login ed entriamo subito in configurazione digitando configure<< ora passiamo alla configurazione.

Impostazione dell’host name: set system host-name nomedaassegnarealrouter <<

Impostazione dominio di appartenenza: set system domain nomedominio <<

Impostazione server DNS: set system name-server ipserverdns <<

Da notare la possybilità di completare i comandi e di mostrare le opzioni con il tasto tab, se sinfatti digitiamo set sy e premiamo tab automaticamente la stringa diviene set system e premendo il tab due volte (una per aggiungere uno spazio dopo la stringa system) visualizzeremo tutti i comandi accettati relativi alla voce system.

Diamo ora un commit per scrivere la configurazione appena modificata e un save per salvarla e renderla definitiva, quindi commit<< save<<.

Uno degli errori più grandi è lasciare le password di default, modifichiamo quindi le password per gli account root e vyatta.

set system login user root authentication plaintext-password nuovapassword<<

set system login user vyatta authentication plaintext-password nuovapassowrd<<

commit<<

save<<

Configurazione IP delle interfacce sotto la piattaforma vyatta

Impostiamo ora gli indirizzi delle interfacce, ricordiamo che solitamente la eth0 è l’interfaccia esposta ad internet, diamo quindi

set interfaces ethernet eth0 address dhcp<<

set interfaces ethernet eth1 address 192.168.1.254/24<<

set system gateway-address 10.10.1.254<<

commit<<

save<<

Ovviamente i volori sono relativi all’esempio quindi se nella nostra interfaccia esterna abbiamo bisogno di inserire un ip fisso non c’è problema, basta utilizzare la notazione usata nella eth1 dell’esempio. Il comando set system gateway address serve a fornire al sistema quale gateway utilizzare per instradare le richieste esterne alla LAN.

Configurazione del NAT

in vyatta la configurazione del nat avviene per regole, abbiamo quindi la possibilità di creare n regole (32) con priorità decrescente, quindi la regola 1 ha più priorità della 2. Per rendere il nostro router un gateway bisogna configurarlo in modo che effettui un operazione di snat dei pacchetti provenienti dalla lan con l’indirizzo dell’interfaccia eth0, questa operazione è detta maquerading. Impostiamo quindi la nat specificando per prima cosa regola e tipo di operazione:

set service nat rule 1 type masquerading<<

ora specifichiamo cosa deve mascherare indicando la nostra rete interna

set service nat rule 1 source address 192.168.1.0/24<<

indichiamo ora l’interfaccia il cui indirizzo IP andrà a sotituire l’IP sorgente dei pacchetti

set service nat rule 1 outbound-interface eth0

infine

commit<<

save<<

Ora riavviamo l’applaiance eseguendo il login come root (prima bisogna uscire dalla configurazione con exit<<) e digitando reboot<<

impostiamo infine il nat per il server terminal.

definiamo come tipologia il dnat: set service nat rule 2 type destination<<

impostiamo l’interfaccia di provenienza: set service nat rule 2 inbound-interface eth0<<

ora impostiamo l’ip pubblico che deve essere nattato set service nat rule 2 destination address ippubblico<<

impostiamo la porta alla quale risponde il servizio lato internet set service nat rule 2 destination port 3389<<

ora impostiamo il tipo di protocollo set service nat rule 2 protocol tcp

passiamo al lato interno indicando l’ip di lan del server terminal set service nat rule 2 inside-address address ipTS<<

terminiamo con l’indicazione della porta sul server terminal set service nat rule 2 inside-address port 3389<<

in ultimo

commit<<

save<<

Bene, spero di essere stato d’aiuto, non dimenticate di consultare la documentazione ufficiale disponibile sul sito vyatta.

Davide Pala

XenServer Pool Master Failure

 

Fortunatamente non è un evento che capita spesso, ma cosa accadrebbe se nell’ambito di un Resource Pool di XenServer la macchina con il ruolo di Master dovesse avere dei problemi?

 

 

Ovviamente ogni server Slave membro del Pool contiene al proprio interno la replica del DB con tutta la configurazione necessaria per prendere possesso del ruolo di Master nel caso gli venga richiesto.

 Quando il nodo Master fallisce avviene questo:

1. I membri si accorgono che la connessione con il master è stata persa e ritentano per 60 secondi di ristabilirla;

2. A questo punto se la connessione non viene ristabilita ogni server Slave entra in Emergency Mode, da questo momento non sarà possibile modificare nessun tipo di configurazione all’interno del Pool e delle singole macchine. Gli unici comandi che i server accetteranno sono quelli relativi alla modalità di emergenza (pool-emergency commands). XenCenter ovviamente non funziona.

Se il master dovesse tornare operativo in questo momento tutti i server membri del Pool lascerebbero la modalità di emergenza e tutto tornerebbe alla normalità.

Se invece il server con il ruolo di Master continua ad avere problemi si deve procedere con la procedura indicata di seguito.

E’ necessario nominare un nuovo Master per il Resource Pool. Scegliere uno dei server slave, raggiungerlo in console oppure tramite ssh, scrivere il seguente comando per farlo diventare il nuovo master:

           xe pool-emergency-transition-to-master

A questo punto sarà possibile contattare il nuovo Master anche con XenCenter. Se necessario bisognerà mandare un segnale a tutti gli altri slave comunicando che il Master è cambiato, il comando è il seguente:

            xe pool-recover-slaves

Avvisa tutti gli slave che il nuovo master è operativo.

Se uno o più slave non dovessero contattare il master, posizionarsi sulla macchina in questione ed eseguire il seguente comando:

 xe pool-emergency-reset-master master-address=<ip del nuovo master>

 Per approfondimenti è disponibile il seguente documento: XenServer System Recovery Guide

Adriano Criscuolo

SUN non rimane indietro

Sun Microsystems ha fornito alcuni dettagli circa il rilascio di VirtualBox 2.1

Commentando l’uscita della nuova versione del programma, Andy Hall, senior product manager, ha dichiarato: “non vogliamo certo mettere da parte il supporto per le soluzioni VMware o Microsoft Hyper-V. Se però gli utenti desiderano ricorrere ad un prodotto diverso da quelli messi a disposizione dai due vendor sappiano che anche noi abbiano una valida applicazione qual è VirtualBox“.

La release 2.1 di VirtualBox, da poco rilasciata, integra il supporto per l’accelerazione hardware attraverso le librerie OpenGL, utilizzate – ad esempio – per garantire il corretto funzionamento di software quali Google Earth. Prossimamente Sun prevede di aggiungere anche il supporto per le librerie DirectX.

Tra le altre migliorie, Sun cita l’ottimizzazione della configurazione della scheda di rete, il supporto per il protocollo iSCSI e per tutti i sistemi operativi a 32 e 64 bit.

David

Anche SUN punta alla virtualizzazione

Anche SUN aggiorna il suo hypervisor, xVM è un derivato di xen che può usufruire dei vantaggi offerti dal sistema operativo Solaris quali ZFS e crossbow e ops center. Con xVM SUN si accinge ad entrare in competizione non solo con i vendor di soluzioni per il consolidamento dei datacenter come XenServer e ESX ma tenta l’assalto anche alle soluzioni di virtualizazione entry level, con l’acquisizione di innotek e del prodotto virtualbox SUN da una spallata a VmWare workstation e tenta la clientela con una soluzione di virtualizzazione gratuita che dalla versione 2.0 supporta anche dischi vhd.

Davide