IPSec-Installation - FreeS/WAN
Hands-on VPN mit Linux und FreeS/WAN
Begleitete Installation, HTA Bern, 13. Juli 2002
Als 2. Teil unseres IPSec-Zyklus folgte dieser praktische Teil dem Theorievortrag vom April im Café Kairo.
Neu: Auch mit FreeBSD als Gateway/Firewall bekommt man eine sehr schöne Lösung. Hier ein Beitrag dazu.
Es ging jetzt darum, die verschiedenen theoretischen Ausführungen über IPSec und FreeS/WAN, die uns alle mehr oder weniger über die Funktionsweise der verschiedenen Sicherheits- und Verschlüsselungsprotokolle erleuchtet hatten, in die Tat umzusetzen (oder fachsprachlich ausgedrückt: "Vergiss, was Du gehört hast, und bring das Ding irgendwie zum Fliegen."). Ein/e jede/r sollte die Ausrüstung und zumindest eine vage Idee vom Wunsch-Setup mitbringen, und zusammen sollte das dann implementiert werden.
An der HTA Bern durften wir freundlicherweise wieder einen Raum als Labor verwenden - ein grosses Dankeschön an Tobias, der uns auch sonst mit Rat und Tat und Hardware zur Seite stand (man kann ja wohl von einem Haufen Informatiker nicht erwarten, dass sie wirklich alles Material dabeihaben, oder? Besonders so Nebensächlichkeiten wie Bildschirm, Tastatur oder Power-Kabel braucht man ja nicht ständig ... ;-)
Nachdem Mathias erfolgreich die verschiedenen Sicherheitseinstellungen von OpenBSD niedergekämpft hatte und unser Router einsatzbereit war, konnten wir loslegen. Das Setup sah mehrere Subnetze vor, die über IPSec-Gateways an ein gemeinsames Transportnetz angeschlossen waren und von dort aus weiter ins Internet. Die Verschlüsselung fand dabei zwischen den Clients und den Gateways statt. Ein solcher Client-Gateway-Tunnel macht wohl vor allem dann Sinn, wenn die Strecke zwischen den beiden unsicher ist, wie das z.B. bei Wireless-LAN-Verbindungen der Fall ist. Mit kleinen Änderungen lässt sich daraus aber auch eine Gateway-Gateway-Verbindung ableiten, die dann verschiedene Subnetze über ein unsicheres Transportnetz (z.B. Internet) miteinander verbindet.
Schema des Netzaufbaus am Event
Eine Besonderheit von FreeS/WAN ist es, dass auf Client und Gateway beinahe identische Konfigurationsdateien verwendet werden. Von diesen gibt es genau zwei,
nämlich /etc/ipsec.conf (die Hauptkonfiguration) und /etc/ipsec.secrets (hier werden die privaten, geheimen
Verbindungsparameter gespeichert).
Wir verwendeten zum Einstieg Pre-Shared Secrets (PSK) zur Authentisierung
der Rechner untereinander. Dank des X.509-Patches können aber auch X.509-Zertifikate
verwendet werden. Leider fehlte uns am Schluss die Zeit, auch das aufzusetzen
(und vor allem fehlte wohl Markus das nötige Fingerspitzengefühl im
Umgang mit openssl :-)
Wir haben folgende Versionen verwendet:
Der Patch- und Installationsprozess ist hier ausführlich beschrieben.
Bei anderen, früheren Versionen kann die Syntax der Konfigurationsdateien abweichen. Insbesondere haben frühere Versionen des X.509-Patches das Einlesen von Zertifikaten und Keys aus externen Dateien nicht unterstützt. Die Parameter mussten dort mit Hilfe eines besonderen Programms aus den Keys/Zertifikaten extrahiert und in der Konfiguration von Hand eingetragen werden.
Auf einem Client-Gateway-Paar sahen die Konfigurationen schliesslich wie folgt aus (Die Einrückungen müssen übrigens Tabs sein):
/etc/ipsec.conf
|
|
|---|---|
|
Client
config setup
|
|
| |
|
|
|
conn %default
Diese Sektion enthält die Parameter, die für alle Verbindungen gelten.
Wir haben die Defaults belassen. Alle Parameter in
*)
Per default wird | |
|
| |
|
|
|
|
|
|
|
|
|
/etc/ipsec.secrets
|
|
|---|---|
|
Client
192.168.1.5 192.168.1.1 : PSK "secret pw"
|
Gateway
%any 192.168.1.1 : PSK "secret pw"
|
|
Die Authentisierung der Hosts 192.168.1.5 (Client) und 192.168.1.1 (Gateway) untereinander erfolgt über ein geheimes Passwort ("Pre-Shared Secret", PSK). Dieses muss beiden Hosts bekannt sein. Das Secret dient dabei nur dem Aufbau eines ersten verschlüsselten Tunnels, über den dann die eigentlichen Verschlüsselungsparameter ("Security Association", SA) ausgehandelt werden. | |
|
|
|
Mit dem obigen Setup muss die Verbindung lugbe-out noch von
einer Seite initialisiert werden, da ja beide mit auto=add nur
auf Verbindungen warten. Am einfachsten geht das mit ipsec auto --up lugbe-out (auf dem Client). Danach gibt es einiges an Output. Wenn zuletzt so etwas steht
wie "SA established", war der Aufbau des IPSec-Tunnels erfolgreich.
Wenn es jetzt immer noch nicht funktioniert, liegt das Problem ziemlich sicher
am Routing. ipsec eroute gibt Auskunft über das Routing im
Tunnel, ipsec look zeigt die aktuellen Verbindungsparameter.
man ipsec schliesslich ist jetzt sonst wohl Dein bester Freund. IP-Forwarding muss übrigens beidseitig aktiviert werden (echo "1" > /proc/sys/net/ipv4/ip_forward)
... und jetzt das Ganze nochmal mit X.509-Zertifikaten
Das bisherige Setup funktioniert ohne den X.509-Patch. Um die Authentisierung der Hosts nicht mittels
Pre-Shared Secrets, sondern mit Zertifikaten zu machen, braucht man - neben
dem Patch - noch ein RSA-Schlüsselpaar im X.509-Format. Wie man dieses
erzeugt, ist schon oft beschrieben worden, unter anderem hier. Dort ist auch der ganze Setup
detailliert und verständlich beschrieben.
In unserem Beispiel ergäben sich folgende Änderungen:
/etc/ipsec.conf (mit X.509-Zertifikaten)
|
|
|---|---|
|
Client
conn %default
|
|
Sämtliche Parameter können, wie schon gesagt, auch in der jeweiligen | |
|
gegenüber anderen Hosts/Gateways authentisiert, liegt hier unter |
|
|
Wenn man das Zertifikat wie hier bei | |
rightid="C=CH, ST=BE, ..."
|
|
|
Der einfachste Fall ist, die Gegenseite
anhand des Subjects ihres Zertifikats zu erkennen. Aus dem Zertifikat kann
das Subject wie folgt extrahiert werden:
| |
/etc/ipsec.secrets (mit X.509-Zertifikaten)
|
|
|---|---|
|
Client
: RSA client.key ""
|
Gateway
: RSA gateway.key ""
|
|
Der private Teil des Schlüssels, Wundersamerweise funktionierte der Setup auf Anhieb. Was? Haben wir etwa Murphys Gesetz widerlegt? Nicht ganz. Immerhin fiel das anschliessend geplante Grillfest im Freien dem Regen zum Opfer - dafür konnten wir uns bis zu nachtschlafener Stunde von Marcs Kochkünsten und den Vorteilen von Gentoo Linux überzeugen. Hier noch ein paar Schnappschüsse von der Installation. Besonders deutlich zu erkennen sind die freien Plätze derjenigen, die sich zwar angemeldet, dann aber den weiten Weg zur HTA doch nicht gefunden hatten (Hint, Hint).
| ||||
Die Artikel dieser Seite stehen unter Copyleft ihrer jeweiligen Autor*innen. Ihre Nutzung, Wiedergabe etc. untersteht den Bedingungen der GNU Free Documentation License (http://www.gnu.org/copyleft/fdl.html), wo nicht explizit anders vermerkt.