14.10. VPNs mit IPsec

ping 192.168.2.34

14.10.3.1. Schritt 1: Die virtuelle Verbindung einrichten

Nehmen wir an, sie wollten von der Gateway-Maschine im Netzwerk #1 (öffentliche IP-Adresse A.B.C.D, private IP-Adresse 192.168.1.1) das Kommando ping 192.168.2.1 absetzen. 192.168.2.1 ist die private IP-Adresse des Systems W.X.Y.Z im Netzwerk #2. Welche Voraussetzungen müssen erfüllt sein, damit der Befehl funktioniert?

1. Die Gateway-Maschine muss das System 192.168.2.1 erreichen können. Das heißt, eine Route zu diesem System muss existieren.

2. Private IP-Adressen, wie der Bereich 192.168.x, sollten im Internet nicht verwendet werden. Jedes Paket zu 192.168.2.1 muss daher in ein anderes Paket gepackt werden, das von A.B.C.D kommt und zu W.X.Y.Z geschickt wird. Das erneute Verpacken der Pakete wird als Kapselung bezeichnet.

3. Wenn das Paket W.X.Y.Z erreicht, muss es dort ausgepackt und an 192.168.2.1 ausgeliefert werden.

Sie können sich diese Prozedur so vorstellen, dass ein Tunnel zwischen beiden Netzwerken existiert. Die beiden Tunnel-Enden besitzen die IP-Adressen A.B.C.D und W.X.Y.Z. Der Tunnel muss zudem Verkehr zwischen den privaten IP-Adressen erlauben und transportiert so Daten zwischen privaten IP-Adressen über das Internet.

Unter FreeBSD wird der Tunnel mit gif-Geräten (generic interface) erstellt. Auf jedem Gateway muss das gif-Gerät mit vier IP-Adressen eingerichtet werden: Zwei öffentliche IP-Adressen und zwei private IP-Adressen.

Die gif-Geräte werden vom Kernel bereitgestellt und müssen in der Kernelkonfigurationsdatei auf beiden Maschinen angegeben werden:

pseudo-device gif

Wie gewöhnlich müssen Sie danach einen neuen Kernel erstellen, installieren und das System neu starten.

Der Tunnel wird in zwei Schritten aufgebaut. Mit gifconfig(8) werden zuerst die öffentlichen IP-Adressen konfiguriert. Anschließend werden die privaten IP-Adressen mit ifconfig(8) eingerichtet.

Auf der Gateway-Maschine im Netzwerk #1 bauen Sie den Tunnel mit den folgenden Kommandos auf:

gifconfig gif0 A.B.C.D W.X.Y.Z
ifconfig gif0 inet 192.168.1.1 192.168.2.1 netmask 0xffffffff

Auf dem anderen Gateway benutzen Sie dieselben Kommandos, allerdings mit vertauschten IP-Adressen:

gifconfig gif0 W.X.Y.Z A.B.C.D
ifconfig gif0 inet 192.168.2.1 192.168.1.1 netmask 0xffffffff

Die Konfiguration können Sie anschließend mit dem folgenden Kommando überprüfen:

gifconfig gif0

Auf dem Gateway in Netzwerk #1 sollten Sie beispielsweise die nachstehende Ausgabe erhalten:

# gifconfig gif0
gif0: flags=8011<UP,POINTTOPOINT,MULTICAST> mtu 1280
inet 192.168.1.1 --> 192.168.2.1 netmask 0xffffffff
physical address inet A.B.C.D --> W.X.Y.Z

Wie Sie sehen, ist ein Tunnel zwischen den IP-Adressen A.B.C.D und W.X.Y.Z aufgebaut worden, der Verkehr zwischen den Adressen 192.168.1.1 und 192.168.2.1 zulässt.

Gleichzeitig wurde ein Eintrag in der Routing-Tabelle erstellt, den Sie sich mit netstat -rn ansehen können. Auf der Gateway-Maschine in Netzwerk #1 sieht das so aus:

# netstat -rn
Routing tables

Internet:
Destination      Gateway       Flags    Refs    Use    Netif  Expire
...
192.168.2.1      192.168.1.1   UH        0        0    gif0
...

Die Route ist eine Host-Route, wie in der Spalte “Flags” angegeben. Das heißt die beiden Gateways wissen wie sie einander erreichen, sie kennen allerdings nicht das Netzwerk auf der anderen Seite. Dieses Problem werden wir gleich angehen.

Wahrscheinlich ist auf beiden Gateways eine Firewall eingerichtet. Für den VPN-Verkehr muss die Firewall umgegangen werden. Sie können generell den Verkehr zwischen beiden Netzwerken erlauben oder Regeln erstellen, die beide Tunnel-Enden des VPNs voreinander schützen.

