Ein IPSec-Gateway im Eigenbau

Inhaltsverzeichnis

Um Mitarbeitern oder ganzen Filialen von außen Zugang zum internen Firmennetz zu gewähren, braucht man ein vollwertiges VPN-Gateway, das mit mehreren Verbindungen gleichzeitig umgehen kann. Im einfachsten Fall übernimmt die Firewall auch gleich die Rolle dieses VPN-Pförtners. Linux-Distributionen wie SuSE und Debian enthalten bereits die Linux-IPSec-Implementierung FreeS/WAN, für Red Hat gibt es fertige RPM-Pakete. Wer sich nicht zutraut, damit eine Linux-Firewall selbst aufzusetzen, ist vielleicht mit einer speziell dafür gebauten Linux-Distribution besser bedient.

Mit dem auf der CD im letzten Heft enthaltenen IPCop kann man innerhalb einer Viertelstunde eine Firewall aufsetzen, die auch gleich alle notwendigen Erweiterungen für ein vollwertiges IPSec-Gateway enthält. Leider hinkt das Web-Frontend für die Administration der Entwicklung etwas hinterher. Es taugt lediglich dazu, einfache IPSec-Verbindungen zwischen zwei Firmen-Netzen einzurichten. Wer sich jedoch vor der Linux-Kommandozeile nicht fürchtet, findet im Kasten "IPCop und IPSec" eine kurze Anleitung, wie er die folgende Anleitung zum Aufbau eines VPN-Gateways auf eine IPCop-Firewall umsetzen kann.

Das VPN-Gateway sollte über einen direkten Zugang zum Internet verfügen und nicht hinter einem Router stehen, der Network Address Translation macht (NAT). Als Alternative kann man das VPN-Gateway auch in einer entmilitarisierten Zone (DMZ) platzieren. Dies erfordert jedoch zusätzliche Regeln auf der Firewall und spezielles Routing der im VPN verwendeten Adressen.

