Diese Dokumentation bezieht sich auf Version 2.4.4 von Openswan, wie sie in aktuellen Distributionen zum Einsatz kommt.

Einleitung

Viele Appliaktionen sind nicht in der Lage, ihre Kommunikation zu verschlüsseln. Insbesondere wenn man das Internet als Transportmedium einsetzen möchte, ist eine Verschlüsselung unabdingbar (Stichwort: VPN).

In diesem Szenario sieht es wie folgt aus: Ein Netzwerk aus drei PCs (PC A, B und C), die alle mit einem Hub verbunden sind. Die PCs A und B möchten gesichert Daten austauschen ohne das PC C die Daten mitlauschen kann.

Weitere Daten:

• Netzwerk-Definition: 192.168.100.0/24
• PC A: 192.168.100.10
• PC B: 192.168.100.20
• PC C: 192.168.100.30

Hinweis: Hier werden lediglich Host-Host-Verbindungen erläutert.

Voraussetzungen

Als Distribution und Grundlage setzen wir einen Server mit OpenSuSE Linux 10.1 ein.

Die weiteren Software-Komponenten:

• Linux Openswan 2.4.4 (mitgeliefert bei OpenSuSE 10.1, Paket openswan muss zur Installation markiert werden)

Navigation

Die SuSE-Installation legt automatisch Schlüssel für die Verschlüsselung an (findet man unter /etc/ipsec.secrets). Die Definition von verschlüsselten Verbindungen finden sich in der Datei /etc/ipsec.conf.

Mittels /etc/init.d/ipsec start bzw. /etc/init.d/ipsec stop startet bzw. beendet man den IPsec-Dienst.

Danach kann man eine Verbindung, die man in der Konfigurationsdatei /etc/ipsec.conf definiert hat, mittels ipsec auto --add pc-a2b dem "Verbindungspool" hinzufügen, um sie danach mittels ipsec auto --up pc-a2b zu starten. Wichtig ist dabei, dass auf beiden PCs die entsprechenden Dienste gestartet, als auch die entsprechenden Verbindungen bekannt gemacht wurden.

Prinzipiell wird bei der Verschlüsselung bzw. deren Definition immer von left und right gesprochen. Damit sind einfach die zu verbindenden Kommunikationspartner gemeint. In unserem Beispiel steht quasi der PC A für left und PC B für right.

Neuen Host-Key erstellen

Möchte man für den Host einen neuen Key erzeugen (für den Fall, dass ein Dritter unautorisiert an den Key gekommen ist), setzt man als root folgendes Kommando ein (vorher bestehende Datei /etc/ipsec.secrets sichern und dann löschen):

ipsec newhostkey --output /etc/ipsec.secrets

Damit werden neue Schlüssel generiert und in der angegebenen Datei /etc/ipsec.secrets abgelegt. Hinweis: Der Vorgang dauert ein kleines Weilchen.

Danach sollte man unbedingt sicher stellen, dass nur der Administrator die entsprechende Datei lesen kann:

chown root:root /etc/ipsec.secrets
chmod 600 /etc/ipsec.secrets

Natürlich müssen Kommunikationspartner von der Änderung der Keys erfahren, da ansonsten keine Kommunikation mehr möglich ist.

Konfiguration PC A und B

Hinweis: Es ist auf korrekte Einrückung und Zeilenabstände der Konfigurations-Schlüsselwörter zu achten!!!

Hier nun die jeweiligen Konfigurationen der teilnehmenden PCs:

# /etc/ipsec.conf - Openswan IPsec configuration file

# Configuration for PC-A, 28. Mai 2006, rOger Eisenecher
version 2.0

config setup
  interfaces=%defaultroute

conn pc-a2b
  auto=add
  authby=rsasig
  left=%defaultroute
  leftid=@pc-a.icer.local
  leftrsasigkey=0sAQPSAl4VOqiXxx...

  right=pc-b.icer.local
  rightid=@pc-b.icer.local
  rightrsasigkey=0sAQOpbNIqxJumq... 

...und PC B:

# /etc/ipsec.conf - Openswan IPsec configuration file

# Configuration for PC-B, 28. Mai 2006, rOger Eisenecher
version 2.0

config setup
  interfaces=%defaultroute

