10.2. Virtual Private Network

Ein Virtual Private Network (kurz VPN genannt) ermoeglicht zwei verschiedene lokale Netze über das Internet mittels eines Tunnels zu verbinde. Zur Wahrung der Vertraulichkeit ist der Tunnel ist normalerweise verschlüsselt. VPNs werden häufig dazu benutzt, einen entfernten Rechner in ein lokales Firmennetz zu integrieren.

Etliche Hilfsprogramme bieten dies an. OpenVPN ist eine auf SSL/TLS basierende effiziente Lösung, die einfach eingesetzt und verwaltet werden kann. Eine andere Möglichkeit, um den IP-Verkehr zwischen zwei Rechnern zu verschlüsseln, ist IPsec; diese Verschlüsselung erfolgt transparent; das heißt, dass Anwendungen das VPN nutzen koennen, ohne dass sie angepasst werden muessten. Auch SSH kann ein VPN bereitstellen, ebenso Microsofts PPTP-Protokoll. Es gibt noch weitere Lösungen, die aber außerhalb des Schwerpunktes dieses Buches liegen.

10.2.1. OpenVPN

OpenVPN ist eine Software zum Anlegen virtueller privater Netze. Um es einzurichten, legen Sie virtuelle Netzwerkschnittstellen auf dem VPN-Server und den Clients an. tun (für Tunnel auf IP-Ebene) und tap (für Tunnel auf Ethernet-Ebene) werden unterstützt. In der Praxis werden meistens tun-Schnittstellen verwendet, außer wenn die VPN-Clients durch eine Ethernet-Brücke in das lokale Netz des Servers integriert werden sollen.

OpenVPN nutzt OpenSSL für die gesamte SSL/TLS-Kryptographie und die damit zusammenhängenden Leistungsmerkmale (Vertraulichkeit, Authentifizierung, Integrität, Nichtabstreitbarkeit). Es kann entweder mit einem geteilten privaten Schlüssel oder mithilfe eines (auf Public-Key-Verschluesselung basierenden) X.509-Zertifikats benutzt werden. Die zweite Konfiguration ist eindeutig vorzuziehen, da sie angesichts einer wachsenden Zahl wechselnder Benutzer des VPN größere Flexibilität ermöglicht.

10.2.1.1. Public-Key-Infrastrultur: easy-rsa

Der RSA-Algorithmus ist in der Public-Key-Kryptographie weit verbreitet. Er umfasst ein "Schlüsselpaar", das aus einem privaten und einem öffentlichen Schlüssel bezieht. Die beiden Schlüssel sind durch ihre mathematischen Eigenschaften derart miteinander verbunden, dass folgende Operation moeglich ist: Eine Nachricht, die mit dem öffentlichen Schlüssel verschlüsselt wurde, kann nur von jemandem entschlüsselt werden, der den privaten Schlüssel kennt. Dies stellt Vertraulichkeit her. In umgekehrter Richtung kann eine mit dem privaten Schlüssel verschlüsselte Nachricht, von jedem entschlüsselt werden, der den öffentlichen Schlüssel kennt. Dies authentifiziert die Nachricht, da sie nur der Inhaber des privaten Schlüssels erstellt haben kann. Dies führt in Verbindung mit einer digitalen Hash-Funktion (MD5, SHA1 oder einer neueren Variante) zu einem Signaturverfahren, das auf jede Nachricht angewendet werden kann.

Jedoch kann jeder ein Schlüsselpaar erstellen, eine beliebige Identität in ihm ablegen und so eine andere Identität vortäuschen. Ein Lösungskonzept beruht auf einer Certification Authority (CA, Zertifizierungsstelle), das durch den Standard X.509 formalisiert ist. Dieser Begriff bezeichnet eine Organisation, die ein vertrauenswürdiges Schlüsselpaar bereithält, das als Stammzertifikat bezeichnet wird. Dieses Zertifikat wird nur dazu benutzt, andere Zertifikate (Schlüsselpaare) zu signieren, nachdem die erforderlichen Schritte zur Überprüfung der Identität, die auf ihm abgelegt ist, unternommen worden sind. X.509-Anwendungen können dann vorgelegte Zertifikate überprüfen, wenn sie die vertrauenswürdigen Stammzertifikate kennen.