Das VPN-Gateway muss nicht unbedingt eine feste, offizielle IP-Adresse haben, ein DynDNS-Name über den es jederzeit erreichbar ist, tuts zur Not auch (siehe c't-Artikel 10/2003 S. 210). Man muss dann lediglich dafür sorgen, dass FreeS/WAN nach jedem Trennen der Internet-Verbindung angehalten und nach dem erneuten Aufbau wieder gestartet wird. Wie man das einrichtet, ist weiter hinten im Artikel beschrieben.

Die benötigte Hardware-Ausstattung hängt von den Anforderungen ab. In unseren Versuchen hatte jedoch selbst ein Pentium-Rechner mit 100 MHz und 64 MByte RAM keine Schwierigkeiten bis zu zehn gleichzeitige VPN-Verbindungen ohne nennenswerte Performance-Einbußen zu bedienen. Die FreeS/WAN-Dokumentation enthält eine detaillierte Aufschlüsselung des Performance-Bedarfs für IPSec-Verbindungen. Danach genügt bereits eine 300-MHz-CPU, um eine 10-MBit/s-Verbindung mit IPSec-Paketen zu sättigen.

Neben Linux unterstützen auch Windows 2000/XP und Mac OS X IPSec, so dass diese direkt als VPN-Clients arbeiten können. Ältere Windows-Versionen benötigen spezielle IPSec-Clients wie Sentinel von SSH (www.ssh.com). Alternativ gibt es von Microsoft auch für sie IPSec-Implementierungen, die sich aber nur zusammen mit dem Layer-2 Tunneling Protocol (L2TP) einsetzen lassen. Diese Kombination L2TP/IPSec ist aber auf Linux-Seite noch nicht so ausgereift, dass man ihren Einsatz in Produktionsumgebungen empfehlen könnte.

Der Internet-Zugang der externen Rechner kann wahlweise direkt oder über einen (Hardware-)Router erfolgen - sofern dieser IPSec-Passthrough beherrscht. Das bedeutet konkret, dass er das zum verschlüsselten Datenaustausch verwendete Internet-Protokoll 50 (Encapsulating Security Payload, ESP) richtig weiterleitet und außerdem die Pakete für den Schlüsselaustausch (Internet Key Exchange, IKE) speziell behandelt. Er muss dazu ausgehende Pakete, die von UDP-Port 500 an UDP-Port 500 gerichtet sind, zwar mit seiner eigenen Adresse versehen, darf dabei aber den Quellport nicht ändern (was bei NAT normalerweise geschieht). Die meisten aktuellen Router und auch Linux haben damit keine Probleme.

Den Ausweis bitte!

Den Ausweis bitte!

Außer der Verschlüsselung übernimmt das VPN-Gateway die Authentifizierung und sorgt dafür, dass nur autorisierte Gegenstellen eine VPN-Verbindung aufbauen können. Im einfachsten Fall geschieht dies über ein geheimes Passwort (auch oft als Pre-Shared Key, kurz PSK bezeichnet). Für VPN-Nutzer ohne feste IP-Adresse - in der FreeS/WAN-Nomenklatur Road Warrior - ist dieser Mechanismus jedoch unbrauchbar: Aufgrund des Designs von IPSec müssten dabei alle das gleiche Passwort verwenden. Um einem (Ex-)Mitarbeiter den Zugang zu sperren, müssten alle anderen das Passwort ändern.

Deshalb wickelt man die Authentifizierung besser über Public-Key-Mechanismen ab, wie sie auch die E-Mail-Verschlüsselung mit PGP/GNUPG benutzt. Standardmäßig setzt FreeS/WAN dazu RSA-Schlüssel ein, mit denen jedoch Windows nicht umgehen kann. Die in Windows 2000 und XP enthaltenen IPSec-Erweiterungen erwarten vollwertige X.509-Zertifikate. Für deren Unterstützung braucht FreeS/WAN derzeit noch einen zusätzlichen Patch, der in vielen fertigen Paketen jedoch bereits enthalten ist. Dann meldet sich FreeS/WAN beim Start mit:

Starting Pluto (FreeS/WAN Version 1.99)
  including X.509 patch (Version 0.9.15)

in der Log-Datei /var/log/auth.log (bei manchen Distributionen in secure).

Die Echtheit solcher X.509-Zertifikate beglaubigt eine Zertifizierungsstelle (Certification Authority, CA). Für ein VPN empfiehlt es sich, eine eigene CA einzurichten, damit man die Zertifikate für die VPN-Nutzer selbst ausstellen kann. Auch dafür gibt es unter Linux mit OpenSSL ein kostenloses Open-Source-Paket.

X.509 und OpenSSL haben wir bereits in [1] ausführlich erläutert, Details dazu würden den Rahmen dieses Artikels sprengen. Für dieses VPN-Projekt genügen die dort ebenfalls vorgestellten Skripte zum Aufbau einer kleinen VPN-CA (siehe Soft-Link und Kasten "Die Mini-CA").

Es ist zwar prinzipiell möglich, die VPN-CA auf dem VPN-Gateway selbst zu betreiben, aus Sicherheitsgründen sollte diese Aufgabe jedoch besser ein separater Linux-Rechner übernehmen. Wer nicht so weit gehen will, ein Notebook nur für diesen Zweck abzustellen und im Tresor aufzubewahren, kann zumindest den geheimen Schlüssel der Root-CA auf Diskette oder einen USB-Stick auslagern und diese getrennt aufbewahren. Ein externes Backup der Schlüssel ist auf jeden Fall anzuraten.

Schwanenzucht

Schwanenzucht

Damit die Firewall den IPSec-Verkehr nicht blockiert, muss man unter Umständen zusätzliche Paketfilterregeln erstellen. Der Schlüsselaustausch und die Authentifizierung erfolgen auf UDP-Port 500, die verschlüsselten Daten sendet IPSec über das Internet-Protokoll 50 (Encapsulating Security Payload, ESP). Einfache Regeln dafür sehen so aus:

iptables -A INPUT -p udp --sport 500 --dport 500 -j ACCEPT
iptables -A INPUT -p 50 -j ACCEPT

Je nach Firewall-Konfiguration sind analoge Regeln für die OUTPUT-Chain erforderlich. Vor der eigentlichen Konfiguration von FreeS/WAN sind noch einige Dateien an den richtigen Platz zu kopieren. Das mit

./make_cert Gateway

erstellte Zertifikat GatewayCert.pem muss in /etc/ipsec.d/ liegen, der geheime Schlüssel GatewayKey.pem in /etc/ipsec.d/private/. Das Zertifikat der vertrauenswürdigen CA (cacert.pem) findet seinen Platz in /etc/ipsec.d/cacerts/, die Liste der widerrufenen Zertifikate (crl.pem) in /etc/ipsec.d/crls/. Die Zugriffsrechte entsprechen den normalen Vorgaben; lediglich private/ darf nur für den Eigentümer root les- und schreibbar sein.

Die ebenfalls nur für den Administrator lesbare Datei /etc/ipsec.secrets nimmt die Passphrase auf, mit der FreeS/WAN auf den geheimen Schlüssel zugreifen kann:

: RSA GatewayKey.pem "sehr geheim"

(der Doppelpunkt am Zeilenanfang und eine abschließende Leerzeile sind wichtig).

Die Konfigurationsdatei /etc/ipsec.conf gliedert sich in mehrere Sektionen, deren Beginn ein Eintrag am Zeilenanfang markiert. Die einzelnen Angaben einer Sektion sind eingerückt. Wer mit "#" eine Option auskommentiert, darf dieses Zeichen nicht am Zeilenanfang einfügen.

Die Einträge im Bereich "config setup" enthalten allgemeine Einstellungen. Im Listing links oben stehen dort nur die Standardwerte, deren Bedeutung die FreeS/WAN-Dokumentation erläutert [2]. Sektionen, die mit dem Schlüsselwort "conn" beginnen, beschreiben eine Verbindung, "conn %default" kommt für alle Verbindungen zur Anwendung und enthält ebenfalls einige Standardeinstellungen. Die Einträge in Zeile 13 und 14 sorgen dafür, dass die Authentifizierung grundsätzlich über Zertifikate erfolgt.

Das Präfix "left" oder "right" legt fest, auf welche Seite der Verbindung sich eine Option bezieht. Es hat sich dabei eingebürgert, immer left als lokalen Endpunkt und right als entfernt (remote) zu verwenden.

Die Option auto gibt an, ob FreeS/WAN eine Verbindung nur registrieren (add) oder auch gleich initiieren soll (start). Da das VPN-Gateway Verbindungsanfragen entgegennimmt, aber selbst keine aufbaut, steht in der %default-Sektion "auto=add".

Die eigene Adresse (left) lautet im Listing %defaultroute. Das ersetzt FreeS/WAN selbstständig durch die IP-Adresse der Schnittstelle auf die die Default-Route zeigt - also in der Regel die Adresse, über die Internet-Verkehr abgewickelt wird. Wenn man hier explizit eine IP-Adresse des Rechners einträgt, muss man auch über leftnexthop das zu verwendende Gateway angeben.

Bei einer restriktiven Firewall-Policy muss man explizit dafür sorgen, dass die entschlüsselten Pakete weitergereicht werden. Die Option

leftupdown=/usr/local/lib/ipsec/updown

legt ein Skript fest, das FreeS/WAN automatisch aufruft, wenn eine Verbindung zu Stande kommt. Für Firewalls mit iptables kann man zumeist ohne weitere Modifikationen das mitgelieferte Skript _updown.x509 verwenden, das sich im FreeS/WAN-Verzeichnis (meist /user/local/lib/ipsec) befindet. Es fügt die notwendigen Regeln ein und entfernt sie nach dem Verbindungsende auch wieder.

conn-Anweisungen

Die folgenden conn-Anweisungen spezifizieren konkrete Verbindungen. Dabei ist zu beachten, dass bei IPSec zu einer Verbindungsbeschreibung auch die darüber zu routenden Adressen gehören. Diese überprüft FreeS/WAN beim Verbindungsaufbau. Will eine Gegenstelle ein Netzwerk routen, das nicht aufgeführt ist, akzeptiert FreeS/WAN die Verbindung nicht. Die Fehlermeldung lautet dann: "cannot respond to IPsec SA request because no connection is known for ...", gefolgt von einer Beschreibung der angeforderten Verbindung. Kommen über eine etablierte Verbindung Pakete mit Adressen, die nicht zu der Verbindungsbeschreibung passen, verwirft sie das Gateway ohne weiteren Kommentar. Die einfachste Beschreibung besteht aus:

right=%any

Damit kann sich ein Road Warrior via IPSec beim Gateway anmelden. Dabei werden nur die Verbindungen zwischen diesen beiden Rechnern verschlüsselt. %any bedeutet, dass das Gateway zunächst Verbindungen von jeder beliebigen IP-Adresse entgegennimmt - wie es für die Anbindung eines Road Warrior auch erforderlich ist. Die IPSec-Verbindung kommt jedoch nur zu Stande, wenn sich die Gegenstelle mit einem Zertifikat ausweisen kann, das eine akzeptierte CA beglaubigt hat.

Alternativ kann man mit right natürlich auch eine feste IP-Adresse beziehungsweise den zugehörigen Namen der Gegenstelle angeben. Die DynDNS-Namen der Road Warrior funktionieren hier leider nicht - beziehungsweise genauer: nicht auf Dauer. Denn FreeS/WAN löst den Namen beim Start in die zugehörige Adresse auf. Ändert sich die Adresse der Gegenstelle, erkennt sie das VPN-Gateway nicht mehr.

Soll das Gateway den Zugang zu einem Firmennetz vermitteln, muss dieses in der Verbindungsbeschreibung als leftsubnet aufgeführt werden. Frees/WAN verwendet bei der Angabe von Netzwerkadressen übrigens eine verkürzte Schreibweise. 10.0.0.0/8 bedeutet, dass nur die ersten acht Bit das Netzwerk festlegen, die restlichen 24 dienen dazu, einzelne Hosts in diesem Netz zu spezifizieren. Es entspricht also einer konventionellen Netzmaske von 255.0.0.0.

Arbeitet die Gegenstelle ihrerseits als Gateway für ein dahinter liegendes Netz, kann man dies als rightsubnet angeben. Die im Listing unter n2n verwendete Variante rightsubnetwithin überlässt es der Gegenstelle, ein beliebiges Subnetz aus dem angegebenen Netz zu benutzen. Diese Freizügigkeit ist allerdings nur eingeschränkt zu empfehlen. Wenn mehrere Road Warrior dieselben Adressen verwenden, sind Probleme vorprogrammiert.

Da mit diesen einfachen Verbindungsbeschreibungen jeder mit einem beglaubigten Zertifikat Zugang zum Firmennetz erhält, kommt man zumindest auf dem Gateway nicht um die Verwendung von Widerrufslisten (CRLs) herum. Nur so kann man beispielsweise den VPN-Zugang aus der Firma ausgeschiedener Mitarbeiter sperren.

Es ist auch möglich, einem Zertifikat eine konkrete Verbindungsbeschreibung zuzuordnen. Dazu spezifiziert man als rightid den so genannten Distinguished Name, der Bestandteil des Zertifikats ist. Das Skript make_cert schreibt diesen in die Datei names.txt. Von dort überträgt man sie am besten via Copy & Paste in die Konfigurationsdatei. Durch explizite Zuweisungen des rightsubnet-Parameters kann der Administrator dann festlegen, wer welche Adressen verwenden darf.

Man braucht sich nicht davor zu scheuen, viele individuelle Verbindungsbeschreibungen anzulegen: Frees/WAN kann nach Angaben der Entwickler ohne weitere Optimierungen circa fünfzig davon handhaben - auch Konfigurationen mit über zweihundert seien machbar.

Road Warrior

Läuft der externe Rechner ebenfalls unter Linux, unterscheidet sich das Setup nicht wesentlich von dem des Gateways. Das Listing oben zeigt, wie eine Verbindungsbeschreibung für eine Linux-Firewall aussieht, die das Heim-LAN 192.168.111.0/24 mit dem Firmennetz 10.0.0.0/8 verbindet. Dies entspricht der n2n-Sektion des Firmen-Gateways. Soll nur ein einziger Rechner den Zugang erhalten, lässt man leftsubnet weg und erhält damit eine p2n-Verbindung. Das FreeS/WAN auf dem Firmen-Gateway sucht sich dazu selbstständig die passende Verbindungsbeschreibung. Ob der Rechner hinter einem (IPSec-fähigen) Router steht oder die Internet-Verbindung selbst herstellt, spielt keine Rolle.

Anders als das fest ans Internet angebundene VPN-Firmen-Gateway wird ein Road Warrior FreeS/WAN nicht schon beim Start des Systems hochfahren. Deshalb sollte man die symbolischen Links *ipsec in den Runlevel-Verzeichnissen /etc/rc[0.6].d/ entfernen - entweder von Hand oder mit dem KDE-Tool ksysv. Der Benutzer kann die VPN-Verbindung dann mit "/etc/init.d/ipsec start" beziehungsweise "stop" steuern oder automatisch bei jedem Aufbau der Internet-Verbindung über /etc/ppp/ip-up und ip-down auf- und abbauen. Außerdem kann man hier die iptables-Regeln für IPSec über die zusätzliche Angabe von -s <vpngate> auf das VPN-Gateway beschränken.

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].

