Ein IPSec-Gateway im Eigenbau
Seite 5: Windows ins VPN
Windows ins VPN
Bei Windows 2000 und XP ist IPSec bereits Bestandteil des Betriebssystems. Allerdings lässt es sich mit Bordmitteln nicht vernünftig einrichten. Abhilfe schafft das IPSec-Tool von Marcus Müller (siehe Soft-Link), das auf ein Kommandozeilen-Tool angewiesen ist, das zwar zu Windows gehört, aber standardmäßig nicht mitinstalliert wird. Dies lässt sich über den Installer SUPTOOLS.MSI in Support\Tools auf der Windows-CD nachholen. Erst wenn man die vollständige Installation auswählt, landet das Programm ipseccmd beziehungsweise ipsecpol auch auf der Platte. Das ZIP-Archiv mit dem müllerschen IPSec-Tool packt man am besten nach c:\ipsec aus.
Dort legt man auch das notwendige Zertifikat ab. Das ist als Datei mit der Endung "p12" in der von make_cert erstellten ZIP-Datei enthalten. Um sicherzustellen, dass alles am richtigen Ort landet, darf man sie allerdings nicht durch einen einfachen Doppelklick importieren, sondern muss den Umweg über die Management-Konsole nehmen.
Ein Doppelklick auf die Datei IPSec.msc startet dazu die Konsole mit dem Snap-In für Zertifikatsverwaltung. Im rechten Fenster unter "Zertifikate/Eigene Zertifkate" öffnet die rechte Maustaste über "All Tasks/Importieren" den gewünschten Assistenten. Mit der Option "Zertifikatsspeicher automatisch auswählen" befördert dieser die Zertifkate an die richtigen Stellen: Das eigene Zertifikat findet sich unter "Eigene Zertifikate/Zertifikate", das der VPN-CA unter "Vertrauenswürdige Stammzertifizierungsstellen/Zertifikate".
Das IPSec-Tool arbeitet mit einer FreeS/WAN-ähnlichen Konfigurationsdatei (siehe S. 121). Ein wesentlicher Unterschied ist, dass man statt des Namens des Zertifikatseigentümers den der ausstellenden CA mit rightca angeben muss. Die Option network=ras gilt für Dial-up-Verbindungen (ISDN, Modem oder DSL); ist der Rechner über ein Netz mit dem Internet verbunden, ist an dieser Stelle lan einzusetzen.
Befindet sich der Windows-Rechner dabei hinter einem Router, ist eine Besonderheit zu beachten: Windows meldet dann beim IPSec-Gateway, dass es ein Subnetz mit seiner eigenen Adresse routen möchte (192.168.1.2/32). Für diese Konfiguration sind also auf dem Firmen-Gateway entsprechende Verbindungsbeschreibungen mit rightsubnet beziehungsweise rightsubnetwithin nötig.
Der Aufruf von ipsec.exe aktiviert die in ipsec.conf definierte Policy, baut aber noch keine VPN-Verbindung auf. Dies geschieht erst, wenn ein Programm versucht, auf eine der IP-Adressen im Firmennetz zuzugreifen. So meldet
ping 10.1.1.1
zunächst "IP-Sicherheit wird verhandelt" und unter Umständen mehrfach "Zeitüberschreitung der Anforderung." Spätestens nach dem dritten Ping-Paket sollte allerdings eine Antwort auftauchen. Der Aufruf
ipsec -delete
beendet die VPN-Verbindung wieder.
Zu Problemen kommt es unter Umständen, wenn die Verbindung länger als fünf Minuten inaktiv ist. Windows schickt nach dieser Zeit eine "Delete SA"-Nachricht an das Gateway und beendet die IPSec-Verbindung. Da FreeS/WAN diese Meldung ignoriert, lässt sich der VPN-Zugang erst nach einem längeren Timeout wieder aufbauen. Als Workaround kann man dafür sorgen, dass regelmäßig Pakete über die virtuelle Leitung gehen, beispielsweise indem man in der Netzwerkumgebung einen WINS-Server im externen Netz einträgt.
Richtig Abhilfe schafft der Patch "Notify/Delete SA", der in dem erweiterten Super-FreeS/WAN und dem FreeS/WAN-Paket für Debian/unstable bereits eingebaut ist. Damit registriert FreeS/WAN die Delete-SA-Meldung, so dass die VPN-Verbindung bei Bedarf sofort wieder aktiviert werden kann.
Mac OS X enthält von Haus aus die der BSD-Welt entstammende IPSec-Implementierung Kame. Auch diese kann mit X.509-Zertifikaten umgehen und IPSec-Verbindungen mit einem FreeS/WAN-Gateway aufbauen. Allerdings beschränken sich die grafischen Tools zur IPSec-Administration wie VaporSec und VPN Tracker bisher auf Pre-Shared Keys. Die Konfiguration mit X.509-Zertifikaten erfolgt deshalb Mac-untypisch über die Kommandozeile. Eine Anleitung dazu findet sich auf [3].
