Product SiteDocumentation Site

10.2. Rete privata virtuale (VPN)

Una rete privata virtuale (VPN in breve) è un modo per collegare due diverse reti locali attraverso Internet per mezzo di un tunnel che, per mantenere la riservatezza, di solito è criptato. Le VPN vengono spesso usate per integrare una macchina remota nella rete locale di un'azienda.
Esistono diversi strumenti utili a questo scopo. OpenVPN è una soluzione efficace, facile da implementare e gestire, basata su SSL/TLS. Un'altra possibilità è l'utilizzo di IPsec per cifrare il traffico IP tra due macchine; la cifratura è trasparente, il che significa che le applicazioni in esecuzione su questi host non devono essere modificate per tener conto della VPN. Può anche essere utilizzato SSH per realizzare una VPN, in aggiunta alle sue caratteristiche più convenzionali. Infine, una VPN può essere stabilita utilizzando il protocollo Microsoft PPTP. Esistono altre soluzioni, ma vanno oltre l'obiettivo di questo libro.

10.2.1. OpenVPN

OpenVPN è un software dedicato alla creazione di reti private virtuali. La sua configurazione prevede la creazione di interfacce di rete virtuali sul server VPN e sul/sui client; sono supportate entrambe le interfacce tun (per tunnel a livello IP) e tap (per tunnel a livello di Ethernet). In pratica, generalmente vengono utilizzate le interfacce tun tranne quando i client VPN vengono integrati nella rete locale del server per mezzo di un bridge (ponte) Ethernet.
OpenVPN si basa su OpenSSL per tutta la crittografia SSL/TLS e le funzioni associate (riservatezza, autenticazione, integrità, non rifiuto). Può essere configurato sia con una chiave privata condivisa che con certificati X.509 basati su un'infrastruttura a chiave pubblica. Quest'ultima configurazione è fortemente preferibile in quanto permette una maggiore flessibilità di fronte a un numero crescente di utenti in roaming che accedono alla VPN.

CULTURA SSL e TLS

Il protocollo SSL (Secure Socket Layer) è stato inventato da Netscape per rendere sicure le connessioni ai server web. È stato poi standardizzato da IETF sotto l'acronimo TLS (Transport Layer Security). Da allora TLS ha continuato ad evolversi ed oggi SSL è deprecato a causa di molteplici difetti di progettazione che sono stati scoperti.

10.2.1.1. Infrastruttura a chiave pubblica: easy-rsa

Si tratta di una «coppia di chiavL'algoritmo RSA è ampiamente utilizzato nella crittografia a chiave pubblica. i», formata da una chiave privata e una chiave pubblica. Le due chiavi sono strettamente legate l'una all'altra, e le loro proprietà matematiche sono tali che un messaggio cifrato con la chiave pubblica può essere decifrato solo da qualcuno a conoscenza della chiave privata, garantendone la riservatezza. Al contrario, un messaggio cifrato con la chiave privata può essere decodificato da chiunque conosca la chiave pubblica, il che permette di autenticare l'origine di un messaggio in quanto solo una persona con accesso alla chiave privata lo avrebbe potuto generare. Quando è associato ad una funzione hash digitale (MD5, SHA1 o una variante più recente), si ottiene un meccanismo di firma che può essere applicato a qualsiasi messaggio.
Tuttavia, chiunque può creare una coppia di chiavi, archiviarvi qualsiasi identità, e fingere di essere l'identità da lui scelta. Una soluzione implica il concetto di Autorità di certificazione (CA: «Certification Authority» ), formalizzato dallo standard X.509. Questo termine si riferisce a un soggetto che detiene una coppia di chiavi fidate conosciuto come certificato principale. Questo certificato viene utilizzato solamente per firmare altri certificati (coppie di chiavi), dopo che sono state adottate misure adeguate per controllare l'identità memorizzata nella coppia di chiavi. Le applicazioni che utilizzano X.509 possono quindi controllare i certificati presentati, se ne conoscono i certificati principali attendibili.
OpenVPN segue questa regola. Dal momento che le CA pubbliche emettono solamente certificati in cambio di un (costoso) pagamento, è possibile creare un'autorità di certificazione privata all'interno dell'azienda. Il pacchetto easy-rsa fornisce gli strumenti che servono come infrastruttura di certificazione X.509, offrendo un insieme di script utilizzando il comando openssl.

