Tecnologie e servizi di rete/VPN

Copertina Tecnologie e servizi di rete/Copertina

Una società che vuole creare una rete privata aziendale per i suoi terminali remoti (utenti singoli, data-center, filiali) può adottare due diversi approcci:

la società può costruire la propria infrastruttura dedicata (linea dedicata, connessione ad accesso remoto);
la società può adottare una soluzione VPN.

Una Virtual Private Network (VPN) permette a una società di distribuire la connettività a più utenti su una infrastruttura condivisa pubblica (Internet o la rete di un Internet Service Provider) forzando le proprie politiche (come la sicurezza, la qualità del servizio, l'indirizzamento privato) come se fosse la propria rete privata.

I vantaggi di una soluzione VPN sono:

economicità: non è più necessario costruire costose connessioni fisiche, ma la soluzione VPN sfrutta un'infrastruttura pre-esistente in modo che il costo sia condiviso;
selettività: grazie a un firewall possono accedere solo gli utenti che hanno i diritti → maggiore sicurezza;
flessibilità: gli utenti ammessi possono essere facilmente aggiunti, e gli utenti possono facilmente spostarsi.

Una VPN è costituita da alcuni componenti principali:

i dati vengono consegnati attraverso dei tunnel, così essi sono separati da altri dati in giro per la infrastruttura condivisa, usando protocolli come GRE, L2TP, MPLS, PPTP e IPsec;
i dati vengono crittografati per una maggiore sicurezza, usando protocolli come IPsec e MPPE;
viene verificata l'integrità dei dati, così essi non possono essere manomessi, grazie al checksum TCP o ad AH in IPsec;
prima di instaurare un tunnel, viene verificata l'identità di chi sta dall'altra parte del tunnel attraverso dei meccanismi di autenticazione (per esempio usando i certificati digitali).

Classificazione

Le soluzioni VPN si possono classificare in base a:

distribuzione: di accesso o site-to-site (intranet/extranet);
accesso a Internet: centralizzato o distribuito;
modello: overlay o peer;
provision: customer o provider;
livello: livello 2, livello 3 o livello 4;
topologia virtuale: hub and spoke o mesh.

	overlay	peer
access	L2TP, PPTP
site-to-site	IPsec, GRE	MPLS

Scenari di distribuzione

Le VPN possono essere distribuite in due scenari principali:

VPN di accesso (anche chiamata "VPN remota" o "dial in virtuale"): virtualizza la connessione ad accesso remoto e connette un singolo utente a una rete aziendale attraverso ISDN, PSTN, modem via cavo, LAN senza fili usando protocolli come PPTP e L2TP;
VPN site-to-site: virtualizza la linea dedicata e connette più reti remote tra loro usando protocolli come IPsec, GRE e MPLS.

Le VPN site-to-site possono essere distribuite in due modi:

VPN intranet: tutte le reti interconnesse appartengono alla stessa società;
VPN extranet: le reti interconnesse appartengono a più società.

Le funzionalità di una VPN devono rispettare alcuni requisiti:

sicurezza: un firewall può limitare l'accesso alle risorse della rete;
crittografia dei dati: per proteggere le informazioni trasmesse su un'infrastruttura condivisa;
affidabilità: si deve garantire che il traffico mission critical arrivi a destinazione;
scalabilità: la soluzione deve funzionare per reti sia piccole sia grandi;
distribuzione incrementale: la soluzione continua a funzionare mentre la rete cresce;
requisiti aggiuntivi per le VPN di accesso:
- autenticazione forte: per verificare le identità degli utenti mobili (ad es. un computer portatile personale potrebbe essere rubato);
- gestione centralizzata degli utenti e dei loro account;
requisiti aggiuntivi per le VPN extranet site-to-site:
- accesso selezionato: ogni società può dare ad altre società l'accesso ad alcuni servizi ma impedire l'accesso ad altri servizi della sua rete privata;
- gestione delle collisioni di indirizzi: un indirizzo privato può appartenere a due diverse reti private → è necessario un NAT;
- utilizzo di una soluzione aperta basata su uno standard: società diverse devono poter condividere la stessa soluzione VPN;
- controllo del traffico: ogni società ha bisogno di controllare la quantità di traffico in entrata proveniente dalle reti di altre società e di eliminare i colli di bottiglia ai punti di accesso della rete.

Accesso a Internet

Un terminale remoto connesso a una VPN può accedere all'Internet pubblico in due modi:

accesso a Internet centralizzato: tutto il traffico da e verso Internet passa sempre attraverso il gateway VPN della sede centrale;
accesso a Internet distribuito: il traffico da e verso Internet non coinvolge la VPN, che è distribuita solo per il traffico aziendale.

Accesso a Internet centralizzato

Vantaggi

gestione delle politiche centralizzata: una società può imporre le proprie politiche per l'accesso ad Internet (ad es. proibendo ai dipendenti di accedere a certi siti Web mentre stanno lavorando) una volta per tutti i terminali remoti connessi;
vantaggio di sicurezza: il firewall aziendale può proteggere gli host dai pacchetti malevoli provenienti da Internet.

Svantaggi

velocità minore ai terminali remoti: i pacchetti da e verso Internet devono viaggiare per un maggior numero di hop perché devono sempre passare attraverso il gateway VPN della sede centrale invece di dirigersi direttamente verso la destinazione;
maggiore larghezza di banda richiesta alla sede centrale;
connessione obbligata: la VPN deve essere sempre attiva, cioè l'utente non deve poter disabilitare temporaneamente la VPN e navigare su Internet senza la protezione del firewall aziendale, altrimenti se viene infettato quando ritorna alla VPN infetterà la rete aziendale perché il traffico che proviene da lui non è protetto dal firewall.

Accesso a Internet distribuito

Vantaggi

velocità maggiore ai terminali remoti: i pacchetti si dirigono sempre verso la destinazione su Internet;
connessione volontaria: l'utente può disabilitare la VPN in qualsiasi momento senza rischi aggiuntivi per la sicurezza.

Svantaggi

gestione delle politiche distribuita: la società deve configurare più router ai terminali remoti per imporre le proprie politiche;
minaccia per la sicurezza: manca la protezione del firewall aziendale.

Modelli

Modello overlay.
Modello peer.

Le VPN si possono suddividere in due modelli a seconda del ruolo dell'infrastruttura condivisa:

modello overlay: l'infrastruttura non è consapevole della soluzione VPN e offre solo il servizio di connettività IP: trasporta solo i pacchetti, senza sapere che sono pacchetti VPN, tra i gateway VPN che non interagiscono con l'infrastruttura → adatto per la privacy dei dati: il gestore dell'infrastruttura non può guardare dati privati né può approfittare di informazioni sull'instradamento;
modello peer: i gateway all'interno dell'infrastruttura partecipano alla creazione della VPN e interagiscono tra loro → instradamento migliore, più scalabilità.

Le VPN con modello peer non basate su MPLS possono essere:

a router dedicato: il gestore dell'infrastruttura dedica alcuni router completamente a un cliente, altri completamente a un altro cliente, e così via;
a router condiviso: ogni router nell'infrastruttura è condiviso tra più clienti → costo minore.

Provision

Provider provision.
Customer provision.

Le VPN possono essere customer o provider provisioned:

customer provision: l'utente crea e gestisce la VPN da solo, e i tunnel vengono instaurati tra Customer Edge (CE);
provider provision: la VPN è fornita e gestita interamente dal fornitore della connettività Internet, e i tunnel vengono instaurati tra Provider Edge (PE).

Le VPN customer provisioned non possono essere con modello peer perché il fornitore non può essere consapevole di una VPN che il cliente ha creato da sé.

Livelli

La connettività VPN può essere a livelli diversi:

livello 2: nella VPN vengono scambiate trame Ethernet:
- Virtual Private LAN Service (VPLS): virtualizza una LAN: i terminali sono connessi come se fossero nella stessa LAN → i pacchetti broadcast sono consentiti;
- Virtual Private Wire Service (VPWS): virtualizza una linea dedicata (su una rete a commutazione di pacchetto);
- IP-only LAN-like Service (IPLS): virtualizza una rete IP, ma sono consentiti solo i pacchetti IP (ICMP e ARP);
livello 3: nella VPN vengono scambiati pacchetti IP;
livello 4: nella VPN vengono instaurate connessioni TCP (eventualmente con SSL per la sicurezza).

Topologie virtuali

Le VPN si possono suddividere in due categorie in base alla topologia virtuale:

hub and spoke: ogni coppia di terminali può comunicare l'uno con l'altro solo passando per la sede centrale → può avvenire un collo di bottiglia alla sede centrale a causa del traffico più alto;
mesh: ogni coppia di terminali può comunicare l'uno con l'altro direttamente senza passare per la sede centrale → l'instradamento è migliore, ma il numero di tunnel è più alto.

Protocolli

PPP

Point-to-Point Protocol (PPP) è un protocollo di livello 2 usato nelle connessioni punto punto (ad accesso remoto, ISDN) per incapsulare qualsiasi protocollo di livello superiore. È un'estensione di HDLC.

Un pacchetto PPP ha il seguente formato:

1 byte	1 byte	1 byte	1 o 2 byte		2 o 4 byte	1 byte
01111110 (flag)	Address	Control	Protocol	Data	CRC	01111110 (flag)

dove i campi più significativi sono:

flag iniziale e finale: sono necessari per la delimitazione dei dati;
campi Address e Control: sono ereditati da HDLC ma sono completamente privi di significato nelle connessioni punto punto; sono stati mantenuti per rendere semplice l'aggiornamento degli algoritmi di elaborazione negli apparati HDLC;
campo Protocol: specifica il protocollo di livello superiore del pacchetto incapsulato.

"01111110" è la sequenza che delimita la trama, ma per inviare quella sequenza come dati sono necessarie delle regole di stuffing. In PPP lo stuffing è al livello dei byte: la sequenza di escape "01111101" è inserita sia quando nei dati compare un byte uguale al byte di delimitazione, sia quando compare un byte uguale al byte di escape stesso:

Link Control Protocol (LCP) ha il compito di aprire e chiudere le connessioni PPP, negoziando alcune opzioni (come la massima lunghezza delle trame, il protocollo di autenticazione).

GRE

Un pacchetto IP non può incapsulare direttamente un protocollo di livello 3 o inferiore, perché il campo "Protocol" nell'intestazione IPv4 può specificare solo protocolli di livello superiore (come TCP, UDP, ICMP).

Generic Routing Encapsulation (GRE) è un protocollo per incapsulare qualsiasi protocollo (compresi IP e altri protocolli di livello inferiore) in IP: l'intestazione GRE è inserita tra l'intestazione IP incapsulante e il pacchetto incapsulato, e il campo "Protocol" nell'intestazione IP incapsulante è impostato a 47.

L'intestazione GRE ha il formato seguente:

				5	8	13	16	32
C	R	K	S	s	Recur	Flags	Version (0)	Protocol type
Checksum (facoltativo)								Offset (facoltativo)
Key (facoltativo)
Sequence number (facoltativo)
Routing (facoltativo) :::

dove i campi più significativi sono:

flag C, R, K, S (1 bit ciascuno): indicano la presenza/assenza dei campi facoltativi;
flag strict source routing (s) (1 bit): se impostato a 1, il pacchetto viene scartato se, quando la lista di source routing (campo "Routing") finisce, la destinazione non è ancora stata raggiunta (simile a TTL);
campo Recur (3 bit): specifica il massimo numero di incapsulamenti aggiuntivi consentito (attualmente non supportato);
campo Version (3 bit): specifica la versione del protocollo GRE (0 in questo caso);
campo Protocol type (16 bit): specifica il protocollo del pacchetto incapsulato;
campo Routing: specifica una sequenza di indirizzi IP corrispondenti ai router intermedi attraverso cui deve passare il pacchetto (source routing).

Il campo "Routing" è a sua volta costituito da alcuni campi (oltre alla lista degli indirizzi IP), tra cui:

campo Address family: specifica il tipo degli indirizzi nella lista (IP in questo caso);
campo SRE Offset: è un puntatore all'elemento della lista contenente l'indirizzo IP del next hop corrente, aggiornato ad ogni hop di source routing;
campo SRE Length: specifica la lunghezza della lista (in byte).

Enhanced GRE

Il formato dell'intestazione Enhanced GRE introduce il nuovo campo "Acknowledgment number":

				5	8		13	16	32
C	R	K	S	s	Recur	A	Flags	Version (1)	Protocol type
Key (lunghezza payload)									Key (call ID)
Sequence number (facoltativo)
Acknowledgment number (facoltativo)

dove i campi più significativi sono:

campo Key (32 bit):
- lunghezza payload (16 bit): specifica la lunghezza del pacchetto esclusa l'intestazione GRE (in byte);
- call ID (16 bit): specifica l'ID di sessione del pacchetto;
campo Acknowledgment number (32 bit): il mittente mette nel pacchetto il numero di sequenza dell'ultimo pacchetto che ha ricevuto dalla destinazione (ACK cumulativo).

Il nuovo campo "Acknowledgment number", in combinazione con il campo "Sequence number", consente alcuni meccanismi aggiuntivi:

controllo di flusso: le finestre scorrevoli evitano di inondare la destinazione, e si spostano quando vengono ricevuti i pacchetti ACK;
rilevamento dei pacchetti out-of-order: Enhanced GRE è stato progettato per l'incapsulamento di PPP, e PPP è un protocollo per connessioni punto punto dove non è previsto che i pacchetti arrivino out-of-order → i pacchetti out-of-order vengono sempre scartati;
rilevamento dei pacchetti persi: quando un timeout scade, cioè nessun ACK è stato ricevuto, il pacchetto viene rilevato come perso, ma i pacchetti persi rilevati non vengono ritrasmessi;
controllo di congestione: quando vengono rilevati troppi timeout, la trasmissione dei pacchetti viene rallentata per non congestionare la rete.

L2TP

Layer 2 Tunneling Protocol (L2TP) è un protocollo per far passare in un tunnel IP qualsiasi protocollo di livello 2 (PPP in questa trattazione). L2TP fu originariamente progettato per VPN di accesso provider provisioned e fu standardizzato da IETF; in seguito fu esteso alle VPN di accesso customer provisioned semplicemente implementando le funzionalità del LAC nella macchina dell'utente.

Nello scenario di riferimento originale per L2TP, un utente remoto vuole inviare un pacchetto attraverso una connessione punto punto (PPP) ad un server interno all'interno della rete aziendale. Sono necessari un tunnel L2TP verso l'L2TP Network Server (LNS) di destinazione e una sessione L2TP all'interno del tunnel per emulare la connessione PPP sulla rete del service provider.

Quando la trama PPP arriva all'L2TP Access Concentrator (LAC), se non è ancora stato stabilito un tunnel L2TP verso l'LNS, prima di aprire una sessione L2TP il LAC deve stabilire un tunnel verso l'LNS: l'LNS si autentica al LAC usando un meccanismo basato su challenge simile al Challenge Handshake Authentication Protocol (CHAP), e viene creata una nuova connessione di controllo.

Ogni sessione L2TP usa due canali all'interno del tunnel:

canale dati: per trasportare i messaggi di dato, cioè le trame PPP;
canale di controllo: per scambiare i messaggi di controllo, che servono per gestire la comunicazione (come verificare che i pacchetti arrivino, ritrasmettere i pacchetti persi, controllare il giusto ordine dei pacchetti).

Al contrario dei messaggi di dato, i messaggi di controllo vengono scambiati in modo affidabile: i messaggi di controllo persi vengono sempre ritrasmessi.

Possono coesistere più sessioni dentro lo stesso tunnel, che condividono la stessa connessione di controllo, per distinguere più flussi di trame PPP di più utenti remoti: ogni tunnel è identificato da un tunnel ID, ogni sessione è identificata da un session ID.

Sicurezza

Oltre all'autenticazione assicurata durante la fase di stabilimento del tunnel, L2TP non fornisce di per sé alcun meccanismo di sicurezza: infatti non ha senso usare meccanismi come la crittografia per i pacchetti L2TP che viaggiano lungo il tunnel, perché il LAC del service provider può comunque guardare le trame di livello 2 → qualsiasi meccanismo di sicurezza va implementato end-to-end, cioè tra l'utente e la destinazione finale nella rete aziendale.
Opzionalmente è possibile usare IPsec attraverso il tunnel: esso fornisce una sicurezza forte ma è complicato da implementare.

Un pacchetto all'interno di un tunnel L2TP include diverse intestazioni incapsulate:

intestazione MAC

intestazione IP

intestazione UDP

intestazione L2TP

intestazione PPP

payload PPP

Intestazione PPP

Identifica la connessione punto punto tra l'utente remoto e il server interno nella rete aziendale.

Intestazione L2TP

Identifica il tunnel L2TP:

						8		16	32
T	L	0	S	0	O	P	0	Version (2)	Length
Tunnel ID									Session ID
Ns									Nr
Offset size									Offset pad :::

dove i campi più significativi sono:

flag T (1 bit): se impostato a 0 il pacchetto è un messaggio di dato, se impostato a 1 è un messaggio di controllo;
campo Tunnel ID (16 bit): identifica il tunnel L2TP;
campo Session ID (16 bit): identifica la sessione L2TP, cioè il canale dati nel tunnel;
campo Ns (16 bit): contiene il numero di sequenza del messaggio di dato/controllo;
campo Nr (16 bit): contiene il numero di sequenza del prossimo messaggio di controllo da ricevere per una connessione di controllo affidabile.

Intestazione UDP

Perché viene usato un protocollo di livello 4 come UDP per spostare delle trame di livello 2? Ciò si può spiegare tenendo conto dei firewall in una rete generale: se un pacchetto non contiene un incapsulamento di livello 4, è più facile che venga scartata dai firewall.
Un'altra possibile motivazione è che al livello 4 si può accedere tramite i socket, mentre il sistema operativo è responsabile del livello 3. Siccome L2TP vuole essere una soluzione contro PPTP (proposto dai fornitori di sistemi operativi), i progettisti di L2TP hanno voluto renderlo accessibile alle applicazioni e non essere legati al volere dei fornitori di sistemi operativi.
È anche possibile usare un protocollo di livello 4 diverso (come ATM, Frame Relay).

Intestazione IP

Contiene gli indirizzi IP delle estremità del tunnel.
Nello scenario di riferimento originale, gli indirizzi IP corrispondono al LAC e all'LNS.

PPTP

Point-to-Point Tunneling Protocol (PPTP) è un protocollo per far passare in un tunnel IP il protocollo PPP. PPTP fu originariamente sviluppato per le VPN di accesso customer provisioned e fu sviluppato dai più importanti fornitori di sistemi operativi; in seguito fu esteso alle VPN di accesso provider provisioned con l'introduzione di un PPTP Access Concentrator (PAC) con funzionalità simili a quelle del LAC.

Lo scenario di riferimento originale per PPTP si differenzia da quello per L2TP per il fatto che il tunnel PPTP viene stabilito tra l'utente remoto stesso e il PPTP Network Server (PNS).

A differenza di L2TP, PPTP fornisce dei deboli meccanismi di sicurezza (facoltativi): lo standard copre l'uso di specifici protocolli di sicurezza proprietari Microsoft come MPPE per la crittografia e MS CHAP per l'autenticazione, così non c'è alcuna negoziazione di protocolli.

Canale dati

Per il canale dati passano le trame PPP incapsulate:

intestazione IP

intestazione GRE

intestazione PPP

payload PPP

PPTP utilizza il protocollo Enhanced GRE per incapsulare le trame PPP in IP. Il payload PPP può essere opzionalmente criptato con MPPE.

Canale di controllo

Per il canale di controllo passano i messaggi di controllo PPTP:

intestazione IP

intestazione TCP

messaggio di controllo PPTP

I messaggi di controllo sono necessari per l'instaurazione, la gestione e l'abbattimento della sessione dati del tunnel, e vengono inviati alla well-known port TCP 1723 del PNS.

IPsec

Le funzionalità della suite di protocolli Internet Protocol Security (IPsec) in IPv4 sono molto simili a quelle in IPv6: Tecnologie e servizi di rete/IPv6#IPsec.

La differenza principale è che in IPv6 IPsec è un extension header incluso nello standard, mentre in IPv4 è un nuovo protocollo aggiuntivo incapsulato in IP (per AH il campo "Protocol" è impostato a 51, per ESP è impostato a 50):

**Authentication Header (AH).**
intestazione IPv4	intestazione AH	intestazione TCP/UDP	payload
dati autenticati

**Encapsulating Security Payload (ESP).**
intestazione IPv4	intestazione ESP (per la crittografia)	intestazione TCP/UDP	payload	autenticazione ESP
		dati criptati
	dati autenticati

SSL

Secure Sockets Layer (SSL), oggi chiamato Transport Layer Security (TLS), è un protocollo crittografico che è progettato per fornire la sicurezza di comunicazione tra un client e un server:

il client apre una connessione TCP sulla porta 443 con il server, e invia un challenge per l'autenticazione del server;
il server invia al client un messaggio Hello contenente il suo certificato e la risposta al challenge criptato con la chiave privata del server;
il client verifica il certificato guardando in una lista di certificati data da una autorità di certificazione fidata, quindi decripta la risposta al challenge utilizzando la chiave pubblica del server;
il client decide una chiave privata per la comunicazione sicura e la invia al server criptandola tramite la chiave pubblica del server → da questo punto in avanti tutti i messaggi di record verranno criptati utilizzando questa chiave privata (che va periodicamente rinegoziata);
spesso il server chiede all'utente di digitare nome utente e password su una pagina Web per l'autenticazione del client (a livello applicazione).

VPN di accesso

Scenario con connessione ad accesso remoto

Fondamentalmente un utente remoto, tipicamente un dipendente di una società, vuole contattare un server passando per la rete aziendale. Può stabilire una connessione punto punto ad accesso remoto con il gateway aziendale che usa PPP per incapsulare i pacchetti IP:

tramite Link Control Protocol (LCP) può negoziare i parametri di livello 2 (come il protocollo di autenticazione);
tramite Network Control Protocol (NCP) può negoziare i parametri di livello 3 (come l'indirizzo IP privato nella rete aziendale, il DNS).

Prima di accettare la connessione ad accesso remoto, il gateway aziendale verifica l'utente contattando il security server aziendale tramite il protocollo Remote Authentication Dial In User Service (RADIUS). Il security server aziendale è un server AAA centralizzato:

Authentication: identificare l'utente (per es. tramite nome utente e password);
Authorization: verificare a quali servizi può accedere l'utente e quali sono limitati all'utente;
Accounting: tenere traccia dell'attività dell'utente (per es. per addebito).

Le VPN di accesso sono in grado di virtualizzare le connessioni ad accesso remoto tra un utente remoto e la rete aziendale sull'infrastruttura condivisa del service provider per ridurre i costi. Continuerà ad essere usato il protocollo PPP incapsulato nei tunnel della VPN, evitando di cambiare troppo il gateway aziendale.

Customer provision

Nelle VPN di accesso customer provisioned, il tunnel viene stabilito tra l'utente remoto e il gateway aziendale:

l'utente richiede di stabilire una connessione ad accesso remoto PPP con il NAS del service provider, chiedendo di negoziare i parametri di configurazione per la connessione tramite LCP e NCP;
il NAS verifica l'identità dell'utente attraverso il security server del provider usando il protocollo RADIUS;
il NAS fornisce all'utente i parametri di configurazione per la connessione ad accesso remoto PPP, in particolare l'indirizzo IP pubblico;
l'utente richiede di aprire un tunnel VPN con il gateway aziendale, inviando una trama PPP contenente un pacchetto IP il cui indirizzo IP di destinazione è l'indirizzo IP pubblico del gateway aziendale;
il NAS inoltra la richiesta sulla rete del service provider al gateway aziendale;
il gateway aziendale verifica l'identità dell'utente attraverso il security server aziendale usando il protocollo RADIUS;
il gateway aziendale fornisce all'utente i parametri di configurazione per il tunnel VPN, in particolare l'indirizzo IP privato nella rete aziendale;
il NAS inoltra la risposta del gateway aziendale all'utente remoto.

Una volta instaurata la VPN, l'utente ha due indirizzi IP: uno pubblico per il NAS del service provider e uno aziendale per il gateway aziendale. Le trame PPP che l'utente può inviare attraverso il tunnel hanno il seguente formato:

intestazione PPP	intestazione IP		intestazione PPP	intestazione IP		payload IP
	src:	indirizzo IP pubblico dell'utente		src:	indirizzo IP aziendale dell'utente
	dst:	indirizzo IP pubblico del gateway aziendale		dst:	indirizzo IP aziendale/pubblico della destinazione finale

Vantaggio

L'utente è indipendente dal service provider: quest'ultimo infatti fornisce all'utente solo la connessione a Internet al gateway aziendale.

Svantaggio

L'utente può disabilitare temporaneamente la connessione VPN e connettersi ad un server esterno su Internet → se prende un malware, quando ritorna alla VPN infetterà la rete aziendale.

Provider provision

Nelle VPN di accesso provider provisioned, il tunnel viene stabilito tra il NAS del service provider e il gateway aziendale:

l'utente richiede di stabilire una connessione ad accesso remoto PPP con il gateway aziendale, chiedendo di negoziare i parametri di configurazione per la connessione tramite LCP e NCP;
il NAS verifica l'identità dell'utente attraverso il security server del provider usando il protocollo RADIUS, in particolare identificando l'utente come un utente della VPN;
il NAS richiede di aprire un tunnel VPN, correlato all'utente, con il gateway aziendale, inviando un pacchetto IP il cui indirizzo IP di destinazione è l'indirizzo IP pubblico del gateway aziendale;
il gateway aziendale verifica l'identità dell'utente attraverso il security server aziendale usando il protocollo RADIUS;
il gateway aziendale fornisce al NAS i parametri di configurazione per il tunnel VPN;
il NAS registra opzionalmente l'accettazione e/o il traffico per far pagare il servizio alla società;
il gateway aziendale fornisce all'utente i parametri di configurazione per la connessione PPP (l'accesso remoto è virtualizzato), in particolare l'indirizzo IP privato nella rete aziendale;
il NAS inoltra la risposta del gateway aziendale all'utente remoto.

Una volta instaurata la VPN, l'utente ha solo l'indirizzo IP aziendale, non consapevole del tunnel tra il NAS del service provider e il gateway aziendale. I pacchetti IP che il NAS può inviare attraverso il tunnel hanno il seguente formato:

intestazione IP		intestazione PPP	intestazione IP		payload IP
src:	indirizzo IP pubblico del NAS del service provider		src:	indirizzo IP aziendale dell'utente
dst:	indirizzo IP pubblico del gateway aziendale		dst:	indirizzo IP aziendale/pubblico della destinazione finale

Vantaggio

L'utente non può accedere ad Internet senza passare per il gateway aziendale (accesso centralizzato) → maggiore sicurezza.

Svantaggio

L'utente non è indipendente dal service provider: infatti se cambia service provider la connessione VPN non funzionerà più.

VPN site-to-site

VPN basate su IPsec

Nelle VPN basate su IPsec, IPsec viene usato in tunnel mode tra i gateway VPN: il pacchetto IP tra i due host viene incapsulato in un pacchetto IP, che ha l'intestazione ESP (e opzionalmente l'intestazione AH), tra i due gateway VPN, in modo che anche gli indirizzi IP dei due host possano essere criptati da ESP.

