Im Folgenden habe ich noch einmal ein altes Tutorium von mir aus 2005 veröffentlicht. Ein paar nützliche Informationen sind sicherlich heute auch noch dabei.

1.Einleitung
1.1 Was ist VPN? - Hintergrund und Anwendung
1.2 Was ist IPSec?
1.2.1 AH: (Authentification Header)
1.2.2 ESP: (Encapsulating Security Payload)
1.2.3 Preshared Keys (PSK)
1.2.4 Transportmodus
1.2.5 Tunnelmodus
2 Das VPN-Szenario / Installation und Konfiguration
2.1 Installation der Gateways
2.2 Installation der Clients
2.3 Konfiguration der Gateways
2.3.1 Netzwerkkonfiguration
2.3.2 Konfiguration von IPSec & Racoon
2.4 Konfiguration der Clients
3 Der VPN-Test
3.1 VPN Netzwerktest
3.2 VPN Tunneltest
4. Fazit
5. Links

1.1 Was ist VPN? - Hintergrund und Anwendung

Durch die zunehmende Dezentralisierung und Automatisierung des Workflows in vielen Wirtschaftsbereichen ist es für viele Beteligten immer wichtiger geworden, auch von geographisch unterschiedlichen Orten einen benötigten Zugriff auf zentrale Datenbestände zu haben. Eine solide Absicherung des "gesamten" Netzwerks und eine hohe Verfügbarkeit für externe Standorte wird daher heute noch vielfach mit teurer Hardware und dedizierten Leitungen erkauft.
Als kostengünstigere Alternative stehen bereits seit einigen Jahren vollwertige VPN-Lösungen gegenüber, die jedoch vielfach mit propertärer Software und den damit verbunden Lizenzkosten pro Rechner im Einsatz sind.

Bei einem VPN handelt es sich um ein "Virtuelles Privates Netzwerk" (Virtual Private Network), das es zusammen mit einer Verschlüsselungstechnologie wie IPSec oder SSL ermöglicht, eine sichere Kommunikation zwischen zwei oder mehreren Rechnern oder ganzen Netzwerken herzustellen und somit in der Lage ist, diese nach außen hin abzusichern.
Der Clou an einem VPN ist, dass die Kommunikation über inhomogene Netzwerke, im häufigsten Falle über das Internet, erfolgen kann. Diese Netzwerke sind jedoch selbst "unsicher".

Mit Beginn des "FreeS/WAN"-Projektes im Jahr 1996 hat sich auch einiges im OpenSource-Bereich getan und es stehen mittlerweile seit einigen Jahren eine ganze Reihe von recht mächtigen Tools zur Verfügung, die den Aufbau eines VPN ermöglichen und dabei helfen, auf Dauer kostengünstig den Netzwerkbetrieb zu sicher.

Hierbei haben sich in erster Linie zwei Projekte hervor getan:

OpenS/WAN (früher FreeS/WAN) und einmal die ab dem Linux-Kernel 2.5.47 bereits nativ implementierten IPSec-Tools, die selbst auf dem USAGI-Projekt basieren. Es handelt sich hierbei um eine alternative Implementierung des IPSec Stacks zum ehemaligen FreeS/WAN-Projekt.

Zusammen mit den derzeit zur Auswahl stehenden IKE-Dämons (IKE=Internet Key Exchange) isakmpd, racoon (KAME) und "pluto" (OpenS/WAN) lassen sich VPN-Lösungen mit Linux auch in inhomogenen Umgebungen präzise realisieren.
Aufgrund der Auswahlmöglichkeiten der Tools, die allesamt mit sehr viel Funktionen mächtig ausgestattet sind, beschränkt sich dieses Tutorial auf die derzeitige native Implementierung des IPSec Stack mit den mitgelieferten IPSec-Tools und dem IKE-Dämon "racoon". Es soll konkret aufzeigen, welche Schritte zu einer korrekten Konfiguration für ein VPN anhand eines vorgestellten Beispielszenarios notwendig sind.