NOTA easy-rsa prima di Jessie

Nelle versioni di Debian fino a Wheezy, easy-rsa è stato distribuito come parte del pacchetto openvpn, e gli script potevano esssere trovati in /usr/share/doc/openvpn/examples/easy-rsa/2.0/. L'impostazione di una CA richiede la copia di quella directory, invece di usare il comando make-cadir come documentato qui.
Gli amministratori della Falcot Corp utilizzano questo strumento per creare i certificati richiesti, sia per il server che per i client. Questo permette una configurazione simile di tutti i client, dato che dovranno essere impostati solo per considerare attendibili i certificati provenienti dalla CA locale di Falcot. Questa CA crea il primo certificato; a tal fine, gli amministratori impostano in un luogo appropriato la directory con i file richiesti per la CA, preferibilmente su una macchina non connessa alla rete, per ridurre il rischio di furto della chiave privata della CA. 
$ make-cadir pki-falcot
$ cd pki-falcot
They then store the required parameters into the vars file, which can be uncommented and edited: 
$ vim vars
$ grep EASYRSA vars
export KEY_CONFIG=`$EASY_RSA/whichopensslcnf $EASY_RSA`
export KEY_DIR="$EASY_RSA/keys"
echo NOTE: If you run ./clean-all, I will be doing a rm -rf on $KEY_DIR
export KEY_SIZE=2048
export KEY_EXPIRE=3650
export KEY_COUNTRY="FR"
export KEY_PROVINCE="Loire"
export KEY_CITY="Saint-Étienne"
export KEY_ORG="Falcot Corp"
export KEY_EMAIL="admin@falcot.com"
export KEY_OU="Certificate authority"
export KEY_NAME="Certificate authority for Falcot Corp"
# If you'd like to sign all keys with the same Common Name, uncomment the KEY_CN export below
# export KEY_CN="CommonName"
$
Il passo successivo è la creazione della coppia di chiavi della CA stessa (le due parti della coppia di chiavi vengono memorizzate nei file keys/ca.crt e keys/ca.key durante questa fase):
The next step is the creation of the CA's key pair itself (the two parts of the key pair will be stored under pki/ca.crt and pki/private/ca.key during this step). We can add the option nopass to avoid entering a password each time the private key is used: 
$ ./easyrsa build-ca nopass

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1b  26 Feb 2019
Generating RSA private key, 2048 bit long modulus (2 primes)
......................................................................................+++++
......................+++++
e is 65537 (0x010001)
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Common Name (eg: your user, host, or server name) [Easy-RSA CA]:

CA creation complete and you may now import and sign cert requests.
Your new CA certificate file for publishing is at:
/home/roland/pki-falcot/pki/ca.crt
Il certificato per il server VPN può essere creato, così come i parametri Diffie-Hellman necessari dal lato server per una connessione SSL/TLS. Il server VPN è identificato dal suo nome DNS vpn.falcot.com; questo nome viene riutilizzato per i file chiave generati (keys/vpn.falcot.com.crt per il certificato pubblico, keys/vpn.falcot.com.key per la chiave privata): 
$ ./easyrsa gen-req vpn.falcot.com nopass
Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1b  26 Feb 2019
Generating a RSA private key
.................................................................................+++++
........+++++
writing new private key to '/home/roland/pki-falcot/pki/private/vpn.falcot.com.key.E5c3RGJBUd'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Common Name (eg: your user, host, or server name) [vpn.falcot.com]:

Keypair and certificate request completed. Your files are:
req: /home/roland/pki-falcot/pki/reqs/vpn.falcot.com.req
key: /home/roland/pki-falcot/pki/private/vpn.falcot.com.key

$ ./easyrsa sign-req server vpn.falcot.com

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1b  26 Feb 2019


You are about to sign the following certificate.
Please check over the details shown below for accuracy. Note that this request
has not been cryptographically verified. Please be sure it came from a trusted
source or that you have verified the request checksum with the sender.

Request subject, to be signed as a server certificate for 1080 days:

subject=
    commonName                = vpn.falcot.com


Type the word 'yes' to continue, or any other input to abort.
  Confirm request details: yes