OpenVPN folgt dieser Regel. Da öffentliche Zertifizierungstellen Zertifikate nur gegen eine (hohe) Gebühr ausstellen, können private Zertifizierungsstellen auch innerhalb eines Unternehmens eingerichtet werden. Das 1easy-rsa Paket enthält Tools, die eine X.509 Zertifizierungs-Infrastruktur bereitstellen. Es besteht aus einem Satz von Skripten, die den Befehl openssl verwenden.

Die Administratoren der Falcot Corp. verwenden dieses Hilfsprogramm, um die erforderlichen Zertifikate sowohl für den Server, als auch die Clients zu erstellen. Dies ermöglicht eine ähnliche Konfiguration aller Clients, da sie nur so eingerichtet werden müssen, dass sie Zertifikaten von Falcots lokaler Zertifizierungsstelle vertrauen. Für diese Stelle wird das erste Zertifikat erstellt. Hierzu erstellen Administratoren das Verzeichnis mit den benötigten Dateien für die CA an einen passenderen Ort; vorzugsweise auf einen nicht mit dem Netzwerk verbundenen Rechner um so das Risiko des Schlüsseldiebstahls zu verringern.

$ 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"
$

Im nächsten Schritt wird das Schlüsselpaar der Zertifizierungsstelle erzeugt (die beiden Teile des Schlüsselpaars werden im Verlauf dieses Schritts unter keys/ca.crt und keys/ca.key gespeichert:

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

Jetzt kann das Zertifikat für den VPN-Server erstellt werden, wie auch die Diffie-Hellmann-Parameter, die für die Serverseite einer SSL/TLS-Verbindung benötigt werden. Der VPN-Server ist mit seinem DNS-Namen vpn.falcot.com gekennzeichnet; dieser Name wird für die erzeugten Schlüsseldateien wiederverwendet (keys/vpn.falcot.com.crt für das öffentliche Zertifikat, keys/vpn.falcot.com.key für den privaten Schlüssel):

$ ./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

Der folgende Schritt erstellt Zertifikate für die VPN-Clients; für jeden Rechner oder jede Person, der das VPN nutzen darf, ist ein eigenes Zertifikat erforderlich:

$ ./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. Konfigurieren des OpenVPN-Servers

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.

Wenn OpenVPN mit dieser Konfiguration gestartet wird, wird die Schnittstelle des virtuellen Netzwerks erstellt, gewöhnlich unter dem Namen tun0. Jedoch werden Firewalls häufig zur gleichen Zeit wie die echten Netzwerkschnittstellen konfiguriert, also vor dem Start von OpenVPN. Ein bewährtes Verfahren besteht deshalb darin, eine dauerhafte Schnittstelle für das virtuelle Netzwerk einzurichten und OpenVPN so zu konfigurieren, dass es dann diese bereits bestehende Schnittstelle benutzt. Dies macht es auch möglich, einen Namen für diese Schnittstelle auszuwählen. Zu diesem Zweck erstellt der Befehl openvpn --mktun --dev vpn --dev-type tun eine Schnittstelle des virtuellen Netzwerks namens vpn und des Typs tun; dieser Befehl kann leicht in das Konfigurationsskript der Firewall integriert werden oder in eine up-Anweisung der Datei /etc/network/interfaces. Die OpenVPN-Konfigurationsdatei muss ebenfalls in entsprechender Weise mit den Anweisungen dev vpn und dev-type tun aktualisiert werden.

Ohne weitere Maßnahmen können VPN-Clients nur den Server selbst über die Adresse 10.8.0.1 erreichen. Um den Clients Zugang zum lokalen Netzwerk (192.168.0.0/24) zu gewähren, muss die Anweisung push route 192.168.0.0 255.255.255.0 zur OpenVPN-Konfiguration hinzugefügt werden, so dass VPN-Clients automatisch eine Netzwerkroute erhalten, die ihnen sagt, dass dieses Netzwerk über das VPN zu erreichen ist. Darüberhinaus müssen Rechner im lokalen Netzwerk ebenfalls darüber informiert werden, dass der Weg zum VPN über den VPN-Server verläuft (dies funktioniert automatisch, wenn der VPN-Server auf dem Gateway installiert ist). Alternativ kann der VPN-Server auch IP-Masquerading unterstützen, so dass von den VPN-Clients kommende Verbindungen so aussehen, als kämen sie stattdessen vom VPN-Server (siehe Abschnitt 10.1, „Gateway“).

10.2.1.3. Konfigurieren des OpenVPN-Clients

Das Einrichten eines OpenVPN-Clients erfordert auch das Erstellen einer Konfigurationsdatei in /etc/openvpn/. Eine Standard-Konfiguration findet sich in der Datei /usr/share/doc/openvpn/examples/sample-config-files/client.conf. Die Anweisung remote vpn.falcot.com 1194 bezeichnet die Adresse und den Port des OpenVPN-Servers; ca, cert und key müssen auch angepasst werden, so dass sie die Orte der Schlüsseldateien bezeichnen.

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).

