Capitolo 2. Rete
Questo capitolo illustra brevemente la configurazione della rete che definisce l'organizzazione virtuale. La conformazione della rete, e le caratteristiche che ne conseguono, hanno determinato in modo fondamentale le scelte che sono state fatte successivamente, dunque è necessario partire da qui per comprendere il resto dell'infrastruttura.
La configurazione di rete è mantenuta sui vari server utilizzando CFengine (vedi il Capitolo 6).
2.1. Struttura
I vari server sono dislocati geograficamente in luoghi differenti, e sono dunque raggiungibili ciascuno con il suo specifico IP pubblico. Caratteristica determinante di questa configurazione è la bassa banda di interconnessione tra i vari server: la dislocazione geografica fa sì che il canale di comunicazione interno competa per le risorse con la comunicazione normale (si veda l'Appendice B per uno studio più approfondito). Ciò rappresenta la maggior differenza tra il modello discusso in questo documento e le soluzioni tradizionali di clustering e high availability, che (generalmente pensate per un ambito più "aziendale"), presuppongono invece una capacità di interconnessione arbitrariamente elevata (locale).
Il canale di comunicazione interno è realizzato con una VPN (utilizzando il software Tinc), che collega i vari nodi permettendo una comunicazione cifrata senza l'overhead di una negoziazione SSL per ciascuna connessione.
La VPN è considerata trusted: la sola presenza sulla VPN è indice di affidabilità, inoltre le singole connessioni su questo anello non hanno strettamente bisogno di essere cifrate (già provvede tinc ad un livello più basso). Molti servizi amministrativi interni (oltre ai meccanismi di sincronizzazione) sono disponibili solo su queste interfacce.
Lo schema completo della rete comprende anche svariate altre macchine, organizzate in anelli concentrici e intercomunicanti, corrispondenti a vari gradi (decrescenti) di affidabilità, per cui, tanto per fare un esempio, già le macchine dell'anello 1 (la numerazione parte da 0) hanno un accesso ristretto al database delle utenze LDAP. Queste macchine sono utilizzate per servizi di minore importanza, per i backup, e altri compiti ausiliari come ad esempio fare da gateway per le connessioni ssh e VPN degli amministratori (l'avere un singolo punto di entrata non pubblico e il traffico successivo instradato attraverso le vpn in modo non tracciabile permette di mantenere un relativo anonimato per gli amministratori medesimi).
Nei punti di interconnessione tra i vari anelli sono presenti dei firewall per regolare i flussi tra un anello e l'altro. Un'altra possibilità che non abbiamo ancora esplorato è quella di avere delle macchine dedicate a questo scopo (il "gateway server" nella figura) anziché addossare questo ruolo agli stessi server. I nodi di connessione dovrebbero poter essere molteplici: stiamo studiando il modo migliore per instradare correttamente i pacchetti tra i due anelli anche se uno dei nodi non dovesse essere più raggiungibile.
2.1.1. VPN
Tinc è un demone VPN con routing automatico in grado di mantenere connessi N host con una serie di connessioni punto-punto gestite automaticamente. Inoltre effettua l'autenticazione e la crittazione basandosi su un suo set autonomo di chiavi RSA, che quindi vanno distribuite opportunamente.
È stato scelto, rispetto ad altre soluzioni, perché è molto facile da installare, e permette di nascondere le varie connessioni punto-punto tra ciascuna macchina: presenta al sistema operativo direttamente un'unica interfaccia di rete, gestendo il routing in proprio in maniera trasparente (per essere più chiari, è come se le macchine fossero tutte collegate in rete locale - anzi meglio perché si occupa automaticamente di cercare percorsi alternativi nel caso la connessione diretta tra due macchine venga a mancare).
Abbiamo scelto per questo, nei file di configurazione di esempio, la rete 172.16.0.0/16, assegnando i seguenti indirizzi IP (che saranno poi aggiunti al file /etc/hosts distribuito centralmente):
test1 172.16.1.1
test2 172.16.1.2
test3 172.16.1.3
Per comodità, è utile scegliere dei nomi per questi IP che siano chiaramente differenti rispetto a quelli usati per gli IP pubblici delle stesse macchine: per esempio utilizzando un sottodominio (test1.vpn.dominio.org) o un suffisso comune (test1-vpn.dominio.org).
Per cominciare, è stata creata la configurazione base per una rete, di nome ring0 (che corrisponde all'anello più interno dello schema di rete privata basato sul trust), in /configfiles/ring0/common/tinc/ring0, in particolare (a parte tinc-up e tinc-down) il file di configurazione principale tinc.conf:
# Sample tinc configuration file
# The name of the machine
# Name = test1
# Connections to be done
ConnectTo = test1
ConnectTo = test2
ConnectTo = test3
# The tap device to use
Device = /dev/net/tun
Nota: i nomi dei computer usati in questo file non devono necessariamente essere validi nel DNS, ma corrispondono ai files nella directory ring0/hosts. E' per la comodità di gestire la cosa con CFengine che i nomi scelti sono uguali a quelli degli host.
La directory /configfiles/ring0/common/tinc/ring0/hosts deve contenere due file per ciascun server, identificati con il loro nome senza suffisso di dominio, NOME e NOME.priv. Le chiavi RSA si possono generare con
$ tincd -n ring0 -K
Bisogna poi editare il file con la chiave pubblica per aggiungervi delle opzioni, questo è un esempio:
# The real IP address of this tinc host. Can be used by other tinc hosts. Address = 192.168.1.21 # Portnumber for incoming connections. Default is 655. Port = 655 # Subnet on the virtual private network that is local for this host. Subnet = 172.16.1.2/32 # Connection with the other ring # Subnet = 172.17.0.0/16 #IndirectData = Yes #TCPOnly = Yes # The public key generated by `tincd -n example -K' is stored here -----BEGIN RSA PUBLIC KEY----- MIGJAoGBAJGedJTd4GnIe1VssM+ROBwsMzRXbdI/reZvkLmji3YK0HJcyDIKnRZ2 /ikPJNyH1bKSWlqds28j4eG6ENM5ZjaWDETztW6OyNOt4vDxAXEQRF50WLBL5BOk e6bXlPoOtXWrVK/ZpBiDl86XpEdm0DHhETB2Cit9KNAXcW2ajnabAgMBAAE= -----END RSA PUBLIC KEY-----