Fehlersuche

Fehlersuche

Kommt aus unerfindlichen Gründen keine Verbindung zu Stande, gilt der erste Blick der Log-Datei auf dem VPN-Gateway. Hier protokolliert FreeS/WAN jeden Verbindungsversuch, den Verlauf der Verhandlungen und schließlich die Erfolgsmeldung "IPsec SA established". Am besten beobachtet man den Verbindungsaufbau life mit

tail -f /var/log/auth.log

Meldet FreeS/WAN hier gar nichts, kommen vermutlich keine IPSec-Pakete auf dem VPN-Gateway an. Dies kann man mit

tcpdump -i eth0 not port ssh

überprüfen. Der not-Filter blendet SSH-Verkehr aus, das Interface eth0 muss man auf Systemen mit Dial-up-Zugang durch ppp0 ersetzen. Mögliche Ursachen können falsch eingetragene Adressen oder Paketfilter-Regeln sein, die die Pakete verwerfen.

Klappt die Authentifizierung nicht, stimmt wahrscheinlich irgendetwas mit den verwendeten Zertifikaten beziehungsweise deren Installationspfad nicht. Konkretere Hinweise liefern unter Umständen die Einträge in der Log-Datei oder die Ausgabe von

ipsec auto --listall

das alle FreeS/WAN bekannten Zertifikate anzeigt.