Der Test des VPNs wird erheblich leichter, wenn Sie jeden Verkehr zwischen den Tunnel-Enden in der Firewall erlauben. Wenn Sie auf der Gateway-Maschine ipfw(8) einsetzen, erlaubt die folgende Regel jeden Verkehr zwischen den Tunnel-Enden, ohne die anderen Regeln zu beeinflussen:

ipfw add 1 allow ip from any to any via gif0

Diese Regel muss offensichtlich auf beiden Gateway-Maschinen existieren.

Damit sollten Sie das Kommando ping jetzt absetzen können. Auf dem System 192.168.1.1 sollte der nachstehende Befehl Antworten erhalten:

ping 192.168.2.1

Denselben Test können Sie auch auf der anderen Gateway-Maschine ausführen.

Allerdings können Sie noch nicht die anderen internen Maschinen auf den Netzwerken erreichen. Die Ursache ist das Routing - die Gateway kennen sich zwar gegenseitig, wissen aber noch nichts von den Netzwerken hinter dem anderen Gateway.

Um die Netzwerke bekannt zu geben, muss auf jeder Gateway-Maschine noch eine statische Route hinzugefügt werden. Auf der ersten Gateway-Maschine setzen Sie dazu das folgende Kommando ab:

route add 192.168.2.0 192.168.2.1 netmask 0xffffff00

Dies entspricht der Anweisung: “Um Rechner auf dem Netz 192.168.2.0 zu erreichen, schicke die Pakete zum System 192.168.2.1”. Auf dem anderen Gateway muss das analoge Kommando (mit den IP-Adressen 192.168.1.x) abgesetzt werden.

Damit ist jetzt der IP-Verkehr zwischen beiden Netzwerken möglich.

Zwei Drittel des VPNs zwischen beiden Netzen ist nun eingerichtet. Es ist “virtuell” und es ist ein “Netzwerk”. Es ist allerdings noch nicht “privat”. Dies können Sie mit ping(8) und tcpdump(1) überprüfen. Setzen Sie auf dem ersten Gateway den folgenden Befehl ab:

tcpdump dst host 192.168.2.1

Starten Sie dann, ebenfalls auf dem ersten Gateway, den folgenden Befehl:

ping 192.168.2.1

Sie werden die nachstehende Ausgabe erhalten:

16:10:24.018080 192.168.1.1 > 192.168.2.1: icmp: echo request
16:10:24.018109 192.168.1.1 > 192.168.2.1: icmp: echo reply
16:10:25.018814 192.168.1.1 > 192.168.2.1: icmp: echo request
16:10:25.018847 192.168.1.1 > 192.168.2.1: icmp: echo reply
16:10:26.028896 192.168.1.1 > 192.168.2.1: icmp: echo request
16:10:26.029112 192.168.1.1 > 192.168.2.1: icmp: echo reply

Die ICMP-Nachrichten werden unverschlüsselt übertragen. Mit der Option -s von tcpdump(1) können Sie sich weitere Daten der Pakete anzeigen lassen.

Die Daten sollen aber automatisch verschlüsselt werden. Wie das geht, wird im nächsten Abschnitt erläutert.

Zusammenfassung

• Richten sie in beiden Kerneln das gif-Gerät ein.

• Fügen Sie auf dem Gateway in Netzwerk #1 folgende Zeilen in /etc/rc.conf ein:

  gifconfig_gif0="A.B.C.D W.X.Y.Z"
  ifconfig_gif0="inet 192.168.1.1 192.168.2.1 netmask 0xffffffff"
  static_routes="vpn"
  route_vpn="192.168.2.0 192.168.2.1 netmask 0xffffff00"
  

  Setzen Sie dabei die richtigen IP-Adressen für die Platzhalter ein.

• Fügen Sie auf beiden Gateways die nachstehende Regel in das Firewall-Skript (zum Beispiel /etc/rc.firewall) ein:

  ipfw add 1 allow ip from any to any via gif0
  

• Nehmen Sie in /etc/rc.conf auf dem Gateway #2 analoge Änderungen, die IP-Adressen müssen vertauscht werden, vor.

14.10.3.2. Schritt 2: Die Verbindung mit IPsec schützen

Um die Verbindung zu schützen, verwenden wir IPsec. IPsec bietet einen Mechanismus, mit dem sich zwei Systeme auf einen Schlüssel einigen können. Mit diesem Schlüssel wird dann der Datenverkehr zwischen beiden Systemen verschlüsselt.