Die große Ausstattung der Funktionalitäten stellt gerade am Anfang ein Hindernis dar, da es viele Wege gibt, wie IPSec und Racoon im Zusammenspiel mit anderen benötigten Netzwerktools wie "route" und "iptables" pp. konfigurierbar ist. Beim hier vorgestellten Beispiel-Szenario ist es möglich, mit relativ wenigem Zusatzaufwand noch möglich weiterführende Anforderungen zu erfüllen und damit andere Szenarien für ein VPN zu realisieren. Weiterführende Informationen finden sich dazu in der Linkliste.

1.2 Was ist IPSec?

IPSec wurde 1998 entwickelt, um die Schwächen des Internetprotokolls (IP) zu beheben. Es stellt eine Sicherheitsarchitektur für die Kommunikation über IP-Netzwerke zur Verfügung. IPsec soll Vertraulichkeit, Authentizität und Integrität gewährleisten. Daneben soll es vor so genannten Replay-Angriffen schützen. Das heisst: ein Angreifer kann nicht durch Abspielen eines vorher mitgeschnittenen Dialogs die Gegenstelle zu einer wiederholten Aktion verleiten.
IPSec entstand im Zuge der Entwicklung von IPv6 und ist in verschiedenen RFCs spezifiziert:

RFC 2401 - Sicherheitsarchitektur für das Internetprotokoll
RFC 2402 - Authentication Header
RFC 2406 - Encapsulating Security Payload
RFC 2407 - IPsec Domain of Interpretation (IPsec DoI)
RFC 2408 -Internet Security Association and Key Management Protocol (ISAKMP)
RFC 2409 - Internet Key Exchange (IKE)

Der RFC 2401 bildet das Hauptdokument zu IPsec. Er beschreibt die Architektur von IPsec. Von dort aus werden die oben genannten RFCs referenziert. Die wesentlichen Inhalte von IPsec sind das Authentication Header Protokoll (AH) und das Encapsulated Security Payload Protokoll (ESP), sowie das Protokoll zum Austausch der Schlüssel.
Ein kurzer Überblick über die Aufgaben der Protokolle:

1.2.1 AH: (Authentification Header)

Das AH-Protokoll sorgt für die Authentisierung der zu übertragenen Daten und Protokollinformationen. AH wird zum Schutz der Paketintegrität und der Paketauthentizität eingesetzt. Die erfolgt über ein Hashing-Verfahren (MD5 und SHA1). Da der äußere IP-Header in die Hashprüfung mit einbezogen wird, ist auf AH-Pakete keine Art von NAT (NAT=Network Address Translation) anwendbar.
Im AH-Paket befindet sich, neben verschiedenen anderen Feldern, der Security Profile Index (SPI) und eine Sequenznummer. Diese Sequenznummer kann zum Schutz vor Replay-Attacks verwendet werden. AH nutzt die IP-Protokoll-Nummer 51.

1.2.2 ESP: (Encapsulating Security Payload)

Das ESP-Protokoll dient der Verschlüsselung eines Datenpaketes und über das Hashing-Verfahren auch zur Integritätssicherung. Zur Verschlüsselung können beliebige Verfahren zur Verschlüsselung eingesetzt werden. Allerdings muss der "DES"-Versclüsselungsalgorithmus unterstützt werden. Bei IPSec in der Version 0.5 ist bereits auch "3DES" implementiert. Als Hashing-Verfahren müssen MD5-96 und SHA-96 verfügbar sein.
Im ESP-Header befindet sich - vergleichbar mit dem AH-Paket - der sogenannte Security Profile Index (SPI) und eine Sequenznummer. ESP nutzt die IP-Protokoll-Nummer 50.
Es gibt zudem mehrere Möglichkeiten des Verbindungsaufbaus:

1.2.3 Preshared Keys (PSK)

