Das FreeBSD-Handbuch
Zurück | Kapitel 14. Sicherheit | Weiter

# 14.10. VPNs mit IPsec

Geschrieben von Nik Clayton.

Dieser Abschnitt beschreibt, wie Sie mit FreeBSD-Gateways ein Virtual-Private-Network (VPN) einrichten. Als Beispiel wird ein VPN zwischen zwei Netzen verwendet, die über das Internet miteinander verbunden sind.

## 14.10.1. IPsec Grundlagen

Geschrieben von Hiten M. Pandya.

Dieser Abschnitt zeigt Ihnen, wie Sie IPsec einrichten und damit FreeBSD-Systeme und Microsoft® Windows® 2000/XP Systeme sicher miteinander verbinden. Um IPsec einzurichten, sollten Sie einen neuen Kernel erzeugen können (siehe Kapitel 8).

IPsec ist ein Protokoll, das auf dem Internet-Protokoll (IP) aufbaut. Mit IPsec können mehrere Systeme geschützt miteinander kommunizieren. Das in FreeBSD realisierte IPsec-Protokoll baut auf der KAME-Implementierung auf und unterstützt sowohl IPv4 als auch IPv6.

> Anmerkung: FreeBSD enthält eine von Hardware beschleunigte Variante des IPsec-Protokolls. Diese Variante wurde von OpenBSD übernommen und wird “Fast-IPsec” genannt. Das crypto(4)-Subsystem arbeitet mit Kryptographie-Hardware zusammen, die IPsec beschleunigt. Das Subsystem ist neu und bietet noch nicht alle Funktionen, die KAME-IPsec bietet. Wenn Sie die Hardware-Beschleunigung nutzen wollen, fügen Sie folgende Zeile der Kernelkonfiguration hinzu:

>     options      FAST_IPSEC  # new IPsec (cannot define w/ IPSEC)

> Momentan können Sie “Fast-IPsec” nicht zusammen mit KAME-IPsec benutzen. Weiteres zu “Fast-IPsec” erfahren Sie in der Hilfeseite fast_ipsec(4).

> Anmerkung: Damit Firewalls den Status von gif(4)-Tunneln überwachen können, müssen Sie die Option `IPSEC_FILTERGIF` in Ihrer Kernelkonfiguration aktivieren:

>     options   IPSEC_FILTERGIF  #filter ipsec packets from a tunnel

IPsec besteht wiederum aus zwei Protokollen:

- Encapsulated Security Payload (ESP) verschlüsselt IP-Pakete mit einem symmetrischen Verfahren (beispielsweise Blowfish oder 3DES). Damit werden die Pakete vor Manipulationen Dritter geschützt.

- Der Authentication Header (AH) enthät eine kryptographische Prüsumme, die sicher stellt, dass ein IP-Paket nicht verändert wurde. Der Authentication-Header folgt nach dem normalen IP-Header und erlaubt dem Empfänger eines IP-Paketes, dessen Integrität zu prüfen.

ESP und AH können, je nach Situation, zusammen oder einzeln verwendet werden.

IPsec kann in zwei Modi betrieben werden: Der Transport-Modus verschlüsselt die Daten zwischen zwei Systemen. Der Tunnel-Modus verbindet zwei Subnetze miteinander. Durch einen Tunnel können dann beispielsweise verschlüsselte Daten übertragen werden. Ein Tunnel wird auch als Virtual-Private-Network (VPN) bezeichnet. Detaillierte Informationen über das IPsec-Subsystem von FreeBSD enthält die Hilfeseite ipsec(4).

Die folgenden Optionen in der Kernelkonfiguration aktivieren IPsec:

    options   IPSEC        #IP security
    options   IPSEC_ESP    #IP security (crypto; define w/ IPSEC)

Wenn Sie zur Fehlersuche im IPsec-Subsystem Unterstützung wünschen, sollten Sie die folgende Option ebenfalls aktivieren:

    options   IPSEC_DEBUG  #debug for IP security

## 14.10.2. Was ist ein VPN?

Es gibt keinen Standard, der festlegt, was ein Virtual-Private-Network ist. VPNs können mit verschiedenen Techniken, die jeweils eigene Vor- und Nachteile besitzen, implementiert werden. Dieser Abschnitt stellt eine Möglichkeit vor, ein VPN aufzubauen.

## 14.10.3. VPN zwischen zwei Netzen über das Internet

