Entrambi i tipi di VPN hanno i loro vantaggi e svantaggi. Ai tempi del progetto, la scelta del tipo di VPN da utilizzare fu quasi obbligatoria, in quanto il server VPN erà già stato creato ed era in uso sulla rete del quartier generale in California. Per poter capire la loro scelta, è necessario dare un'occhiata alla rete alla quale avrei dovuto collegarmi. Questa rete incredibilmente costosa (ed ora anche generosamente decorata, a partire dagli chassis esterni sino ai temi dei desktop) era temporanea; il progetto avrebbe potuto continuare per due o tre mesi dopo il festival, ma quasi sicuramente l'intero edificio sarebbe stato svuotato e il suo contenuto messo su qualche camion per essere riportato verso ovest, da dove veniva. Non esistevano porte Ethernet nei muri, nessun quadro appeso alle pareti, solo molti mobili e tendaggi esotici; con un buon gruppo di operai per il trasloco, tutto sarebbe potuto essere smontato e spedito in pochi minuti.
Tra le priorità più alte consideravo velocità e praticità d'uso, mentre la massima sicurezza era relegata alla parte più bassa della classifica. Le cose stavano accadendo ORA, persino oggi, riguardandomi indietro dopo anni, ripenso come tutto potesse funzionare così bene. Sotto quelle circostanze, scelsi PPTP. So che questa scelta contraddice completamente i fondamenti logici che che mi avrebbero spinto a scegliere un metodo di codifica wireless ma, come ogni altra cosa che ho scritto in questa serie di articoli, c'è un piano preciso dietro la mia pazzia.
Figura 3: Configurazione del Server VPN
Come mostrato in Figura 3, sarebbe stato possibile aggiungere un Server VPN al Controller di Dominio/Server DHCP assegnandogli il ruolo di Server per Accesso Remoto. Il quartier generale della società utilizzava già un server PPTP in California, quindi il mio lavoro consisteva solamente nella creazione del client. Una connessione VPN di questo tipo deve essere stabilita in modo tale che il Controller di Dominio del server e dei client si parlino attraverso i rispettivi firewall. I tecnici californiani erano responsabili dell'adeguata configurazione delle policies di accesso remoto, mentre io ero responsabile del completamento del tunnel.
I tecnici del quartier generale, hanno dovuto configurare non solo il server VPN, ma anche un server WINS, per permettere ai client VPN di navigare i file della rete in remoto.
Il mio obiettivo invece fu triplice: stabilire un collegamento tra la rete che avevo costruito e quella centrale in California, configurare il Pix 525 così che il collegamento funzionasse al meglio ed assicurarmi che i Client VPN utilizzassero NetBIOS per inviare il proprio nome e indirizzo IP al server WINS. Invece che collegare individualmente ciascun client alla VPN del quartier generale, preferii stabilire una connessione VPN dal Controller di Dominio.
La configurazione del PPTP attraverso il firewall PIX (per esempio per permettere ad un client VPN posto all'interno della rete di accedere alle risorse su un server VPN remoto, passando attraverso il firewall, invece della configurazione PPTP verso il firewall PIX che, nel nostro caso avrebbe usato un server locale che nel quartier generale in California), varia in base alla versione del firewall si stà utilizzando. Potete dare un'occhiata sul sito di Cisco per trovare una lista delle configurazioni disponibili per ogni versione del firewall.
Stavo utilizzando la versione 6.2, quindi fu necessario definire una mappa statica contenente sia gli indirizzi IP interni del Controller di Dominio che quelli esterni.
pixfirewall(config)#static (inside,outside) 163.198.1.4 192.168.1.27 netmask 255.255.255.255 0 0
Come detto precedentemente, una volta che la sessione GRE è stata inviata dal client al server, una seconda sessione viene inviata dal server al client, per gestire la prima. Il passo successivo quindi, permise di configurare la Lista di Controllo degli Accessi per consentire la connessione dal server VPN attraverso il firewall PIX:
pixfirewall(config)#access-list acl-out permit gre host 163.198.1.20 host 163.198.1.4
pixfirewall(config)#access-group acl-out in interface outside
Sostanzialmente una simile configurazione permise di gestire in modo particolare tutte le richieste rivolte a server o altre macchine non appartenenti al gruppo di indirizzi della rete locale. Qualsiasi richiesta rivolta a un indirizzo IP esterno alla nostra rete infatti, veniva inoltrato al Controller di Dominio che, una volta stabilita la connessione VPN tra il quartier generale e la rete Sundance, agiva come gateway tra i client e il quartier generale stesso.
Per esempio, ad ogni tentativo di accesso da parte di Mary al fileserver Marketing, localizzato sulla rete del quartier generale e quindi esterno al gruppo di indirizzi della rete locale, il sistema avrebbe gestito la richiesta così come qualsiasi altra richiesta di accesso ad Internet, inoltrandola cioé, al Controller di Dominio per poi rispedirla al quartier generale.
Figura 4: Configurazione di un client VPN
La Figura 4 mostra l'interfaccia che mi permise di risparmiare centinaia di ore di lavoro condividendo gli stessi database utenti, la struttura del Dominio e i diritti dei Gruppi già esistenti sulla rete del quartier generale. Per quanto riguarda i Permessi degli Accessi Remoti impostati nel server VPN, i client mantennero gli stessi privilegi di cui godevano nella rete locale... che a loro volta erano gli stessi definiti precedentemente nella rete del quartier generale. Quando Mary (per esempio) utilizzava il fileserver Marketing remoto, aveva accesso a tutti i file e a tutte le cartelle, come se si trovasse fisicamente in California; e tutto ciò con uno sforzo infinitesimale da parte mia.