La intranet privata può essere protetta da:

un firewall: filtra il traffico secondo le politiche aziendali per esempio riguardanti gli indirizzi IP ammessi, e può essere messo in diverse posizioni in relazione al gateway VPN:
- prima del gateway VPN: il gateway VPN è protetto, ma il firewall non può filtrare il traffico VPN perché è criptato;
- dopo il gateway VPN: il firewall può filtrare il traffico VPN decriptato, ma il gateway VPN non è protetto;
- in parallelo al gateway VPN: i pacchetti passano per il firewall sia prima sia dopo il gateway VPN, così il gateway VPN è protetto e il traffico VPN è filtrato, ma il carico di lavoro per il firewall è maggiore;
- integrato nel gateway VPN: entrambe le funzionalità di gateway VPN e di firewall sono integrate in un unico apparato → massima flessibilità;
un Intrusion Detection System (IDS): osserva il traffico provando a rilevare se ci sono degli attacchi in corso, e vengono messe due sonde IDS in parallelo con il gateway VPN:
- la sonda prima del gateway VPN osserva il traffico che arriva dal tunnel e protegge dagli attacchi provenienti dall'infrastruttura condivisa;
- la sonda dopo il gateway VPN osserva il traffico della VPN e protegge dagli attacchi provenienti dalla rete aziendale (ad es. malware installato sui PC dei dipendenti, attacchi da un'altra società se la VPN site-to-site è extranet).

La presenza di NAT potrebbe provocare dei problemi con IPsec:

AH autentica l'intero pacchetto, quindi comprende anche l'intestazione IP → i NAT hanno bisogno di cambiare gli indirizzi IP, quindi l'autenticazione non funzionerà più;
ESP cripta il payload, quindi i NAT posizionati lungo il tunnel non saranno in grado di vedere gli indirizzi IP e le porte TCP/UDP criptati per gestire siti VPN diversi.

VPN basate su MPLS

Livello 2: PWE3

Lo standard Pseudo Wire Emulation End-to-End (PWE3) permette di emulare fili su una rete MPLS per scambiare trame Ethernet tra terminali di livello 2 quali switch Ethernet e centralini telefonici.^[1] Questo tipo di connessione richiede alcuni requisiti in termini di ritardi costanti delle trame Ethernet come se esse viaggiassero su un filo fisico.

Il traffico è trasportato attraverso un LSP, quindi deve poter andare ad uno tra più siti collegati a interfacce diverse dell'LSR ingress/egress:

etichetta esterna: identifica l'LSP tra due LSR ingress/egress, ed è seguita da una tra più etichette interne;
etichetta interna: identifica il tunnel VPN per una società, e l'LSR ingress/egress la usa per inviare la trama fuori da una delle sue interfacce verso il sito della società.

Le VPN di livello 2 basate su MPLS non sfruttano tutti i vantaggi di MPLS, perché i protocolli di instradamento per il traffic engineering lavorano bene con IP → di solito gli LSP vengono configurati manualmente.

Livello 3: BGP

Border Gateway Protocol (BGP) è stato esteso a internal BGP e external BGP per supportare la distribuzione delle VPN su MPLS, per esempio per il sito 1 della società A:

CE1 della società A annuncia a PE1 le destinazioni nel sito 1, cioè dice a PE1 tutti gli indirizzi IP che possono essere raggiunti nel sito 1, attraverso l'internal BGP;
PE1 assegna una etichetta ad ogni indirizzo IP da CE1 e registra il mapping in una tabella VPN Routing and Forwarding (VRF) specifica della porta verso CE1;
PE1 annuncia le etichette scelte agli altri PE attraverso l'external BGP inviando pacchetti contenenti ciascuno un indirizzo IP più un route distinguisher che identifica la famiglia di indirizzi, che effettivamente è la porta verso il sito della società A, utile nel caso ci siano due indirizzi privati identici in due diverse reti aziendali.
Questa fase deve essere effettuata manualmente: l'amministratore del sistema deve aprire una peering session tra PE1 e ciascuno degli altri PE nella rete MPLS;
gli altri PE possono elaborare i messaggi di advertisement o ignorarli:
- ogni altro PE a cui è collegato uno dei siti della società A (nella figura PE3) registra nella sua tabella VRF le informazioni annunciate da PE1, cioè l'etichetta scelta per ogni destinazione IP nel sito 1, in altre parole gli indirizzi IP associati alla famiglia di indirizzi del sito 1, più l'indirizzo IP di PE1;
- ogni altro PE a cui non è collegato alcun sito della società A (nella figura PE2) ignora semplicemente le informazioni annunciate da PE1;

Una volta che le destinazioni IP sono state annunciate tra i PEs, si può iniziare ad inviare dati della VPN lungo gli LSP MPLS, per esempio da CE3 della società A a CE1 della società A:

PE3, cioè l'LSR ingress, effettua l'operazione di push di due etichette nella pila delle etichette:
- etichetta interna: quella precedentemente annunciata da PE1;
- etichetta esterna: quella decisa dagli LSR attraverso i protocolli MPLS per label binding, distribution e mapping per l'LSP da PE3 a PE1;
gli LSR intermedi non si preoccupano dell'etichetta interna, ma operano solo sull'etichetta esterna lungo l'LSP;
l'ultimo LSR subito prima di PE1 rimuove l'etichetta esterna (penultimate label popping) e invia il pacchetto a PE1;
PE1, che è l'LSR ingress, cerca nelle sue tabelle VRF l'etichetta interna e trova la porta dove far uscire il pacchetto, quindi rimuove anche l'etichetta interna e invia il pacchetto a CE1.

Vantaggio

Questa soluzione è molto scalabile:

ogni LSR intermedio deve avere a che fare con tanti LSP quanti sono i PE, not con tanti LSP quante sono le destinazioni IP;
ogni PE deve avere a che fare con tante tabelle VRF quanti sono i siti ad esso collegati.

Svantaggio

Le peering session tra i PE sono da configurare manualmente.

Questa soluzione non fornisce alcuna crittografia perché è provider provisioned e la società deve fidarsi del service provider.

Livello 3: virtual router

Nelle VPN basate su MPLS con virtual router, ogni PE esegue un'istanza di (virtual) router per ogni società che è collegata ad esso, in modo che ogni istanza debba avere a che fare solo con una rete aziendale → il protocollo è più semplice perché deve avere a che fare solo con una VPN alla volta, ma la scalabilità è minore perché le istanze di router devono essere configurate manualmente.

(Pseudo)VPN SSL

SSL può essere usato per creare delle VPN site-to-site e di accesso, ma è principalmente utilizzato nelle (pseudo)VPN SSL per garantire un accesso sicuro ai servizi (come servizio Web, posta elettronica) tramite il tunneling basato su TCP/UDP. Il vantaggio principale delle (pseudo)VPN SSL è che hanno una buona probabilità di funzionare in qualsiasi scenario di rete, senza alcun problema nell'attraversare i NAT, i firewall e i router, e i servizi SSL possono anche essere acceduti da browser Web attraverso HTTPS.

Confronto con soluzioni alternative

Confronto con IPsec

Vantaggi

SSL è più conveniente di IPsec in termini di:

utilizzo: IPsec ha troppe opzioni da configurare e da amministrare, mentre SSL richiede solo di compilare l'applicazione insieme a una libreria che implementa SSL;
sicurezza: lavora a livello applicazione → un attacco a SSL coinvolge solo l'applicazione e non l'intero sistema operativo;
maturità: è usato da molti anni con molte versioni → pochi bug nel codice;
compatibilità con il NAT traversal:
- nessuna autenticazione dell'intestazione IP perché l'SSL è sopra il livello trasporto;
- nessuna crittografia delle porte come con ESP di IPsec.

Svantaggio

SSL è critico con gli attacchi DoS: i pacchetti hanno sempre bisogno di essere elaborati fino al livello trasporto, mentre in IPsec essi vengono scartati già a livello rete.

Confronto con PPTP

SSL supera alcuni problemi di PPTP:

interoperabilità scarsa con piattaforme non Microsoft;
alcuni amministratori di rete potrebbero configurare i router per bloccare GRE, su cui si basa PPTP, a causa del fatto che a loro non piace la funzionalità di source routing.

Flavor di (pseudo)VPN SSL

Web proxying

Il server Web non supporta HTTPS → un "VPN gateway",^[2] al margine della rete aziendale, scarica le pagine Web dal server Web tramite HTTP, e le consegna all'utente, al di fuori della rete aziendale, tramite HTTPS.

Port forwarding

Il client esegue un'applicazione che supporta un protocollo applicativo (come FTP, SMTP, POP3) → un port forwarder installato sul client converte i pacchetti, inviati a una specifica porta, dal protocollo applicativo in pacchetti HTTPS inviandoli da un'altra porta, e viceversa.

Application translation

Il server Web è un server applicativo (ad es. server di posta) che supporta un protocollo applicativo (come FTP, SMTP, POP3) → il "gateway VPN" converte HTTPS nel protocollo applicativo e viceversa tramite un meccanismo di port forwarding implementato nel "gateway VPN".

Protocolli SSL'ed

Alcuni protocolli applicativi possono integrare nativamente SSL in se stessi (ad es. SMTP-over-SSL, POP-over-SSL) → il client e il server Web possono comunicare direttamente in modo sicuro senza la necessità della traduzione da parte di un "gateway VPN".

Application proxying

Il client utilizza un protocollo SSL'ed, ma il server Web non lo supporta → è ancora necessario un "gateway VPN" con meccanismo di port forwarding.

Network extension

Sia il client sia il server Web non supportano SSL → sono necessari due "gateway VPN", uno dal lato dell'utente e l'altro dal lato del server Web, così il tunnel SSL viene creato tra i due "gateway VPN".^[3]

Note

↑ È anche possibile usare i router come terminali, ma ha pochissimo senso.
↑ Questa è una definizione lasca di gateway VPN: in verità sarebbe più accurato definirlo come un proxy.
↑ Questa non è una (pseudo)VPN SSL.

[1] È anche possibile usare i router come terminali, ma ha pochissimo senso.

[2] Questa è una definizione lasca di gateway VPN: in verità sarebbe più accurato definirlo come un proxy.

[3] Questa non è una (pseudo)VPN SSL.

[1]

[2]

[3]