Solaris

Im Test kam Solaris 10 in der aktuellen Version zum Einsatz. Die ersten Versuche in einer XEN-HVM-Umgebung wurden aufgrund extrem schlechter Performance auf eine VM mit Virtualbox verschoben.

Auch Solaris teilt die Konfiguration in mehrere Dateien auf:

• »/etc/inet/ipsecinit.conf« enthält die Policy ähnlich dem Setkey-Skript bei Kame/Racoon, jedoch sind hier auch die Algorithmen für Phase 2 in der Regel hinterlegt. In der Regel ist außerdem ein Tunnel-Interface konfiguriert.
• »/etc/hostname.ip.tunX« : Das üblicherweise eingestellte Tunnelinterface steht in dieser Datei. Es kann auch manuell mit dem Kommando »ifconfig« angelegt werden, würde aber dann einen Reboot nicht überstehen. Für jede Verbindung muss es eine solche Datei geben.
• »/etc/inet/ike/config« : Diese Datei entspricht der »racoon.conf« , enthält aber abgesehen von Definitionen für die Lebenszeit der Schlüssel und die verwendete PFS-Gruppe nur Parameter für Phase 1. Für jedes Gegenüber lassen sich hier die Parameter wie verwendete Authentisierung, lokale und entfernte IP-Adresse der Verbindung sowie die Algorithmen angeben. Im Gegensatz zu Racoon ist es jedoch möglich, die Parameter allgemein für alle Verbindungen zu setzen (wenn alle Phase-1-Verbindungen mit 3DES verschlüsselt werden sollen) und nur im Einzelfall einen unpassenden Parameter zu überschreiben. Die Möglichkeit die Verbindungen mit Namen zu versehen, hilft bei der Fehlersuche.
• »/etc/inet/ike/secret/ike.preshared« : Speicherort für den Fall voreingestellter Passwörter. Diese Datei enthält das Passwort als Hexstring, den der Administrator mit »od« aus dem Klartextpasswort erzeugen muss.

Die Tunneldefinition sieht wie folgt aus (das Beispiel gehört zur Verbindung zu Racoon aus der Übersicht):

192.168.60.254 192.168.2.23 tsrc 192.168.1.105 tdst 192.168.1.7 router up

Eine zusammengefasste Version von »/etc/inet/ike/config« für den gleichen Partner sieht aus wie in Listing 4 .

Nun fehlt noch die Phase-2-Definition aus der »ipsecinit.conf« :

{tunnel ip.tun1 negotiate tunnel laddr 192.168.60.0/24 raddr 192.168.2.0/24 } ipsec {encr_algs aes encr_auth_algs sha1 sa shared}

Schließlich fehlt noch die Definition des Shared Secret aus »/etc/inet/ike/secret/ike.preshared« ( Listing 5 ).

In der Kombination mit Racoon ist es möglich, den Hexstring direkt in »psk.txt« einzutragen. Auch die Juniper SRX bietet die Möglichkeit, einen Hexstring statt Klartext einzugeben. Der Schlüssel »test123« ergibt den Hexstring »74657374313233« . Ein Klartextpasswort lässt sich mit »echo Password |od -tx« in den notwendigen Hexstring umwandeln.

Solaris 10 führte das Konzept von Diensten ein, die mit »svcadm« gestoppt und gestartet werden. Zur Fehlersuche empfiehlt es sich, den Dienst zu stoppen und den IKE-Daemon von Hand zu starten. Auch das Routing muss aktiviert sein, da der Rechner ja als Gateway dienen soll. Den IKE-Daemon findet der Administrator unter »/usr/lib/inet/in.iked« . Er akzeptiert eine Option »-d« , um das Debugging zu aktivieren.