Es gibt hierbei zwei Sachen die konfiguriert werden müssen:

1. Die Security-Association bestimmt, mit welchen Methoden der Verkehr zwischen beiden Systemen verschlüsselt wird.

2. Die Security-Policy bestimmt, was verschlüsselt wird. Es soll ja nicht der gesamte Datenverkehr nach außen verschlüsselt werden, sondern nur der Teil des Verkehrs, der zum VPN gehört.

Die Security-Association wie auch die Security-Policy werden vom Kernel verwaltet und können von Anwendungen verändert werden. Dazu müssen allerdings zuerst IPsec und das Encapsulated-Security-Payload (ESP) Protokoll in die Kernelkonfigurationsdatei eingetragen werden:

options IPSEC
options IPSEC_ESP

Wie üblich, müssen Sie danach den Kernel übersetzen, installieren und das System neu starten. Die Kernel müssen auf beiden Gateway-Maschinen neu erstellt werden.

Sie können die Security-Association auf zwei Arten konfigurieren: Manuell, dann müssen Sie den Verschlüsselungsalgorithmus, die Schlüssel und alles Weitere selbst konfigurieren. Oder automatisch, mithilfe eines Dæmons, der das Internet-Key-Exchange Protokoll (IKE) beherrscht.

Im Allgemeinen wird die letzte Variante bevorzugt. Sie ist auch wesentlich leichter einzurichten.

Mit setkey(8) können Sie Security-Policies editieren und anzeigen. Die Beziehung von setkey und der Tabelle der Security-Policies im Kernel entspricht dem Verhältnis von route(8) und der Routing-Tabelle. Die momentanen Security-Associations lassen sich ebenfalls mit setkey anzeigen; setkey verhält sich in diesem Fall wie netstat -r, um die Analogie fortzuführen.

Sie haben die Wahl zwischen mehreren Programmen, wenn Sie Security-Associations mit FreeBSD verwalten wollen. Im Folgenden wird racoon beschrieben. racoon lässt sich in gewohnter Weise aus der Ports-Collection installieren. Sie finden das Programm unter security/racoon.

Auf beiden Gateway-Maschinen muss racoon laufen. Auf jedem System wird es mit der IP-Adresse der Gegenstelle und einem geheimen Schlüssel konfiguriert. Auf beiden Gateway-Maschinen muss der gleiche Schlüssel verwendet werden.

Die beiden raccon-Daemonen prüfen mithilfe des geheimen Schlüssels gegenseitig ihre Identität. Anschließend generieren Sie einen neuen geheimen Schlüssel, mit dem dann der Datenverkehr im VPN verschlüsselt wird. Dieser Schlüssel wird von Zeit zu Zeit geändert. Ein Angreifer, der einen der Schlüssel geknackt hat - das ist schon ziemlich unwahrscheinlich - kann somit nicht viel mit diesem Schlüssel anfangen, da schon wieder ein anderer Schlüssel verwendet wird.

Die Konfiguration von racoon befindet sich in ${PREFIX}/etc/racoon. In der dort befindlichen Konfigurationsdatei sollten Sie nicht allzu viele Änderungen vornehmen müssen. Sie müssen allerdings den so genannten “Pre-Shared-Key” (den vorher ausgetauschten Schlüssel) ändern.

In der Voreinstellung befindet sich dieser Schlüssel in der Datei ${PREFIX}/etc/racoon/psk.txt. Dieser Schlüssel wird nicht zum Verschlüsseln des Datenverkehrs verwendet. Er dient lediglich der Authentifizierung der beiden racoon-Daemonen.

Für jeden entfernten Kommunikationspartner enthält psk.txt eine Zeile. Damit besteht die Datei psk.txt in unserem Beispiel aus einer Zeile (wir verwenden einen entfernten Kommunikationspartner).

Auf dem Gateway #1 sieht diese Zeile wie folgt aus:

W.X.Y.Z            geheim

Die Zeile besteht aus der öffentlichen IP-Adresse der Gegenstelle, Leerzeichen und dem geheimen Schlüssel. Sie sollten natürlich nicht geheim verwenden. Für den geheimen Schlüssel gelten dieselben Regeln wie für Passwörter.

Auf dem anderen Gateway sieht die Zeile folgendermaßen aus:

A.B.C.D            geheim

Die Zeile besteht aus der öffentlichen IP-Adresse der Gegenstelle, Leerzeichen und dem geheimen Schlüssel. Die Zugriffsrechte von psk.txt müssen auf 0600 (Lese- und Schreibzugriff nur für root) gesetzt sein, bevor racoon gestartet wird.