Meldet FreeS/WAN "IPsec SA established", es kommen aber trotzdem keine Ping-Antworten zurück, werden die Pakete irgendwo unterwegs verworfen oder falsch weitergeleitet. Um die Ursache dafür aufzuspüren, muss man sie auf ihrem Weg schrittweise mit tcpdump verfolgen.

Sendet ein Rechner in einem Heimnetz ein Ping-Paket in Richtung Firmennetz, kommt dies zunächst auf dem internen Interface (eth0) des heimischen VPN-Gateways an. Das System leitet es dann an das IPSec-Interface ipsec0 weiter. Dort wird es verschlüsselt, in ESP verpackt und über das externe Interface (ppp0) verschickt. Als ESP-Paket kommt es auf dem externen Interface des Firmen-Gateways an, das es entschlüsselt und dann - wieder als Ping-Paket - über ipsec0 an das interne Interface des Firmen-Gateways weiterreicht, über das es sein Ziel erreichen sollte. Die Antwort nimmt denselben Weg rückwärts. Durch systematisches Sniffen mit tcpdump auf all diesen Interfaces sollte sich der Punkt, an dem die Pakete verloren gehen und damit hoffentlich auch die Ursache dafür, aufspüren lassen.

Mehr Komfort

Wer auf den internen Firmen-Webserver zugreift, möchte dabei nicht mit Adressen wie 10.1.1.100 hantieren. Die URL http://intern.firma.com quittiert der Browser jedoch trotz VPN-Verbindung zunächst mit einer Fehlermeldung, da der DNS-Server im Internet den nur intern bekannten Namen nicht auflösen kann. IPSec stellt lediglich eine gesicherte IP-Verbindung her - um Namensauflösung hat sich der Administrator selbst zu kümmern. Bei der Kopplung ganzer Netze empfiehlt es sich, auf beiden Seiten einen DNS-Server so einzurichten, dass er als "Secondary" den Datenbestand des anderen spiegelt und damit auch DNS-Anfragen nach Rechnern im entfernten Netz beantworten kann.