Using configuration from /home/roland/pki-falcot/pki/safessl-easyrsa.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
commonName            :ASN.1 12:'vpn.falcot.com'
Certificate is to be certified until Jun 14 10:44:44 2022 GMT (1080 days)

Write out database with 1 new entries
Data Base Updated

Certificate created at: /home/roland/pki-falcot/pki/issued/vpn.falcot.com.crt

$ ./easyrsa gen-dh

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1b  26 Feb 2019
Generating DH parameters, 2048 bit long safe prime, generator 2
This is going to take a long time
[…]
DH parameters of size 2048 created at /home/roland/pki-falcot/pki/dh.pem
Il passo seguente crea i certificati per i client VPN, è richiesto un certificato per ogni computer o persona autorizzata ad usare la VPN: 
$ ./build-key JoeSmith

Note: using Easy-RSA configuration from: ./vars

Using SSL: openssl OpenSSL 1.1.1b  26 Feb 2019
Generating a RSA private key
....+++++
..............................+++++
writing new private key to '/home/roland/pki-falcot/pki/private/JoeSmith.key.mY21iP8ysv'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Common Name (eg: your user, host, or server name) [JoeSmith]:

Keypair and certificate request completed. Your files are:
req: /home/roland/pki-falcot/pki/reqs/JoeSmith.req
key: /home/roland/pki-falcot/pki/private/JoeSmith.key
Now all certificates have been created, they need to be copied where appropriate: the root certificate's public key (pki/ca.crt) will be stored on all machines (both server and clients) as /etc/ssl/certs/Falcot_CA.crt. The server's certificate is installed only on the server (pki/issued/vpn.falcot.com.crt goes to /etc/ssl/vpn.falcot.com.crt, and pki/private/vpn.falcot.com.key goes to /etc/ssl/private/vpn.falcot.com.key with restricted permissions so that only the administrator can read it), with the corresponding Diffie-Hellman parameters (pki/dh.pem) installed to /etc/openvpn/dh.pem. Client certificates are installed on the corresponding VPN client in a similar fashion.

10.2.1.2. Configurazione del server OpenVPN