Auf beiden Gateway-Maschinen muss racoon laufen. Sie brauchen ebenfalls Firewall-Regeln, die IKE-Verkehr erlauben. IKE verwendet UDP, um Nachrichten zum ISAKMP-Port (Internet Security Association Key Management Protocol) zu schicken. Die Regeln sollten früh in der Regelkette auftauchen:

ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp
ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp

Wenn racoon läuft, können Sie versuchen, mit ping von einem Gateway-Rechner aus den anderen Gateway zu erreichen. Die Verbindung wird zwar immer noch nicht verschlüsselt, aber racoon wird die Security-Association zwischen beiden Systemen einrichten. Dies kann eine Weile dauern, und Sie bemerken vielleicht eine kleine Verzögerung, bevor die Antworten von der Gegenstelle kommen.

Die Security-Association können Sie sich auf einem der beiden Gateway-Systeme mit setkey(8) ansehen:

setkey -D

Damit ist die erste Hälfte der Arbeit getan. Jetzt muss noch die Security-Policy konfiguriert werden.

Damit wir eine sinnvolle Security-Policy erstellen können, fassen wir das bisher geleistete zusammen. Die Diskussion gilt für beide Enden des Tunnels.

Jedes gesendete IP-Paket enthält im Header Informationen über das Paket selbst. Im Header befinden sich die IP-Adressen des Senders und des Empfängers. Wie wir bereits wissen, dürfen private IP-Adressen, wie 192.168.x.y nicht auf das Internet gelangen. Pakete zu privaten IP-Adressen müssen zuerst in einem anderen Paket gekapselt werden. In diesem Paket werden die privaten IP-Adressen durch öffentliche IP-Adressen ersetzt.

Das ausgehende Paket hat beispielsweise wie folgt ausgesehen:

Es wird in ein anderes Paket umgepackt (gekapselt) und sieht danach wie folgt aus:

Die Kapselung wird vom gif-Gerät vorgenommen. Das neue Paket enthält im Header eine öffentliche IP-Adresse und der Datenteil des Pakets enthält das ursprüngliche Paket.

Natürlich soll der gesamte Datenverkehr des VPNs verschlüsselt werden. Dies kann man wie folgt ausdrücken:

“Wenn ein Paket von A.B.C.D zu W.X.Y.Z geschickt wird, verschlüssele es entsprechend der Security-Association.”

“Wenn ein Paket von W.X.Y.Z kommt und für A.B.C.D bestimmt ist, entschlüssele es entsprechend der Security-Association.”

Das ist fast richtig. Mit diesen Regeln würde der ganze Verkehr von und zu W.X.Y.Z verschlüsselt, auch wenn er nicht zum VPN gehört. Die richtige Formulierung lautet:

“Wenn ein Paket, das ein gekapseltes Paket enthält, von A.B.C.D zu W.X.Y.Z geschickt wird, verschlüssele es entsprechend der Security-Association.”

“Wenn ein Paket, das ein gekapseltes Paket enthält, von W.X.Y.Z kommt und für A.B.C.D bestimmt ist, entschlüssele es entsprechend der Security-Association.”

Dies ist eine zwar subtile aber eine notwendige Änderung.

Die Security-Policy können Sie mit setkey(8) erstellen. setkey(8) besitzt eine Konfigurations-Syntax zur Erstellung der Security-Policy. Sie können die Konfiguration über die Standardeingabe oder in einer Datei, die Sie mit der Option -f angeben, erstellen.

Gateway #1 (öffentliche IP-Adresse: A.B.C.D) muss folgendermaßen konfiguriert werden, um alle ausgehenden Pakete an W.X.Y.Z zu verschlüsseln:

spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require;

Speichern Sie dieses Kommando in einer Datei, beispielsweise /etc/ipsec.conf ab. Rufen Sie anschließend das nachstehende Kommando auf:

# setkey -f /etc/ipsec.conf

spdadd weist setkey(8) an, der Security-Policy-Datenbank eine Regel hinzuzufügen. Der Rest der Zeile gibt an, auf welche Pakete diese Regel zutrifft. A.B.C.D/32 und W.X.Y.Z/32 sind die IP-Adressen und Netzmasken, die Systeme angeben, auf die diese Regel zutrifft. Im Beispiel gilt die Regel für die beiden Gateway-Systeme. ipencap zeigt an, dass die Regel nur für Pakete gilt, die gekapselte Pakete enthalten. -P out legt fest, dass die Regel nur für ausgehende Pakete gilt.