Es existieren Schlüssel auf zwei Rechnern, um eine Verbindung "von Hand" aufzubauen, indem zuvor die Schlüssel gegenseitig ausgetauscht und verifiziert werden. Bei Erfolg wird eine Verbindung aufgebaut. Über einen IKE-Dämon (racoon,pluto,iskampd) werden die Schlüssel ausgetauscht Dies ist die sichere Variante und wird bei dem Beispielszenario verwendet. Es gibt zudem zwei verschiedene Transportmodi:

1.2.4 Transportmodus

Im Transportmodus wird ausschließlich der Datenteil (Nutzdaten/ "Payload") des IP-Paketes verschlüsselt. Alle anderen Teile der Nachricht, also der IP-Header selbst, bleiben unverändert. Den Nutzdaten wird nur der ESP-Header vorangestellt. Dieses Verfahren wird zur Übertragung von kritischen Informationen z.B. von Passwörtern verwendet.

1.2.5 Tunnelmodus

Im Tunnelmodus wird das komplette IP-Paket vor der Übertragung verschlüsselt und mit einem neuen IP-Header versehen, der die Daten für das Ziel-Gateway enthält. Auf diese Weise können transparente Verbindungen zwischen zwei Firmenstandorten über das Internet hergestellt werden oder, wie in diesem Beispielszenario, ein Rechner bzw. über ein Switch auch mehrere Rechner über ein öffentliches (IP-)Netzwerk z.B. mit einem Firmennetz verbunden werden.

2. Das VPN Szenario / Installation und Konfiguration

In dem zu hier entwickelnden Beispielszenario liegt die Anwendung des VPN darauf, zwei verschiedene Subnetze miteinander sicher zu verbinden und nach außen hin vor unbefugtem Zugriff abzusichern. Die Wahl der Konfiguration fällt auf den Tunnelmodus mit Einsatz von X.509 Zertifikaten, die von einer CA zur gegenseitigen Authentifizierung der Gateways abgesegnet werden. Diese Lösung ist insgesamt sicherer ist als bei den anderen Modi und besser, da sie besser zu skalieren ist.
Wird zwischen den beiden Gateways bei einer Anfrage eines Client von Subnetz A zu einem Client aus Subnetz B abgesetzt, wird zwischen den beiden Gateways ein VPN-Tunnel etabliert und es werden Daten verschlüsselt zwischen den Gateways ausgetauscht und danach unverschlüsselt an den anderen Client weitergeleitet. Für jeden Client sieht es so aus, als wenn dieser lokal auf die Rechner des anderen Subnetzes zugreifen würde. Würde man weitere Netzwerke dahinter absichern wollen, so müssen hierfür weitere Tunnel konfiguriert werden.

Auf die Konfiguration einer Firewall wie "iptables" wird in diesem Beispiel bewusst verzichtet, da deren Konfiguration in jedem Fall separat durchgeführt werden muss. Da ein Einsatz jedoch in jedem Produktivsysytem aus Sicherheitsgründen unabdingbar ist, muss für eine korrekte Funktionsweise des VPN am einfachsten das Konfigurationstool Yast2 gestartet werden und im Punkt "Sicherheit & Benutzer >> Firewall" in der Liste der zugelassenen Dienste, der Dienst "IPSec" aktiviert werden, sodass entsprechend verwendete Ports (50/51) wieder frei geschaltet sind.

Bei dem diesem Beispielszenario werden fest konfigurierte IP-Adressen für alle Geräte verwendet, jedoch ist der Aufbau mit dynamischen Adressen für die Gateways auch kein Problem. Es existieren im Internet kostenlose, jederzeit verfügbare Dienste wie "DynDNS.org", die es ermöglichen einer fest konfigurierten DynDNS-Domain unterschiedliche IP-Adressen, zum Beispiel über entsprechende Router regelmäßig zuzusenden, sodass diese Domain immer mit der aktuellen IP-Adresse der Gateways aufgelöst wird.