Das Paket network-manager-openvpn-gnome enthält eine Erweiterung für Network Manager (siehe Abschnitt 8.2.5, „Automatische Netzwerkkonfigurierung für mobile Benutzer“), die es ermöglicht, OpenVPN-Netzwerke zu verwalten. Damit kann jeder Benutzer OpenVPN-Verbindungen grafisch konfigurieren und sie über das Netzwerkverwaltungs-Symbol kontrollieren.

10.2.2. Virtual Private Network mit SSH

Es gibt eigentlich zwei Wege, um ein virtuelles privates Netzwerk mit SSH einzurichten. Der historische erfordert eine PPP-Schicht über die SSH-Verbindung. Diese Methode wird in einem HOWTO-Dokument beschrieben:

→ http://www.tldp.org/HOWTO/ppp-ssh/

Die zweite Methode ist neueren Datums und wurde mit OpenSSH 4.3 eingeführt; OpenSSH kann jetzt Schnittstellen des virtuellen Netzwerks (tun*) auf beiden Seiten einer SSH-Verbindung erstellen, und diese virtuellen Schnittstellen können genauso konfiguriert werden, als seien es reale Schnittstellen. Das Tunnelungssystem muss zuvor aktiviert werden, indem PermitTunnel in der Konfigurationsdatei des SSH-Servers (/etc/ssh/sshd_config) auf "yes" gesetzt wird. Bei der Einrichtung der SSH-Verbindung muss die Erstellung eines Tunnels ausdrücklich mit der Option -w any:any verlangt werden (any kann durch die gewünschte tun-Gerätenummer ersetzt werden). DEr Benutzer benötigt Administratorrechte auf beiden Seiten, um das Netzwerkgerät erstellen zu können (mit anderen Worten: die Verbindung muss als Root eingerichtet werden).

Beide Methoden zur Erstellung eines virtuellen privaten Netzwerks über SSH sind recht einfach. Jedoch ist das VPN, das sie bereitstellen, nicht das effizienteste; insbesondere kann es nicht gut mit hohem Datenaufkommen umgehen.

Die Erklärung ist die zweifache Anwendung des TCP-Protokolls, wenn ein TCP/IP-Stack in einer TCP/IP-Verbindung (für SSH) eingekapselt ist; einmal für die SSH-Verbindung und einmal innerhalb des Tunnels. Dies führt zu Problemen, insbesondere wegen der Zeitüberschreitungsverzögerungen durch die sich TCP an Netzwerkbedingungen anpasst. Die folgende Seite beschreibt das Problem genauer:

→ http://sites.inka.de/sites/bigred/devel/tcp-tcp.html

VPNs über SSH sollten daher auf einmalige Tunnel ohne besondere Leistungsanforderungen beschränkt bleiben.

10.2.3. IPsec