By default, the OpenVPN initialization script tries starting all virtual private networks defined in /etc/openvpn/*.conf. Setting up a VPN server is therefore a matter of storing a corresponding configuration file in this directory. A good starting point is /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz, which leads to a rather standard server. Of course, some parameters need to be adapted: ca, cert, key and dh need to describe the selected locations (respectively, /etc/ssl/certs/Falcot_CA.crt, /etc/ssl/vpn.falcot.com.crt, /etc/ssl/private/vpn.falcot.com.key and /etc/openvpn/dh.pem). The server 10.8.0.0 255.255.255.0 directive defines the subnet to be used by the VPN; the server uses the first IP address in that range (10.8.0.1) and the rest of the addresses are allocated to clients.
Con questa configurazione, l'avvio di OpenVPN crea l'interfaccia di rete virtuale solitamente con il nome tun0. Tuttavia, i firewall sono spesso configurati contemporaneamente alle interfacce di rete reali, e questo avviene prima dell'avvio di OpenVPN. Le buone pratiche raccomandano pertanto la creazione di una interfaccia di rete virtuale persistente e di configurare OpenVPN ad utilizzare questa interfaccia preesistente. Questo permette inoltre di scegliere il nome per questa interfaccia. A tal fine, il comando openvpn --mktun --dev vpn --dev-type tun crea una interfaccia di rete virtuale denominata vpn di tipo tun; questo comando può essere facilmente integrato nello script di configurazione del firewall, o in una direttiva up del file /etc/network/interfaces. Il file di configurazione di OpenVPN deve essere aggiornato di conseguenza, con le direttive dev vpn e dev-type tun.
Salvo ulteriori modifiche, i client VPN possono accedere solo al server VPN stesso attraverso l'indirizzo 10.8.0.1. Per fornire ai client l'accesso alla rete locale (192.168.0.0/24) è necessario aggiungere una direttiva push route 192.168.0.0 255.255.255.0 nella configurazione di OpenVPN, in questo modo i client VPN ottengono automaticamente un percorso di rete che gli consente di raggiungere questa rete attraverso la VPN. Inoltre, le macchine sulla rete locale devono anche essere informate che il percorso verso la VPN passa attraverso il server VPN (questo funziona automaticamente quando il server VPN è installato sul gateway). In alternativa, il server VPN può essere configurato per eseguire il mascheramento IP in modo che le connessioni provenienti dai client VPN figurino invece come provenienti dal server VPN (vedere la Sezione 10.1, «Gateway»).

10.2.1.3. Configurazione del client OpenVPN

Anche l'impostazione di un client OpenVPN richiede la creazione di un file di configurazione in /etc/openvpn/. Una configurazione standard può essere ottenuta usando /usr/share/doc/openvpn/examples/sample-config-files/client.conf come punto di partenza. La direttiva remote vpn.falcot.com 1194 indica l'indirizzo e la porta del server OpenVPN. Le direttive ca, cert e key devono essere modificate per indicare le posizioni dei file di chiave.
If the VPN should not be started automatically on boot, set the AUTOSTART directive to none in the /etc/default/openvpn file. Starting or stopping a given VPN connection is always possible with the commands systemctl start openvpn@name and systemctl stop openvpn@name (where the connection name matches the one defined in /etc/openvpn/name.conf).
Il pacchetto network-manager-openvpn-gnome contiene un'estensione per Network Manager (vedere la Sezione 8.2.5, «Automatizzare la configurazione della rete per gli utenti in movimento») che consente la gestione delle reti private virtuali di OpenVPN. Questo permette ad ogni utente di configurare le connessioni OpenVPN graficamente e di controllarle tramite l'icona di gestione della rete.

10.2.2. Rete privata virtuale con SSH

In realtà ci sono due modi per creare una rete privata virtuale con SSH. La versione storica richiede la creazione di uno strato di PPP sul collegamento SSH. Questo metodo è descritto in un documento HOWTO:
→ http://www.tldp.org/HOWTO/ppp-ssh/
Il secondo metodo è più recente, ed è stato introdotto con OpenSSH 4.3. OpenSSH ora può creare interfacce di rete virtuali (tun*) su entrambi i lati di una connessione SSH, e queste interfacce virtuali possono essere configurate esattamente come se fossero interfacce fisiche. Il sistema di tunneling deve essere prima abilitato impostando PermitTunnel a «yes» nel file di configurazione del server SSH (/etc/ssh/sshd_config). Nello stabilire la connessione SSH, la creazione di un tunnel deve essere esplicitamente richiesta con l'opzione -w any:any (any può essere sostituito con il numero desiderato per il dispositivo tun). Questo richiede che l'utente disponga dei privilegi di amministratore su entrambi i lati, così da poter creare il dispositivo di rete (in altre parole, la connessione deve essere stabilita come root).
Entrambi i metodi, permettono di implementare facilmente la creazione di una rete privata virtuale su SSH. Tuttavia, non nella maniera più efficiente: in particolare le VPN che forniscono non sono adatte per elevati livelli di traffico.
La spiegazione è che quando uno stack TCP/IP è incapsulato all'interno di una connessione TCP/IP (per SSH), il protocollo TCP viene utilizzato per due volte: una per la connessione SSH ed una all'interno del tunnel. Questo comporta problemi, soprattutto per il modo in cui TCP si adatta alle condizioni della rete variando i ritardi di timeout. Sul sito riportato di seguito viene descritto il problema in modo più dettagliato:
→ http://sites.inka.de/sites/bigred/devel/tcp-tcp.html
. Le VPN su SSH dovrebbero pertanto essere limitate unicamente a tunnel temporanei senza vincoli di prestazioni.

10.2.3. IPSec

IPsec, pur rappresentando lo standard nelle VPN IP, è molto più difficile da implementare. Il motore di IPsec è integrato nel kernel di Linux; il pacchetto ipsec-tools fornisce i componenti necessari nello spazio utente, gli strumenti di controllo e configurazione. In termini concreti, in ogni host è presente un file /etc/ipsec-tools.conf che contiene i parametri per i tunnel IPsec (o, nella terminologia IPsec, Security Association) che riguardano l'host; lo script /etc/init.d/setkey fornisce un modo per avviare e arrestare un tunnel (ogni tunnel è un collegamento sicuro ad un altro host collegato alla rete privata virtuale). Questo file può essere costruito a mano a partire dalla documentazione fornita dalla pagina di manuale setkey(8). Tuttavia, scrivere esplicitamente i parametri per tutti gli host in un insieme non piccolo di macchine diventa rapidamente un compito arduo, in quanto il numero di tunnel cresce velocemente. L'installazione di un demone IKE (per IPsec Key Exchange) come racoon o strongswan rende il processo molto più semplice rendendo la'mministrazione centralizzata, e più sicura ruotando le chiavi periodicamente.
A dispetto del suo status di riferimento, la complessità della configurazione di IPsec limita il suo utilizzo nella pratica. Soluzioni basate su OpenVPN verranno generalmente preferite quando i tunnel richiesti non sono né troppi né troppo dinamici.

ATTENZIONE IPsec e NAT

I firewall NAT e IPsec non lavorano bene insieme: poiché IPsec firma i pacchetti, qualsiasi cambiamento (eventualmente) fatto dal firewall sui pacchetti renderà la firma non valida e i pacchetti verranno rifiutati a destinazione. Varie implementazioni di IPsec includono ora la tecnica NAT-T (NAT Traversal), che fondamentalmente incapsula il pacchetto IPsec all'interno di un pacchetto UDP standard.

SICUREZZA IPsec e firewall

La modalità standard di IPsec prevede lo scambio di dati sulla porta UDP 500 per gli scambi delle chiavi (anche sulla porta UDP 4500 nel caso NAT-T sia in funzione). Inoltre, i pacchetti IPsec utilizzano due protocolli IP dedicati che il firewall deve lasciare passare; la ricezione di questi pacchetti è basata sul loro numero di protocollo, 50 (ESP) e 51 (AH).

10.2.4. PPTP

PPTP (protocollo di tunneling punto a punto: Point to Point Tunneling Protocol) utilizza due canali di comunicazione, uno per i dati di controllo e uno per i dati di traffico; quest'ultimo utilizza il protocollo GRE (incapsulamento generico di instradamento: Generic Routing Encapsulation). Un collegamento PPP standard viene poi stabilito sopra il canale di scambio dei dati.

10.2.4.1. Configurazione del client

Il pacchetto pptp-linux contiene un client PPTP facilmente configurabile per Linux. Le seguenti istruzioni trovano ispirazione nella documentazione ufficiale:
→ http://pptpclient.sourceforge.net/howto-debian.phtml
Gli amministratori della Falcot hanno creato diversi file: /etc/ppp/options.pptp, /etc/ppp/peers/falcot, /etc/ppp/ip-up.d/falcot e /etc/ppp/ip-down.d/falcot.

Esempio 10.2. Il file /etc/ppp/options.pptp

# Opzioni PPP usate per una connessione PPTP
lock
noauth
nobsdcomp
nodeflate

Esempio 10.3. Il file /etc/ppp/peers/falcot

# vpn.falcot.com e' il server PPTP
pty "pptp vpn.falcot.com --nolaunchpppd"
# la connessione si identifichera' come utente 'vpn'
user vpn
remotename pptp
# e' necessaria la cifratura
require-mppe-128
file /etc/ppp/options.pptp
ipparam falcot

Esempio 10.4. Il file /etc/ppp/ip-up.d/falcot

# Create the route to the Falcot network
if [ "$6" = "falcot" ]; then
  # 192.168.0.0/24 is the (remote) Falcot network
  ip route add 192.168.0.0/24 dev $1
fi

Esempio 10.5. Il file /etc/ppp/ip-down.d/falcot

# Delete the route to the Falcot network
if [ "$6" = "falcot" ]; then
  # 192.168.0.0/24 is the (remote) Falcot network
  ip route del 192.168.0.0/24 dev $1
fi

SICUREZZA MPPE

Mettere in sicurezza PPTP implica l'uso della funzionalità di crittografia MPPE (Microsoft Point to Point Encryption), disponibile come modulo nei kernel Debian ufficiali.

10.2.4.2. Configurazione del server

ATTENZIONE PPTP e firewall

I firewall intermedi devono essere configurati per consentire il passaggio dei pacchetti IP che utilizzano il protocollo 47 (GRE). Inoltre, la porta 1723 del server PPTP deve essere aperta in modo che possa attivarsi il canale di comunicazione.
pptpd è il server PPTP per Linux. Il file di configurazione principale, /etc/pptpd.conf, richiede pochissime modifiche: localip (indirizzo IP locale) e remoteip (indirizzo IP remoto). Nell'esempio riportato di seguito, il server PPTP utilizza sempre l'indirizzo 192.168.0.199 e i client PPTP ricevono gli indirizzi IP da 192.168.0.200 a 192.168.0.250.

Esempio 10.6. Il file /etc/pptpd.conf

# TAG: speed
#
#       Specifies the speed for the PPP daemon to talk at.
#
speed 115200

# TAG: option
#
#       Specifies the location of the PPP options file.
#       By default PPP looks in '/etc/ppp/options'
#
option /etc/ppp/pptpd-options

# TAG: debug
#
#       Turns on (more) debugging to syslog
#
# debug

# TAG: localip
# TAG: remoteip
#
#       Specifies the local and remote IP address ranges.
#
#       You can specify single IP addresses separated by commas or you can
#       specify ranges, or both. For example:
#
#               192.168.0.234,192.168.0.245-249,192.168.0.254
#
#       IMPORTANT RESTRICTIONS:
#
#       1. No spaces are permitted between commas or within addresses.
#
#       2. If you give more IP addresses than MAX_CONNECTIONS, it will
#          start at the beginning of the list and go until it gets
#          MAX_CONNECTIONS IPs. Others will be ignored.
#
#       3. No shortcuts in ranges! ie. 234-8 does not mean 234 to 238,
#          you must type 234-238 if you mean this.
#
#       4. If you give a single localIP, that's ok - all local IPs will
#          be set to the given one. You MUST still give at least one remote
#          IP for each simultaneous client.
#
#localip 192.168.0.234-238,192.168.0.245
#remoteip 192.168.1.234-238,192.168.1.245
#localip 10.0.1.1
#remoteip 10.0.1.2-100
localip 192.168.0.199
remoteip 192.168.0.200-250
La configurazione PPP utilizzata da un server PPTP richiede anche alcuni cambiamenti in /etc/ppp/pptpd-options. I parametri importanti sono il nome del server (pptp), il nome di dominio (falcot.com) e gli indirizzi IP per i server DNS e WINS.

Esempio 10.7. Il file /etc/ppp/pptpd-options

## turn pppd syslog debugging on
#debug

## change 'servername' to whatever you specify as your server name in chap-secrets
name pptp
## change the domainname to your local domain
domain falcot.com

## these are reasonable defaults for WinXXXX clients
## for the security related settings
# The Debian pppd package now supports both MSCHAP and MPPE, so enable them
# here. Please note that the kernel support for MPPE must also be present!
auth
require-chap
require-mschap
require-mschap-v2
require-mppe-128

## Fill in your addresses
ms-dns 192.168.0.1
ms-wins 192.168.0.1

## Fill in your netmask
netmask 255.255.255.0

## some defaults
nodefaultroute
proxyarp
lock
L'ultimo passaggio prevede la registrazione dell'utente vpn (e la sua password associata) nel file /etc/ppp/chap-secrets. Contrariamente alle altre istanze dove un asterisco (*) potrebbe funzionare, il nome del server deve essere inserito qui in modo esplicito. Inoltre, i client Windows PPTP si identificano con la forma DOMINIO\\UTENTE, anziché fornire il solo nome utente. Questo spiega perché il file cita anche l'utente FALCOT\vpn. È anche possibile specificare i singoli indirizzi IP per gli utenti; un asterisco in questo campo specifica che devono essere utilizzati gli indirizzi dinamici.

Esempio 10.8. Il file /etc/ppp/chap-secrets

# Secrets for authentication using CHAP
# client        server  secret      IP addresses
vpn             pptp    f@Lc3au     *
FALCOT\\vpn     pptp    f@Lc3au     *

SICUREZZA Vulnerabilità in PPTP

La prima implementazione PPTP di Microsoft ha attirato pesanti critiche perché aveva molte vulnerabilità di sicurezza; da allora, la maggior parte sono state risolte nelle versioni più recenti. La configurazione documentata in questa sezione utilizza l'ultima versione del protocollo. Bisogna essere consapevoli però che rimuovere alcune opzioni (ad esempio require-mppe-128 e require-mschap-v2) renderebbe il servizio nuovamente vulnerabile.