Die Gateways in dem Beispielszenario selbst verfügen über zwei Ethernet Netzwerkkarten, sodass keine Aliase gebildet werden müssen, die Clients benötigen jeweils nur eine Ethernetkarte.

2.1 Installation der Gateways

Als Betriebssystem für die beiden Gateways dient die aktuell verfügbare SuSE-Distribution 9.3 mit dem Kernel 2.6.10. Als zusätzliche Pakete müssen die mitgelieferten IPSec-Tools in der aktuellen Version 0.5. und das Tool OpenSSL (V0.97) für die Erzeugung sämtlicher Zertifikate für die Gateways und der CA (Certificate Authority) mit installiert werden. Ansonsten können die Systeme mit den Standardeinstellungen oder individuell installiert werden.

2.2 Installation der Clients

Die Auswahl des Betriebssystems ist für die Installation der Clients frei wählbar. Damit klar wird, dass der Aufbau des VPN unter Linux keinen Einfluss auf andere Betriebssysteme hat, die auf den Clients laufen, wird bei der Installation der Clients das Betriebssystem Windows XP verwendet.

2.3 Konfiguration der Gateways

Im folgenden Abschnitt wird auf die Konfiguration der beiden benötigten Gateways näher eingegangen.

2.3.1 Netzwerkkonfiguration

Die Konfiguration der Gateways bei diesem Beispielszenario beschränkt sich rein auf die Lauffähigkeit des VPN. Es empfiehlt sich für die folgende Konfiguration ein kleines Shellskript anzulegen, das bei der Initialisierung des Systems gestartet wird. Die angegebenen Pfade können je nach Distribution variieren. Zuerst ist eine Konsole mit SuperUser-Rechten z.B. "root" zu öffnen.

Das Stoppen der Firewall erfolgtauf den Gateways mit:

#Wichtig:

Die SuSEfirewall2 wird mit diesem Befehl mit ihren kompletten Sicherheitsrichtlinien gestoppt. Erfolgt dieser Schritt über das Verwaltungstool Yast bzw. Yast2 wird zwar der Dienst selbst gestoppt, jedoch nicht alle Sicherheitsrichtlinien automatisch mit gelöscht. Dies kann schnell zur Verwirrung bei der korrekten Konfiguration der Gateways führen, da z.B. bei einem Ping von Client zu Client zwar ein VPN-Tunnel korrekt etabliert wird, jedoch keine Daten übertragen werden können.
Als nächstes erfolgt die Routeneintragung der beiden Gateways, damit alle Anfragen von Subnetz A auf Subnetz B und umgekehrt über die Gateways weitergeleitet werden können.

Jetzt ist noch das IP-Forwarding einzuschalten.
 

Damit die internen Subnetze nun vor den unsicheren, äußeren Netzen abgeschirmt sind, muss das Masquerading, also die "Network Address Table" (NAT) für die beiden Netzwerkkarten eingeschaltet werden, damit keine Anfragen von außerhalb durch die Gateways weitergeleitet werden.
 

Damit ist die reine Netzkonfiguration der Gateways abgeschlossen. Zur Überprüfung der Gatewayrouten schauen wir uns mit "route -n" die Routingtabellen auf beiden Gateways an:

2.3.2 Konfiguration von IPSec und Racoon