Im Test war die Hürde nicht die Konfiguration der Parameter für die Verschlüsselung, sondern das Routing. Im Gegensatz zu Racoon muss der Administrator dafür sorgen, dass eine IP-Route in das "gegenüberliegende" Netz existiert. Das Verwirrende dabei war für den Autor die Tatsache, dass als Gateway der Route die IP-Adresse des Gateways auf der Innenseite des anderen LANs angegeben werden muss. In der Kopplung mit Racoon musste also die Route in das Netz 192.168.2.0/24 auf das Gateway 192.168.2.23 gesetzt werden. Dauerhaft lassen sich Route unter Solaris wie unter Windows mit der Option »-p« setzen.

Windows 2008

Die Konfiguration unter Windows 2008 Server hat den Autor einige schlaflose Nächte gekostet, obwohl sie letztlich ganz einfach ist. Erst der Link unter [1] und das vollständige Löschen und die Neukonfiguration führten zum Erfolg. Bevor ein Windows 2008 Server als VPN-Gateway fungieren kann, muss erst einmal das IP Forwarding aktiviert werden. Außerdem sollten die Network Policy and Access Services installiert werden.

Die Konfiguration erfolgt über die Windows-Firewall beziehungsweise deren Management-Consolen-Plugin oder über das Kommandozeilentool »netsh« . In den allgemeinen Eigenschaften der Windows-Firewall definiert der Administrator die Parameter für Phase 1 und 2. Dies geschieht unter dem Reiter »IPSEC Settings« , wo man jeweils »Advanced« wählen muss, um die Parameter einzustellen. Hier verbirgt sich auch die größte Falle bei der Verbindung mit einem Microsoft Server: PFS wird in Phase 2 nicht unterstützt, wenn die Konfiguration über das GUI stattfindet, man muss es also beim Partner deaktivieren oder »netsh« verwenden, doch dazu später mehr. Die Eingabe der Parameter in den Phasen 1 und 2 ist in den Dialogen in Abbildung 2 und 3 zu sehen.

Abbildung 2: Definition der Phase 1 bei Windows 2008.

Abbildung 3: Definition der Phase 2 bei Windows 2008.

Nun legt der Windows-Administrator eine Connection Security Rule an. Endpunkt 1 ist dabei immer das LAN am Windows Server, Endpunkt 2 das LAN auf der anderen Seite. Die IP-Adressen der Gateways sind die Adressen auf der Außenseite. Der Wizard zum Anlegen einer neuen Regel fragt noch die Authentisierungsmethode ab, die man auf »Pre Shared Key« setzen muss. Fortan wird das Passwort pro Verbindung hinterlegt. Es ist nicht möglich, pro Verbindung andere Parameter für Verschlüsselungsalgorithmen auszuwählen.

Schließlich muss der Admin noch eine Route in das LAN des Verbindungspartners setzen, die auf die äußere IP-Adresse des VPN Gateways zeigt. Damit die Routen Reboots überleben, sollte hier (wie bei Solaris) die Option »-p« verwendet werden.

Statt einer Konfiguration über das GUI kann man auch mit »netsh« arbeiten. Dabei ist es dann auch möglich, PFS in Phase 2 zu aktivieren oder individuelle Algorithmen pro Verbindung anzugeben. Ein Beispiel für die Konfiguration gibt Listing 6 .

Wenn der Admin viele Tunnel anlegen muss, empfiehlt sich das Skripten über »netsh« , nicht nur wegen der Vielzahl der Optionen, sondern auch, weil es einfach schneller geht. Die Fehlersuche bei Windows gestaltete sich besonders schwierig, da in der Standardkonfiguration gar keine Logeinträge im Windows Eventlog landen, die etwas mit den IPSEC-Verbindungen zu tun haben. Erst ein Technet-Artikel [2] zur Verwendung von »auditpol.exe« brachte Aufklärung. Die Syntax des Aufrufs ist:

auditpol.exe /set /category "System"/subcategory "IPsec Driver" /success:enable/failure:enable

Damit tauchen dann im Security Log Fehlermeldungen für IKE-Verhandlungen auf. Kommt keine Verbindung zustande, fehlt leider oft der Grund.