Für den Road Warrior mit dem Notebook im Hotel ist ein eigener DNS-Server natürlich Overkill. Er kann jedoch beim Einrichten des VPN-Zugangs alle benötigten Rechner und deren IP-Adressen in die Datei c:\windows\system32\etc\hosts eintragen (unter Linux /etc/hosts). Damit klappt die Namensauflösung unabhängig vom DNS.

Das gleiche gilt für die Datei lmhosts im selben Verzeichnis, die die Namen für Windows-Server bereitstellt. Damit lassen sich die Server über die Suchfunktion der Netzwerkumgebung oder über den net-Befehl auf der Kommandozeile ansprechen. Um einen externen Rechner voll in eine Windows Infrastruktur einzubinden, kann man in der Netzwerkumgebung einen Eintrag auf einen WINS-Server des Firmnenetzes eintragen (in der Netzwerkumgebung/Verbindung/Eigenschaften/Internetprotokoll/Erweitert). Dann sollte allerdings eine Firewall SMB-Broadcasts abfangen, damit diese nicht versehentlich nach außen gelangen.

Umsichtige Administratoren erstellen gleich Vorlagen für alle notwendigen Dateien. Diese können sie zusammen mit einer kurzen Anleitung über die zip- beziehungsweise tar-Anweisung in make_cert in das Archiv mit dem Zertifikat einfügen. Damit hat der Anwender gleich alle notwendigen Informationen für die Installation zur Hand.