Wie bereits erwähnt, kann der Aufbau des VPN mit IPSec mit verschiedenen Methoden erfolgen. Die sicherste Variante ist die Verwendung von X.509-Zertifikaten und einer CA, da bei einer asynchronen Verschlüsselungsmethode Schlüsselpaare (privater und öffentlicher Schlüssel) verwendet werden. Jeder beteiligte Gateway besitzt in diesem Szenario ein solches Schlüsselpaar, wobei bei jedem Verbindungsaufbau jeweils immer nur der öffentliche Schlüssel ausgetauscht wird. Nähere Informationen dazu finden sich als Link im Anhang.
Würde man das VPN auf einen Einsatz für Roadwarrior erweitern, kämen für die Clients je nach Plattform entweder reine X.509-Zertifiakte bzw. für die Windows-Plattform vollwertige PKCS#12-Zertifikate zum Einsatz. Dies ist die sicherste Variante und zugleich ein  entscheidener Vorteil im Vergleich zum Aufbau eines VPN mit SSL, da man als Administrator jederzeit vollen Zugriff auf jede Verbindung besitzt, nicht erst auf Applikationsebene. Es ist sollte daher auch defacto die 1. Wahl beim Aufbau eines VPN sein.

Für die Erzeugung der Schlüssel und der Zertifikate ist jedoch vorher eine CA (Certificate Authority) einzurichten.
Diese "unterschreibt" Zertifikatsanfragen und erkennt generierte Schlüsselpaare an, oder verwirft diese wenn diese in einer CRL (Certificate Revocation List) stehen. Dies geschieht aus Sicherheitsgründen meistens auf einer getrennten Maschine. Das Gleiche gilt ebenfalls für die Firewall und den Gateway, worauf jedoch im Rahmen dieses Tutorials verzichtet wird, um die grundsätzliche Vorgehensweise zu verdeutlichen.
Die Erstellung der CA und der Zertifikate erfolgt mit Hilfe des Tools OpenSSL, das zu Beginn der Installation mitinstalliert wurde und braucht nur auf einem Gateway durchgeführt zu werden.

Wir erstellen zunächst ein Verzeichnis für die CA:
 

Danach wechseln wir in das Verzeichnis
 

und erstellen ein neues Verzeichnis, dem wir volle Zugriffsrechte geben und erstellen eine neue CA.
 

Als nächstes ist die PEM Passphrase einzugeben und die Eingabe zu wiederholen.
Diese Passphrase wird später noch benötigt. Danach müssen weitere Daten eingegeben werden, die beispielsweise mit folgenden Werten versehen werden können: LAND, PROVINZ, STADT, FIRMA, ABTEILUNG, NAME, EMAIL.
 

Nach dem erstellen der CA wird in das folgende Verzeichnis gewechselt und anschliessend der private Schlüssel für die CA erzeugt:
 

Es erscheint folgende Meldung:
 

Wir wechseln eine Verzeichnisebene höher
 

Mit Eingabe der privaten Passwortphrase ist die Certificate Authority (CA) nun fertig konfiguriert. Als nächstes wird ein Zertifikat für das erste Gateway erstellt, welches von der CA abgezeichnet werden muss. Dieses funktioniert folgendermaßen:
 

Das neue Zertifikat liegt nun in "newreq.pem" vor und muss noch von der CA unterschrieben werden.
 

Folgendermaßen kann dann ein Zertifikat aussehen, jedoch ist dieses von der Version der CA abhängig.
 

Das unterschriebene Zertifikat liegt nun in newcert.pem vor. Die beiden Dateien werden zum bessern Verständnis umbenannt. Dies geschieht mit:
 

Als nächstes wird das Zertifikat für die Gegenstelle erzeugt. Dies geschieht auf dieselbe Art wie beim ersten Zertifikat, folglich sollte zunächst wieder mit
 

ein neues Request erzeugt werden, wobei auch hier wieder die gefragten Angaben eingegeben werden müssen. Dies können dieselben Daten wie beim ersten Request sein, dies ist aber nicht zwingend notwendig. Danach wird dieser wieder mit:
 

signiert. Auch diese Dateien werden der Übersicht halber umbenannt.
 

Die Zertifikate und der private Schlüssel der CA müssen nun noch auf das andere Gateway per Diskette o.ä. übertragen werden. Um die Richtlinien für den IPSec-Stack einzurichten und den IKE-Dämon für X.509-Zertifikate zu konfigurieren wird bei beiden Gateways wie folgt vorgegangen. Wir wechseln zunächst in das Racoon-Verzeichnis und legen ein Verzeichnis für die Zertifiakte an:
 