Dieses Szenario hat die folgenden Vorausetzungen:

- Es müssen zwei Netzwerke vorhanden sein.

- Beide Netzwerke müssen intern IP benutzen.

- Beide Netzwerke sind über einen FreeBSD-Gateway mit dem Internet verbunden.

- Der Gateway jedes Netzwerks besitzt mindestens eine öffentliche IP-Adresse.

- Die intern verwendeten IP-Adressen können private oder öffentliche Adressen sein. Der Gateway kann, wenn nötig, IP-Adressen mit NAT umschreiben.

- Die IP-Adressen der internen Netzwerke dürfen nicht überlappen. Mit NAT ließe sich diese Anforderung zwar umgehen, doch wäre die Konfiguration und Pflege des resultierenden Netzwerks zu aufwändig.

Wenn die zu verbindenden Netzwerke intern dieselben IP-Adressen benutzen (beispielsweise `192.168.1.x`), müssen einem der Netzwerke neue IP-Adressen zugewiesen werden.

Die Netzwerktopologie sieht wie folgt aus:

Beachten Sie die beiden öffentlichen IP-Adressen. Im Folgenden werden sie durch Buchstaben (als Platzhalter) gekennzeichnet. Setzen Sie hierfür Ihre eigenen öffentlichen IP-Adressen ein. Beide Gateways besitzen die interne Adresse `x.x.x.1` und beide Netzwerke besitzen unterschiedliche private IP-Adressen: `192.168.1.x` und `192.168.2.x`. Die Default-Route aller internen Systeme ist jeweils die Gateway-Maschine (`x.x.x.1`).

Aus der Sicht der Systeme sollen jetzt beide Netzwerke wie über einen Router, der in diesem Fall etwas langsamer ist, verbunden werden.

Auf dem Rechner `192.168.1.20` soll also beispielsweise der folgende Befehl funktionieren:

    ping 192.168.2.34

Windows-Systeme sollen die Systeme auf dem anderen Netzwerk erkennen und Shares sollen funktionieren. Alles soll genauso wie in lokalen Netzwerken funktionieren.

Zusätzlich soll die Kommunikation zwischen beiden Netzwerken noch verschlüsselt werden.

Das VPN wird in mehreren Schritten aufgebaut:

1. Zuerst wird eine virtuelle Verbindung zwischen beiden Netzwerken über das Internet eingerichtet. Die virtuelle Verbindung können Sie mit Werkzeugen wie ping(8) prüfen.

2. Danach wird eine Sicherheitsrichtlinie (Security-Policy) festgelegt, die automatisch den Datenverkehr zwischen beiden Netzwerken verschlüsselt und entschlüsselt. Mit Werkzeugen wie tcpdump(1) können Sie überprüfen, dass die Daten tatsächlich verschlüsselt werden.

3. Wenn sich Windows-Systeme im VPN gegenseitig erkennen sollen, so sind noch weitere Konfigurationsschritte notwendig, die aber nicht in diesem Abschnitt beschrieben werden.

### 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:

    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 ifconfig(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:

    # ifconfig gif0 create
    # ifconfig gif0 tunnel 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:

    # ifconfig gif0 create
    # ifconfig gif0 tunnel 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:

    ifconfig gif0

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

    # ifconfig gif0
    gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
            tunnel inet A.B.C.D --> W.X.Y.Z
            inet 192.168.1.1 --> 192.168.2.1 netmask 0xffffffff

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

- Fügen Sie in beiden Kerneln die Zeile “device gif” ein und bauen Sie die Kernel neu.

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

      gif_interfaces="gif0"
      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, das Sie über den Port `security/ipsec-tools` installieren können.

Auf beiden Gateway-Maschinen muss racoon laufen. Konfiguriert wird jeweils die IP-Adresse der Gegenstelle sowie der geheime Schlüssel. Dabei muss auf beiden Gateway-Maschinen 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 den Port `security/ipsec-tools`. 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.

Zurück | Zum Anfang | Weiter
OpenSSL | Nach oben | OpenSSH

Wenn Sie Fragen zu FreeBSD haben, schicken Sie eine E-Mail an <de-bsd-questions@de.FreeBSD.org>.
Wenn Sie Fragen zu dieser Dokumentation haben, schicken Sie eine E-Mail an <de-bsd-translators@de.FreeBSD.org>.