Ist das VPN-Gateway einmal im Produktionsbetrieb, kann man FreeS/WAN nicht für jede Änderung oder neu eingetragene Verbindung neu starten und damit allen VPN-Nutzern die Verbindung kappen. Hier hilft das Kommandozeilen-Tool ipsec, das meist in /usr/local/sbin/ liegt.

ipsec auto --replace n2n

lädt eine Verbindungsbeschreibung neu. Weitere auto-Kommandos wie start, delete, status helfen bei der Administration.

ipsec barf > ipsec.txt 

schreibt alle relevanten Einstellungen in eine Datei. Überhaupt bieten FreeS/WAN und die X.509-Erweiterungen eine ganze Reihe zusätzlicher Optionen und Funktionen, die in dieser Anleitung zu kurz gekommen, aber in der Dokumentation gut beschrieben sind [2, 4].

Literatur

[1] Andreas Steffen, Eigener Schlüsseldienst, VPNs und Zertifikate im Eigenbau, c't 5/02, S. 220

[2] FreeS/WAN-Dokumentation

[3] Mac OS X und FreeS/WAN

[4] X.509-Dokumentation

[5] IPCop VPN-Howto

[6] IPSec-Tool für XP/2000

[7] Listings

IPSec mit IPCop

IPSec mit IPCop

Hinter der etwas spartanischen Fassade des Web-Frontends enthält IPCop ein vollwertiges FreeS/WAN mit X.509-Erweiterungen. Um sie zu nutzen, muss man allerdings auf der Kommandozeile einige Modifikationen am System vornehmen. Wer nicht direkt am IPCop-Rechner arbeiten kann - weil er beispielsweise nach der Installation Monitor und Tastatur abgeklemmt und den Router in den Schrank gestellt hat -, aktiviert dazu den SSH-Zugang.

IPCop legt alle Konfigurationsdateien unter /var/ipcop/ ab. In /etc/ liegen lediglich symbolische Links, die auf diese Dateien verweisen. Die Befehle

cd /etc
mkdir ipsec.old
mv ipsec.conf ipsec.secrets ipsec.old

räumen die Links aus dem Weg. Das Web-Frontend modifiziert lediglich die Vorlagen in /var/ipcop/, so dass man ungestört seine eigenen Konfigurationsdateien anlegen und bearbeiten kann.

cp ipsec.old/ipsec.conf ipsec.conf

schafft eine Vorlage, die man entsprechend der Anleitung in diesem Artikel modifizieren kann. Wer sich mit dem Unix-Editor vi nicht anfreunden kann, benutzt dazu den Wordstar-artigen joe. Nach dem Anlegen der Datei /etc/ipsec.secrets muss man deren Zugriffsrechte mit

chmod 0600 ipsec.secrets

noch richtig setzen. Abschließend kann man im Web-Frontend unter "VPN" den automatischen Start von FreeS/WAN beim Verbindungsaufbau aktivieren. Modifikationen an den ipchains-Paketfilterregeln, sind nicht erforderlich.

Die Mini-CA

Die über den Soft-Link erhältliche Skript-Sammlung erleichtert den Aufbau einer Certification Authority für VPNs. Vor dem Einsatz sollten Sie den Installationspfad und einige Voreinstellungen für die Namen der Zertifikate in openssl.cnf anpassen. Das Skript make_ca erstellt dann einige zusätzliche Verzeichnisse und das Root-Zertifikat zum Beglaubigen der VPN-Zertifikate.