Danach werden die Zertifikate der Gateways zusammen mit dem CA-Key auf beiden Gateways in dieses Verzeichnis kopiert und anschließend mit den Rechten '0700' versehen. Die Überprüfung der über das Netz übermittelten Zertifikate erfolgt ebenfalls mit OpenSSL. Damit OpenSSL das CA-Zertifkat findet und die evtl. angegebene CRL, müssen auf beiden Gateways noch symbolische Links erzeugt werden:
 

Damit racoon nicht in der Lage ist einen verschlüsselten privaten Schlüssel zu lesen, müssen diese noch entschlüsselt werden:
 

#Wichtig:

Die folgenden Rechte müssen gesetzt werden, da ansonsten der Racoon-Dämon den Austausch der öffentlichen Schlüssel nicht vornehmen kann!
 

Folgende Konfigurationsdaten sollten sich in dem Verzeichnis /etc/racoon/ bereits befinden:

- racoon.conf
- setkey.conf

Falls diese Dateien noch nicht existieren legen wir sie einfach an und editieren sie wie folgt:
 

In der Konfigurationsdatei racoon.conf stehen alle Angaben über die Methode und der benötigten Ressourcen für die gegenseitige Authentifizierung sowie die Angaben mit welcher Verschlüsselungsmethode gearbeitet wird, etc. Nähere Informationen dazu werden in Kapitel 6 aus "VPN mit Linux" (Addison Wesley) von Ralf Spenneberg gut erklärt und daher hier darauf verzichtet. Dieses Kapitel ist ebenfalls kostenlos auf der Website des Autors als PDF-Dokument verfügbar! Um eine sichere und korrekte Konfiguration zu gewährleisten setzten wir den Pfad zur Konfigurationsdatei "racoon.conf" wie folgt auf beiden Gateways:
 

Dieser Befehl weist den Dämon an, definitiv immer beim Start die richtige Konfigurationsdatei einzulesen.
Die VPN-Tunneleinstellungen selbst erfolgen über das Tool "setkey", das mit den IPSec-Tools automatisch installiert wird.
Wir editieren nun die Konfigurationsdatei "setkey.conf"
 

Wie man sieht, spiegeln sich die Konfigurationsdateien der beiden Gateways.
Mit den Befehlen "flush" und "spdflush" wird zunächst alle eventuell bestehenden Sicherheitsrichtlinien von IPSec restlos gelöscht.
Anschließend wird mittels "spdadd" jeweils zwei Verbindungsarten zwischen den Gateways bzw. zwischen deren angeschlossenen Subnetzen hergestellt. Es wäre auch möglich, auch nur einen einseitigen Datenverkehr durch einen Tunnel durchzulassen, daher existieren pro Verbindung immer zwei Einträge.
Zu Demonstrationszwecken wurden die beiden Gateways selbst ebenfalls mit den beiden letzten Policies abgesichert.

#Wichtig:

Normalerweise wäre nur die 1. Regel für den Datenaustausch zwischen den beiden Subnetzen notwenig. Da jedoch die beiden Subsetze nach außen maskiert werden, ändert sich auch der IP-Adressheader auf die IP-Adresse der Netzwerkkarte des Gateways, die die Daten zum anderen Gateway transportiert. Würde man die 2.-4. Regel weglassen, würde sich zwar der VPN-Tunnel zwischen den Gateways aufbauen, allerdings würden alle IP-Pakete unverschlüsselt übertragen werden, da genau genommen hierfür keine Regel existiert.

Die beiden Konfigurationsdateien "racoon.conf" und "setkey.conf" dürfen nur reine "root"-Rechte besitzen, da sie andernfalls nicht eingelesen werden und dabei auch keine Fehlermeldung in "/var/log/messages" ausgegeben werden würde.
Wir geben den Konfigurationsdateien also noch reine "root"-Rechte:
 