ipsec gibt an, dass die Pakete geschützt werden. Das benutzte Protokoll wird durch esp angegeben. tunnel kapselt das Paket in ein IPsec-Paket. Die nochmalige Angabe von A.B.C.D und W.X.Y.Z gibt die Security-Association an. Das abschließende require erzwingt die Verschlüsselung der Pakete.

Diese Regel gilt nur für ausgehende Pakete. Sie brauchen eine analoge Regel für eingehende Pakete:

spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require;

In dieser Regel wird in anstelle von out benutzt und die IP-Adressen sind notwendigerweise umgekehrt angegeben.

Das zweite Gateway-System mit der IP-Adresse W.X.Y.Z braucht entsprechende Regeln:

spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec esp/tunnel/W.X.Y.Z-A.B.C.D/require;
spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec esp/tunnel/A.B.C.D-W.X.Y.Z/require;

Schließlich brauchen Sie auf beiden Gateway-Systemen noch Firewall-Regeln, die ESP- und IPENCAP-Pakete in beide Richtungen erlauben:

ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z
ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D
ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z
ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D

Da die Regeln symmetrisch sind, können sie auf beiden Systemen verwendet werden.

Damit sehen ausgehende Pakete wie folgt aus:

Am anderen Ende des VPNs werden die Pakete zuerst entsprechend der von racoon ausgehandelten Security-Association entschlüsselt. Das gif-Interface entfernt dann die zweite Schicht, damit das ursprüngliche Paket zum Vorschein kommt. Dieses kann dann in das interne Netzwerk transportiert werden.

Dass die Pakete wirklich verschlüsselt werden, können Sie wieder mit ping(8) überprüfen. Melden Sie sich auf dem Gateway A.B.C.D an und rufen das folgende Kommando auf:

tcpdump dst host 192.168.2.1

Auf demselben Rechner setzen Sie dann noch das nachstehende Kommando ab:

ping 192.168.2.1

Dieses Mal wird die Ausgabe wie folgt aussehen:

XXX tcpdump output

Jetzt zeigt tcpdump(1) ESP-Pakete an. Auch wenn Sie diese mit der Option -s untersuchen, werden Sie wegen der Verschlüsselung nur unverständliche Zeichen sehen.

Herzlichen Glückwunsch. Sie haben soeben ein VPN zwischen zwei entfernten Netzen eingerichtet.

Zusammenfassung

• IPsec muss in beiden Kernelkonfigurationsdateien enthalten sein:

  options IPSEC
  options IPSEC_ESP
  

• Installieren Sie security/racoon. Tragen Sie auf beiden Rechnern in ${PREFIX}/etc/racoon/psk.txt jeweils die IP-Adresse des entfernten Gateways und den geheimen Schlüssel ein. Setzen Sie die Zugriffsrechte der Datei auf 0600.

• Fügen Sie auf jedem Rechner die folgenden Zeilen zu /etc/rc.conf hinzu:

  ipsec_enable="YES"
  ipsec_file="/etc/ipsec.conf"
  

• Erstellen Sie auf jedem Rechner die Datei /etc/ipsec.conf mit den nötigen spadd-Zeilen. Auf dem Gateway #1 hat die Datei folgenden Inhalt:

  spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P out ipsec
    esp/tunnel/A.B.C.D-W.X.Y.Z/require;
  spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P in ipsec
    esp/tunnel/W.X.Y.Z-A.B.C.D/require;
  

  Auf dem Gateway #2 sieht die Datei so aus:

  spdadd W.X.Y.Z/32 A.B.C.D/32 ipencap -P out ipsec
    esp/tunnel/W.X.Y.Z-A.B.C.D/require;
  spdadd A.B.C.D/32 W.X.Y.Z/32 ipencap -P in ipsec
    esp/tunnel/A.B.C.D-W.X.Y.Z/require;
  

• Fügen Sie auf beiden Rechnern Firewall-Regeln hinzu, die IKE-, ESP- und IPENCAP-Verkehr erlauben:

  ipfw add 1 allow udp from A.B.C.D to W.X.Y.Z isakmp
  ipfw add 1 allow udp from W.X.Y.Z to A.B.C.D isakmp
  ipfw add 1 allow esp from A.B.C.D to W.X.Y.Z
  ipfw add 1 allow esp from W.X.Y.Z to A.B.C.D
  ipfw add 1 allow ipencap from A.B.C.D to W.X.Y.Z
  ipfw add 1 allow ipencap from W.X.Y.Z to A.B.C.D
  

Das VPN wurde in zwei Schritten eingerichtet. Maschinen auf beiden Netzen können miteinander kommunizieren und der Datenverkehr zwischen beiden Netzen wird automatisch verschlüsselt.