make_cert erledigt mehrere Schritte auf einmal: Es erzeugt das Schlüsselpaar mit geheimem und öffentlichem Schlüssel, erstellt aus dem öffentlichen einen Zertifizierungs-Antrag und unterschreibt diesen auch gleich mit dem geheimen Schlüssel der Root-CA. Am Ende packt es alle benötigten Dateien in ein tgz- beziehungsweise zip-Archiv.

Alle darin enthaltenen sicherheitsrelevanten Daten sind durch eine Passphrase geschützt, so dass man diese Datei auch getrost per E-Mail versenden kann. Lediglich die Passphrase muss man über einen sicheren Weg - also beispielsweise via Telefon - übermitteln. Sie dient lediglich zum Auspacken der Schlüssel - nicht zur Authentifizierung gegenüber dem VPN-Gateway.

Die Host-Zertifikate sind jeweils ein Jahr gültig, danach müssen neue ausgestellt werden. Das Skript show_valid listet die Gültigkeitszeiträume aller signierten Zertifikate auf. Will man ein Zertifikat vor Ablauf seiner Gültigkeit sperren, erzeugt

openssl ca -revoke newcert/01.pem
./make_crl

eine Liste gesperrter Zertifikate (Certificate Revocation List, CRL) in crls/crl.pem, die dann nach /etc/ipsec.d/crls/ zu kopieren ist. Nach

ipsec auto --rereadcrls

weist FreeS/WAN Verbindungsversuche des ausgesperrten Nutzers ab. Der Einsatz solcher Widerrufslisten ist unter FreeS/WAN zwar optional, es ist jedoch sinnvoll, zumindest auf dem Gateway eine aktuelle CRL vorzuhalten.

Listings

Listing 1

Auf einem klassischen VPN-Firmen-Gateway benötigt man typischerweise die IPSec-Verbindungsbeschreibungen p2n (Peer to Network) und n2n (Network to Network).

  1 config setup
  2      interfaces=%defaultroute
  3      klipsdebug=none
  4      plutodebug=none
  5      plutoload=%search
  6      plutostart=%search
  7      uniqueids=yes
  8 
  9 conn %default
 10      keyingtries=1
 11      disablearrivalcheck=no
 12      # always use certificates
 13      authby=rsasig
 14      rightrsasigkey=%cert
 15      auto=add
 16      # lokaler Endpunkt (left)
 17      left=%defaultroute
 18      leftcert=GatewayCert.pem
 19      leftupdown=/usr/local/lib/ipsec/updown
 20 
 21 conn p2p
 22      right=%any
 23 
 24 conn p2n
 25      right=%any
 26      leftsubnet=10.0.0.0/8
 27 
 28 conn n2n
 29      right=%any
 30      rightsubnetwithin=192.168.0.0/16
 31      leftsubnet=10.0.0.0/8
 32 
 33 conn xp-n2n
 34      right=%any
 35      rightid="C=DE, L=Hannover, O=Heise Verlag, CN=ju@ct.heise.de"
 36      rightsubnet=192.168.1.2/32
 37      leftsubnet=10.0.0.0/8

Listing 2

Dieser Auszug aus ipsec.conf beschreibt eine Verbindung zwischen dem Netz eines Home-Office mit dem Firmen-LAN.

  1 conn linux-n2n
  2     auto=start
  3     left=%defaultroute
  4     leftcert=juCert.pem
  5     leftsubnet=192.168.111.0/24
  6     leftupdown=/usr/local/lib/ipsec/updown
  7     right=vpngateway.firma.com
  8     rightrasigkey=%cert
  9     rightid="C=DE, L=Hannover, O=Heise Verlag, CN=Test Gateway"
 10     rightsubnet=10.0.0.0/8

Listing 3

Ein Road Warrior mit Windows XP und Dial-up-Zugang zum Internet kann mit dieser Konfiguration auf das Firmennetz zugreifen.

  1 conn Win-p2n
  2     network=ras
  3     auto=start
  4     left=%any
  5     right=vpngateway.firma.com
  6     rightsubnet=10.0.0.0/8
  7     rightca="C=DE, L=Hannover, O=Heise Verlag, CN=Test CA"
  8     pfs=yes


(ju)