2.4 Konfiguration der Clients

Nachdem die Konfiguration der Gateways abschlossen ist, müssen noch die Netzwerkeinstellungen der Clients für das Szenario eingestellt werden.
Unter Windows XP/2000 geschieht dies über die Konfiguration der Netzwerkverbindungen in der Systemsteuerung.

Konfiguration Client 1:

Wir wechseln zunächst in die Systemsteuerung und wählen Netzwerkverbindungen an. Anschliessend wählen wir die Eigenschaften der angeschlossenen Netzwerkkarte aus:



Jetzt wählen wir die Internetprotokolleigenschaften aus (TCP/IP) und klicken auf Eigenschaften:



Als nächstes tragen wir wie in Abb. 2.3 zu sehen ist, die entsprechenden Daten ein und bestätigen.



Die Konfiguration des 2. Client läuft gleichermaßen ab. Tragen Sie entsprechende Werte aus Abb. 2.4 im 2. Client ein und bestätigen.



Jetzt ist der VPN-Tunnel soweit konfiguriert. Lediglich der racoon-Dämon und der IPSec-Dienst muss auf den Gateways gestartet werden. Dies erfolgt in Abschnitt 3.
 

3. Der VPN-Test

Im folgengen Abschnitt wird beschrieben, wie das aufgebaute Netzwerk auf seine Funktionsfähigkeit getestet werden kann.
 

3.1 VPN Netzwerktest

Um ein VPN auf seine seine korrekte Arbeitsweise zu testen gibt es, je nach Anwendung und Architektur des Szenarios, mehrere Möglichkeiten.
In diesem Fall liegt der Focus auf dem korrekten Aufbau des Tunnels und die Möglichkeit verschlüsselt Daten zwischen den Subnetzen bzw. den beteiligten Clients auszutauschen. Ist kein Tunnel etabliert, darf ein Zugriff von außerhalb auf beide Subnetze nicht möglich sein, da diese zuvor nach außen durch das Masquerading abgeschirmt worden sind. Zum anderen muss der Datenaustausch bei eingeschaltetem racoon zwischen den Gateways verschlüsselt erfolgen. Es besteht jedoch die Möglichkeit, trotz eines zuvor aufgebauten Tunnels, Daten unverschlüsselt zwischen den Gateways zu übertragen, wenn nicht ausreichend viele Regeln für den Tunnelaufbau definiert worden sind.

Der reine Netzwerktest kann über einen der Clients einfach mit dem Befehl "ping" in der Konsole ausgeführt werden. Wir öffnen dazu eine Windowskonsole: (Start >> Ausführen >> "cmd" eingeben und bestätigen) und setzen einen PING-Befehl ab. Da die racoon-Dämone noch nicht auf beiden Gateways gestartet sein dürfen, muss bei korrekter Konfiguration folgende Meldung auf dem Schirm des anfragenden Clients erscheinen:
 

#Wichtig:

Ist ein Ping zum anderen Client mit ausgeschaltetem IPSec möglich, ist das andere Subnetz für jeden anderen Rechner von außerhalb verfügbar und somit falsch konfiguriert! In diesem Fall auf jeden Fall das Masquerading und die NAT-Einstellungen auf den Gateways überprüfen und die Fehler ggf. korrigieren.

3.2 VPN-Tunneltest

Wir starten nun den racoon-Dämon auf beiden Gateways. Die Regeln für den Tunnelaufbau werden automatisch durch einen internen Aufruf von setkey gleichzeitig eingelesen und gesetzt.

Nun sollte folgende Meldung auf dem Schirm des Client1 erscheinen, wenn wieder ein Ping an den anderen Client abgesetzt wird:
 

Dies ist jedoch noch kein eindeutiger Beweis dafür, dass der VPN-Tunnel korrekt aufgebaut wurde.
In der Systemlogdatei auf den Gateways lässt sich mühelos feststellen, ob eine IPSec-Verbindung aufgebaut und ob diese auch tatsächlich genutzt wurde:

Dazu sehen wir uns "var/log/messages" auf beiden Gateways an:
 

Interessant sind hier die Zeilen mit den Informationen ".IPsec-SA established: ESP/Tunnel 192.168.1.1->192.168.1.125 spi=...".
Dies ist der Beweis für den korrekten Aufbau des VPN-Tunnels selbst. Jetzt bleibt noch nachzuweisen, ob durch diesen Tunnel auch wirklich die Daten des PING-Befehls übertragen wurden. Dies lässt sich während eines PING's einfach mit dem Netzwerktool "tcpdump" feststellen, das den Datenverkehr auf der externen Netzwerkkarte mitliest.

Mittels "tcpdump -i eth0" bzw. "tcpdump -i eth1" auf den Gateways lässt sich feststellen, ob die IP-Pakete wirklich verschlüsselt übertragen wurden bzw. werden. Dies lässt sich anhand des Kürzels "ESP" für eine ESP-Verschlüsselung festellen. Wurde ein IP-Paket nicht verschlüsselt, fehlt dieses Kürzel in der Zeile.

Möchte man genau wisssen, welche der definierten Regeln zuletzt nach dem Tunnelaufbau benutzt wurden, kann sich alle Sicherheitsrichtlinien und die zuletzt verwendeten Sicherheitsrichtlinien auf den Gateways mit "setkey -DP" anzeigen lassen.
Wurde eine Regel in der Tat benutzt, wird bei jeder Benutzung ein Timestamp gesetzt wie z.B. "lastused: Jun 30 18:28:08 2005".

4. Fazit

Die Verwendung der nativen Implementierung des IPSec Stacks in Zusammenhang mit dem IKE-Dämon racoon ab dem Linux Kernel 2.6.10 ist prinzipiell unproblematisch und von den Kinderkrankheiten aus dem 2.5.47 Kernel ist auch nichts mehr zu sehen. racoon ist in der Lage mit verschiedenen anderen Implementierungen zusammenzuarbeiten und bietet zudem umfassende Optionen für die Anpassung an andere Systeme.

Was jedoch Probleme bereiten kann, ist zum Beispiel die uneinheitliche Administration der SuSEfirewall2. Sie lässt sich beispielsweise nur in der Konsole komplett mit ihren gesamten Richtlinien ausschalten, während sie dies über das Tool Yast nicht tat, dass mitunter viel Zeit für die korrekte Konfiguration vergeudet hat. Zudem erfordert die Einrichtung eines VPN mit Linux erweiterte Kenntnisse in der Administration des Betriebssystems auf Konsolenebene, das erspart bliebe, wenn der Administrator ein VPN mit Windows aufsetzt.
Eine graphische Oberfläche für die Konfiguration von IPSec und racoon wäre für Linux auf jeden Fall in Zukunft wünschenswert.

Insgesamt gesehen bleibt aber dem Verantwortlichen eines Netzwerkes jedoch nichts anderes übrig, als sich zur Genüge in die Materie VPN und IPSec bei erweiterter Konfiguration  und Problembehebung einzuarbeiten, egal welches Betriebssystem nun der Favorit ist.

5. Links

Im folgenden befinden sich die Literaturquellen, welche hilfreich beim Aufbau und der Konfiguration des VPN's waren.

"VPN mit Linux", Ralf Spenneberg, Addison Wesley (2. Auflage 2004)

Forum "VPN mit Linux" von Ralf Spenneberg 
http://www.spenneberg.com/VPNmitLinux/164.html

"Linux Advanced Routing & Traffic Control" 
http://lartc.org/howto/lartc.ipsec.html

"IPSec-HowTo" 
http://www.ipsec-howto.org/t1.html

Homepage der IPSec-Tools (basierend auf dem KAME-Projekt)
http://ipsec-tools.sourceforge.net/