conn pc-b2a

  auto=add
  authby=rsasig
  left=pc-a.icer.local
  leftid=@pc-a.icer.local
  leftrsasigkey=0sAQPSAl4VOqiXxx...
  right=%defaultroute
  rightid=@pc-b.icer.local
  rightrsasigkey=0sAQOpbNIqxJumq...

Nun die einzelnen Einträge etwas erläutert (Erläuterungen beziehen sich auf die erste Konfigurationsdatei, gilt für die zweite analog):

• version 2.0: Standard-Abschnitt, immer notwendig. Teilt dem Dienst mit, dass es sich um eine Konfigurationsdatei Version 2 handelt.
• config setup: Standard-Abschnitt, immer notwendig
• interfaces=%defaultroute: Damit wird die Schnittstelle definiert, über die die verschlüsselten Daten gesendet werden.
• conn pc-a2b: Verbindungsdefinition.
• auto=start: Was soll beim Start des IPsec-Dienstes gemacht werden (start entspricht "Starten" beim "Start").
• authby=rsasig: Wie soll Verbindung authentifiziert werden (rsasig entspricht Authentifizierung mittels RSA Signatur).
• left=%defaultroute: offizielle IP-Adresse des linken Teilnehmers. Falls der Wert %defaultroute gesetzt wird, wird die Adresse automatisch durch IPsec gesetzt.
• leftid=@pc-a.icer.local: Identifikation des linken Teilnehmers für die Authentifikation. Mittels dem Zeichen @ kann man einen FQDN angeben.
• leftrsasigkey=0sAQPSAl4VOqiXxx...: RSA Signatur des linken Teilnehmers.
  Hinweis: Die Signatur ist hier wesentlich verkürzt aufgeführt.

Für die Einträge, die mit right beginnen, gilt dasselbe wie für die entsprechenden Einträge mit left.

Die RSA Signatur wird auf dem linken System wie folgt extrahiert:

ipsec showhostkey --left

Die Signatur muss nun entsprechend in der Datei /etc/ipsec.conf eingetragen werden. Analog geht man für die Signatur auf dem rechten System vor.

Starten von IPsec

Nach dem Erstellen der notwendigen Konfigurationsdateien gilt es, den IPsec-Dienst zu starten. Dies erfolgt mittels /etc/init.d/ipsec start. Man sollte etwa folgende Ausgaben sehen:

ipsec_setup: Starting Openswan IPsec 2.4.4...
ipsec_setup: insmod /lib/modules/2.6.16.13-4-default/kernel/net/key/af_key...
ipsec_setup: insmod /lib/modules/2.6.16.13-4-default/kernel/net/ipv4/ah4.ko
ipsec_setup: insmod /lib/modules/2.6.16.13-4-default/kernel/net/ipv4/esp4.ko
ipsec_setup: insmod /lib/modules/2.6.16.13-4-default/kernel/net/ipv4/ipcom...
ipsec_setup: insmod /lib/modules/2.6.16.13-4-default/kernel/net/ipv4/xfrm4...
ipsec_setup: insmod /lib/modules/2.6.16.13-4-default/kernel/net/xfrm/xfrm_...
ipsec_setup: insmod /lib/modules/2.6.16.13-4-default/kernel/crypto/sha1.ko
ipsec_setup: insmod /lib/modules/2.6.16.13-4-default/kernel/crypto/aes.ko
                                                                     done 

Wichtig ist insbesondere das abschliessende done. Als Kontrolle sollte man in der Datei /var/log/messages Einträge wie unten angegeben vorfinden:

May 28 16:55:54 pc-a ipsec__plutorun: Starting Pluto subsystem...
May 28 16:55:55 pc-a pluto[3766]: Starting Pluto (Openswan Version 2.4.4 X...
May 28 16:55:55 pc-a pluto[3766]: Setting NAT-Traversal port-4500 floating...
May 28 16:55:55 pc-a pluto[3766]:    port floating activation criteria nat...
May 28 16:55:55 pc-a pluto[3766]:   including NAT-Traversal patch (Version...
May 28 16:55:55 pc-a pluto[3766]: ike_alg_register_enc(): Activating OAKLE...
May 28 16:55:55 pc-a pluto[3766]: starting up 1 cryptographic helpers
May 28 16:55:55 pc-a pluto[3766]: started helper pid=3776 (fd:6)
May 28 16:55:55 pc-a pluto[3766]: Using Linux 2.6 IPsec interface code on ...
May 28 16:55:55 pc-a pluto[3766]: Changing to directory '/etc/ipsec.d/cace...
May 28 16:55:55 pc-a pluto[3766]: Could not change to directory '/etc/ipse...
May 28 16:55:55 pc-a pluto[3766]: Could not change to directory '/etc/ipse...
May 28 16:55:55 pc-a pluto[3766]: Changing to directory '/etc/ipsec.d/crls'
May 28 16:55:55 pc-a pluto[3766]:   Warning: empty directory
May 28 16:55:55 pc-a pluto[3766]: added connection description "packetdefa...
May 28 16:55:55 pc-a pluto[3766]: added connection description "block"
May 28 16:55:55 pc-a pluto[3766]: added connection description "clear-or-p...
May 28 16:55:56 pc-a pluto[3766]: added connection description "clear"
May 28 16:55:56 pc-a pluto[3766]: added connection description "private-or...
May 28 16:55:56 pc-a pluto[3766]: added connection description "private"
May 28 16:55:57 pc-a pluto[3766]: listening for IKE messages
May 28 16:55:57 pc-a pluto[3766]: adding interface eth1/eth1 ...
May 28 16:55:57 pc-a pluto[3766]: adding interface lo/lo 127.0.0.1:500
May 28 16:55:57 pc-a pluto[3766]: adding interface lo/lo ::1:500
May 28 16:55:57 pc-a pluto[3766]: loading secrets from "/etc/ipsec.secrets"
May 28 16:55:57 pc-a pluto[3766]: loading group "/etc/ipsec.d/policies/pri...
May 28 16:55:57 pc-a pluto[3766]: loading group "/etc/ipsec.d/policies/pri...
May 28 16:55:57 pc-a pluto[3766]: loading group "/etc/ipsec.d/policies/clear"
May 28 16:55:57 pc-a pluto[3766]: loading group "/etc/ipsec.d/policies/cle...
May 28 16:55:57 pc-a pluto[3766]: loading group "/etc/ipsec.d/policies/blo...

Damit ist gewährleistet, dass der Dienst erfolgreich gestartet ist (Vergleiche oben die Fett markierte Zeile).

Aufbauen der gesicherten Verbindung

Nun läuft der IPsec-Dienst; jetzt muss nur noch die verschlüsselte Verbindung hergestellt werden. Dies geschieht mittels dem Starten der definierten IPsec-Verbindung auf der einen Seite (z.B. left).

z.B. auf PC A:

ipsec auto --up pc-a2b

Nun sollte folgende Ausgabe sichtbar sein:

104 "pc-a2b" #1: STATE_MAIN_I1: initiate
003 "pc-a2b" #1: received Vendor ID payload [Openswan (this version) 2.4.4...
003 "pc-a2b" #1: received Vendor ID payload [Dead Peer Detection]
106 "pc-a2b" #1: STATE_MAIN_I2: sent MI2, expecting MR2
108 "pc-a2b" #1: STATE_MAIN_I3: sent MI3, expecting MR3
004 "pc-a2b" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_RSA_SIG...
117 "pc-a2b" #2: STATE_QUICK_I1: initiate
004 "pc-a2b" #2: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0x26...

Damit ist die gesicherte Verbindung zwischen den PCs hergestellt.

Tools/Tests

Hier ein paar Hinweise, wie man die Verbindung prüfen kann bzw. nachweisen kann, dass die Verbindung auch verschlüsselt wird.

Damit man mit einem Netzwerk-Sniffer auch sehen kann, dass Daten verschlüsselt verschickt werden, kann man dem Befehl ping auffordern, ein bestimmtes Muster als Payload zu senden:

ping -p deadbeef 192.168.100.10

Mittels dem Tool tcpdump können Datenpakete aufgezeichnet werden. Für einfache Tests bietet sich folgendes an:

tcpdump -i eth0 -n -x host 192.168.100.10 and not port ssh

Damit werden alle Pakete ausgegeben, die nicht durch eine SSH-Verbindung verursacht wurden.

Natürlich kann auch ein grafisches Tools zur Analyse herangezogen werden: ethereal. Gibt es auch als Windows-Version ;-)

Troubleshooting

Offenbar gab es ein Problem. Hier finden sich ein paar Tips, wie man Fehlern auf die Spur kommen kann.

Einer der wichtigsten Grundsätze ist das beidseitige beenden des IPsec-Dienstes (/etc/init.d/ipsec stop).

Fehlermeldung: 021 no connection named "name"

Es wurde versucht, ein Kommando der Art ipsec auto --up "name" auszuführen. Die Fehlermeldung besagt, dass die Verbindung noch nicht dem "Verbindungs-Pool" hinzugefügt wurde (mittels ipsec auto --add "name". Man sollte prüfen, ob man den Namen der Verbindung korrekt angegeben hat und ob die Verbindung dem Pool hinzugefügt wurde.

Ein weiterer Grund dafür könnte sein, dass in der Datei ipsec.conf für die Zielpunkte der gesicherten Verbindung Namen angegeben wurden, die nicht aufgelöst werden können. In diesem Fall findet sich in der Log-Datei /var/log/messages ein Eintrag der folgenden Form:

May 28 18:52:37 pc-a ipsec__plutorun: whack error: "pc-a2b" does not look   \
                 numeric and name lookup failed "pc-b.planet-express.private"
May 28 18:52:37 pc-a ipsec__plutorun: ...could not add conn "pc-a2b"

Abhilfe schafft das Eintragen konkreter IP-Adressen.

Fehlermeldung: we require peer to have ID '@<fqdn>', but peer declares '<ip>'

Die Konfigurations-Dateien scheinen auf der Seite left und right nicht überein zu stimmen. Abhilfe schafft das prüfen der entsprechenden Konfigurationsdateien.

(Alt) Fehlermeldung: ipsec showhostkey: multiple default keys found!?!

ipsec hat festgestellt, dass offenbar mehrere gleiche Keys in der Datei /etc/ipsec.secrets gefunden wurden. Abhilfe schafft das Entfernen der doppelten Keys oder falls man nur eine Verbindung hat, das Löschen der entsprechenden Datei und das Neu-Erzeugen der Datei gemäss Abschnitt "Neuen Host-Key erstellen".

(Alt) Fehlermeldung: did not find conn section(s) "name"

Wahrscheinlich wurde versucht, ein Kommando der Art ipsec auto --add "name" auszuführen. Die Fehlermeldung besagt, dass in der Datei ipsec.conf kein Eintrag mit dem Namen "name" gefunden werden konnte. Man sollte prüfen, ob man den Namen der Verbindung korrekt angegeben hat.

(Alt) Fehlermeldung: no default route, %defaultroute cannot cope!

Damit man in der Datei ipsec.conf den Parameter %defaultroute benutzen kann, muss ein Standard-Gateway definiert sein. FreeS/WAN versucht dann anhand dieser Angaben automatisch die Schnittstelle zu ermitteln, die für den Versand der verschlüsselten Daten benutzt wird. Die Alternative besteht darin, dass man anstatt der automatischen Bestimmung der Schnittstelle diese vorschreibt. Ein entsprechender Eintrag könnte wie folgt aussehen:

config setup
  interfaces="ipsec0=eth0"

(Alt) Fehlermeldung: fatal error in "name": %defaultroute requested but not known

Damit man in der Datei ipsec.conf den Parameter %defaultroute benutzen kann, muss ein Standard-Gateway definiert sein. FreeS/WAN versucht dann anhand dieser Angaben automatisch die Schnittstelle zu ermitteln, die für den Versand der verschlüsselten Daten benutzt wird und bestimmt auch automatisch den Wert für die Parameter left bzw. right, wenn man dort %defaultroute angegeben hat. Die Alternative besteht darin, dass man die IP fix angibt:

# /etc/ipsec.conf - FreeS/WAN IPsec configuration file

# Configuration for PC-A, 11. Juni 2003, Roger Eisenecher

config setup
  interfaces="ipsec0=eth0"

conn pc-a2b
  auto=start
  authby=rsasig
  left=192.168.100.10
  leftid=192.168.100.10
  leftrsasigkey=0sAQPSAl4VOqiXxx...
  right=192.168.100.20

  rightid=192.168.100.20
  rightrsasigkey=0sAQOpbNIqxJumq... 

Natürlich muss die Datei ipsec.conf auch beim Kommunikationspartner angepasst werden.

(Alt) Fehlermeldung: "name" does not look numeric and name lookup failed "FQDN"

Ein weiterer Knackpunkt stellt die Namensauflösung der Kommunikationspartner dar. Das aufgeführte Beispiel geht davon aus, dass eine Namensauflösung stattfinden kann (normalerweise mittels DNS).

Verfügt man über keine funktionierende Namesauflösung, muss man statt den Namen der Kommunikationspartner deren IP-Adressen einsetzen. Hier die geänderte Datei ipsec.conf exemplarisch für PC A:

# /etc/ipsec.conf - FreeS/WAN IPsec configuration file

# Configuration for PC-A, 11. Juni 2003, Roger Eisenecher

config setup
  interfaces=%defaultroute

conn pc-a2b
  auto=start
  authby=rsasig
  left=%defaultroute

  leftid=192.168.100.10
  leftrsasigkey=0sAQPSAl4VOqiXxx...
  right=192.168.100.20
  rightid=192.168.100.20
  rightrsasigkey=0sAQOpbNIqxJumq... 

Natürlich muss die Datei ipsec.conf auch beim Kommunikationspartner angepasst werden.

Was kann man noch prüfen?

Nun sollte man prüfen, ob der IPsec-Dienst gestartet ist. Dazu muss man die Log-Datei /var/log/messages prüfen, ob folgende Zeilen vorkommen:

May 28 16:55:54 pc-a ipsec__plutorun: Starting Pluto subsystem...
May 28 16:55:55 pc-a pluto[3766]: Starting Pluto (Openswan Version 2.4.4 X...
May 28 16:55:55 pc-a pluto[3766]: Setting NAT-Traversal port-4500 floating...
May 28 16:55:55 pc-a pluto[3766]:    port floating activation criteria nat...
May 28 16:55:55 pc-a pluto[3766]:   including NAT-Traversal patch (Version...
May 28 16:55:55 pc-a pluto[3766]: ike_alg_register_enc(): Activating OAKLE...
May 28 16:55:55 pc-a pluto[3766]: starting up 1 cryptographic helpers
May 28 16:55:55 pc-a pluto[3766]: started helper pid=3776 (fd:6)
May 28 16:55:55 pc-a pluto[3766]: Using Linux 2.6 IPsec interface code on ...
May 28 16:55:55 pc-a pluto[3766]: Changing to directory '/etc/ipsec.d/cace...
May 28 16:55:55 pc-a pluto[3766]: Could not change to directory '/etc/ipse...
May 28 16:55:55 pc-a pluto[3766]: Could not change to directory '/etc/ipse...
May 28 16:55:55 pc-a pluto[3766]: Changing to directory '/etc/ipsec.d/crls'
May 28 16:55:55 pc-a pluto[3766]:   Warning: empty directory
May 28 16:55:55 pc-a pluto[3766]: added connection description "packetdefa...
May 28 16:55:55 pc-a pluto[3766]: added connection description "block"
May 28 16:55:55 pc-a pluto[3766]: added connection description "clear-or-p...
May 28 16:55:56 pc-a pluto[3766]: added connection description "clear"
May 28 16:55:56 pc-a pluto[3766]: added connection description "private-or...
May 28 16:55:56 pc-a pluto[3766]: added connection description "private"
May 28 16:55:57 pc-a pluto[3766]: listening for IKE messages
May 28 16:55:57 pc-a pluto[3766]: adding interface eth1/eth1 ...
May 28 16:55:57 pc-a pluto[3766]: adding interface lo/lo 127.0.0.1:500
May 28 16:55:57 pc-a pluto[3766]: adding interface lo/lo ::1:500
May 28 16:55:57 pc-a pluto[3766]: loading secrets from "/etc/ipsec.secrets"
May 28 16:55:57 pc-a pluto[3766]: loading group "/etc/ipsec.d/policies/pri...
May 28 16:55:57 pc-a pluto[3766]: loading group "/etc/ipsec.d/policies/pri...
May 28 16:55:57 pc-a pluto[3766]: loading group "/etc/ipsec.d/policies/clear"
May 28 16:55:57 pc-a pluto[3766]: loading group "/etc/ipsec.d/policies/cle...
May 28 16:55:57 pc-a pluto[3766]: loading group "/etc/ipsec.d/policies/blo...

Hat es soweit geklappt, dann sollte man die Signaturen bzw. die weiteren Einstellungen in der Datei /etc/ipsec.conf prüfen.

Nun sollte eigentlich der verschlüsselten Verbindung nichts mehr im Wege stehen.

Weitere Infos

• Lokale Infos: man ipsec.conf und man ipsec.secrets
• Homepage von Openswan(external link)
• Homepage von tcpdump(external link)
• Homepage von Wireshark(external link) (ehemals Ethereal)