Obwohl IPsec der Standard in IP-VPNs ist, ist es stärker an seiner Umsetzung beteiligt. Die IPsec-Engine ist im Linux-Kernel integriert; die erforderlichen Teile im User-Space sowie die Steuerungs- und Konfigurierungsprogramme werden vom Paket ipsec-tools bereitgestellt. Konkret enthält die Datei /etc/ipsec-tools.conf jedes Rechners die Parameter für die IPsec-Tunnel (oder in der IPsec-Terminologie: Security Associations), mit denen der Rechner zu tun hat; das Skript /etc/init.d/setkey bietet die Möglichkeit, einen Tunnel zu eröffnen oder zu schließen (jeder Tunnel ist eine sichere Verbindung zu einem anderen mit dem virtuellen privaten Netzwerk verbundenen Rechner). Diese Datei kann von Hand mithilfe der Dokumentation auf der Handbuchseite setkey(8) erstellt werden. Es wird jedoch schnell zu einer mühseligen Arbeit, die Parameter aller Rechner in einem nicht alltäglichen Satz von Geräten ausführlich niederzuschreiben, da die Anzahl der Tunnel schnell ansteigt. Die Installation eines IKE-Daemons (für IPsec Key Exchange), wie racoon oder strongswan vereinfacht den Vorgang wesentlich durch das Bündeln der Verwaltung an einem zentralen Punkt und sicherer durch das regelmäßige Rotieren der Schlüssel.

Trotz seines Status als Referenz, schränkt die Komplexität der Einrichtung von IPsec seine Verwendung in der Praxis ein. Lösungen auf der Basis von OpenVPN werden im allgemeinen bevorzugt, solange die erforderlichen Tunnel weder zu zahlreich noch zu dynamisch sind.

10.2.4. PPTP

PPTP (für Point-to-Point Tunneling Protocol) verwendet zwei Kommunikationskanäle, einen für die Kontrolldaten und einen für die Nutzdaten; letzterer verwendet das GRE-Protokoll (Generic Routing Encapsulation). Über den Datenaustauschkanal wird dann eine Standard-PPP-Verbindung eingerichtet.

10.2.4.1. Den Client konfigurieren

Das Paket pptp-linux enthält einen leicht zu konfigurierenden PPTP-Client für Linux. Die folgenden Anweisungen sind durch die offizielle Dokumentation angeregt:

→ http://pptpclient.sourceforge.net/howto-debian.phtml

Die Falcot-Administratoren haben mehrere Dateien erstellt: /etc/ppp/options.pptp, /etc/ppp/peers/falcot, /etc/ppp/ip-up.d/falcot und /etc/ppp/ip-down.d/falcot.

Beispiel 10.2. Die Datei /etc/ppp/options.pptp

# PPP options fuer eine PPTP connection
lock
noauth
nobsdcomp
nodeflate

Beispiel 10.3. Die Datei /etc/ppp/peers/falcot

# vpn.falcot.com ist der PPTP server
pty "pptp vpn.falcot.com --nolaunchpppd"
# die Verbindung wird dem "vpn" Benutzer zugerechnet
user vpn
remotename pptp
#  Verschluesselung wird benuetigt
require-mppe-128
file /etc/ppp/options.pptp
ipparam falcot

Beispiel 10.4. Die Datei /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

Beispiel 10.5. Die Datei /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

10.2.4.2. Den Server konfigurieren

pptpd ist der PPTP-Server für Linux. Dessen Hauptkonfiguratiosdatei, /etc/pptpd.conf, erfordert nur sehr wenige Änderungen: localip (die lokale IP-Adresse) und remoteip (die entfernte IP-Adresse). Im folgenden Beispiel benutzt der PPTP-Server stets die Adresse 192.168.0.199, und PPTP-Clients erhalten Adressen von 192.168.0.200 bis 192.168.0.250.

Beispiel 10.6. Die Datei /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

Die PPP-Konfiguration des PPTP-Servers erfordert auch einige Änderungen in /etc/ppp/pptpd-options. Die wichtigen Parameter sind der Servername (pptp), der Domainname (falcot.com) und die IP-Adressen für DNS- und WINS-Server.

Beispiel 10.7. Die Datei /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

Im letzten Schritt wird der vpn-Benutzer (und das dazugehörige Passwort) in der Datei /etc/ppp/chap-secrets registriert. Hier muss statt des Sterns (*) der Servername ausdrücklich angegeben werden. Außerdem identifizieren sich Windows-PPTP-Clients in der Form DOMAIN\\BENUTZER statt nur einen Benutzernamen anzugeben. Dies erklärt, warum die Datei auch den Benutzer FALCOT\\vpn erwähnt. Es ist auch möglich, individuelle IP-Adressen für Benutzer anzugeben; ein Stern in diesem Feld bedeutet, dass dynamisch adressiert werden soll.

Beispiel 10.8. Die Datei /etc/ppp/chap-secrets

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