Product SiteDocumentation Site

10.3. 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.
Several tools provide this functionality. OpenVPN is an efficient solution, easy to deploy and maintain, based on SSL/TLS. Another possibility is using IPsec to encrypt IP traffic between two machines; this encryption is transparent, which means that applications running on these hosts need not be modified to take the VPN into account. SSH can also be used to provide a VPN, in addition to its more conventional features. Finally, a VPN can be established using Microsoft's PPTP protocol. Other solutions exist, but are beyond the focus of this book.

10.3.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.3.1.1. Konfigurieren des OpenVPN-Servers

After all certificates have been created (follow the instructions from Abschnitt 10.2.2, „Public-Key-Infrastrultur: easy-rsa“), 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/certs/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.3.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.
With this configuration, starting OpenVPN creates the virtual network interface, usually under the tun0 name. However, firewalls are often configured at the same time as the real network interfaces, which happens before OpenVPN starts. Good practice therefore recommends creating a persistent virtual network interface, and configuring OpenVPN to use this pre-existing interface. This further allows choosing the name for this interface. To this end, openvpn --mktun --dev vpn --dev-type tun creates a virtual network interface named vpn with type tun; this command can easily be integrated in the firewall configuration script, or in an up directive of the /etc/network/interfaces file, or a udev rule can be added to that end. The OpenVPN configuration file must also be updated accordingly, with the dev vpn and dev-type tun directives.
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.3.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.3.2. Virtual Private Network mit SSH

There are actually two ways of creating a virtual private network with SSH. The historic one involves establishing a PPP layer over the SSH link. This method is described in a HOWTO document:
→ https://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.
The explanation is that when a TCP/IP stack is encapsulated within a TCP/IP connection (for SSH), the TCP protocol is used twice, once for the SSH connection and once within the tunnel. This leads to problems, especially due to the way TCP adapts to network conditions by altering timeout delays. The following site describes the problem in more detail:
→ http://sites.inka.de/sites/bigred/devel/tcp-tcp.html
VPNs over SSH should therefore be restricted to one-off tunnels with no performance constraints.

10.3.3. IPsec

IPsec, despite being the standard in IP VPNs, is rather more involved in its implementation. The IPsec engine itself is integrated in the Linux kernel; the required user-space parts, the control and configuration tools, are provided by the libreswan package or the strongswan package. Here we describe briefly the libreswan option.
First, we install the libreswan package. In concrete terms, each host's /etc/ipsec.conf contains the parameters for IPsec tunnels (or Security Associations, in the IPsec terminology) that the host is concerned with. There are many configuration examples in /usr/share/doc/libreswan/, but Libreswan's online documentation has more examples with explanations:
→ https://libreswan.org/wiki/
The IPsec service can be controlled with systemctl; for example, systemctl start ipsec will start the IPsec service.
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.

VORSICHT IPsec und NAT

Firewalls mit NAT und IPsec funktionieren nicht gut zusammen: Da IPsec die Pakete signiert, macht jede Veränderung dieser Pakete, die die Firewall möglicherweise vornimmt, die Signatur ungültig, und die Pakete werden an ihrem Ziel zurückgewiesen. Mehrere IPsec-Anwendungen enthalten inzwischen die NAT-T-Technik (für NAT Traversal), die im Prinzip das IPsec-Paket in einem normalen UDP-Pakets einkapselt.

SICHERHEIT IPsec und Firewalls

In IPsec ist der Datenaustausch über den UDP-Port 500 für den Austausch von Schlüsseln voreingestellt (auch auf UDP-Port 4500, falls NAT-T benutzt wird). Darüberhinaus benutzen IPsec-Pakete zwei fest zugeordnete IP-Protokolle, die die Firewall durchlassen muss; der Empfang dieser Pakete basiert auf ihren Protokollnummern 50 (ESP) und 51 (AH).

10.3.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.3.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

SICHERHEIT MPPE

PPTP wird mit der MPPE-Funktion abgesichert (Microsoft Point-to-Point Encryption), die in den offiziellen Debian-Kerneln als Modul vorhanden ist.

10.3.4.2. Den Server konfigurieren

VORSICHT PPTP und Firewalls

Zwischenliegende Firewalls müssen so konfiguriert sein, dass sie IP-Pakete durchlassen, die das Protokoll 47 (GRE) verwenden. Außerdem muss der Port 1723 des PPTP-Servers geöffnet sein, damit der Kommunikationskanal aufgebaut werden kann.
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     *

SICHERHEIT PPTP-Schwachstellen

Microsofts erste PPTP-Anwendung zog wegen der vielen Sicherheitslücken heftige Kritik auf sich; die meisten sind in neueren Versionen behoben worden. Die in diesem Abschnitte beschriebene Konfiguration verwendet die jüngste Version des Protokolls. Seien Sie sich jedoch bewusst, dass das Entfernen einiger Optionen (wie require-mppe-128 und require-mschap-v2) den Dienst wieder angreifbar machen würde.