blog/shl@INTERDOSE

zu Google.

Google

Wer von seiner preshared-key Infrastruktur weg möchte, dem sei gesagt: es geht auch viel schöner. Und wirklich so viel komplizierter ist dieser Weg auch nicht.

Leider sind gute Tutorials zu dieser Thematik recht selten, aber vielleicht hilft Euch ja das Folgende. Ich beziehe mich auf die aktuelle Version von OpenVPN aus Debian GNU/Linux. Das Prinzip ist allerdings bei jeder OpenVPN-Installation gleich.

Beginnen wir mit einem “leeren” Debian, und installieren als ersten Schritt die notwendigen Pakete.

apt-get update
apt-get install openvpn openssl

Debian wird den OpenVPN-Dienst direkt starten, welcher aber nicht wirklich weit kommen wird, daher beenden wir ihn per /etc/init.d/openvpn stop.

In /usr/share/doc/openvpn/examples/easy-rsa/2.0 finden wir die notwendigen Scripte um die Zerifikate für die Clients sowie den Server zu erstellen. Als erstes kopieren wir den Inhalt dieses Verzeichnises in /etc. (Wer noch kein Backup-System für /etc hat, dem sei etckeeper ans Herz gelegt – man sollte Backups machen. Wirklich.)

Die Datei vars enthält ein paar default Werte, die auf den persönlichen Geschmack geändert werden sollten, denn hier werden die Meta-Infos für die Zertifikate abgelegt. Sobald die Datei angepasst ist, den Inhalt “sourcen”.

. ./vars

Die zwei Punkte sind wichtig, kein Tippfehler. Da wir mit einer neuen Grund-Installation anfangen, übernimmt das Script clean-all etwas Aufräumarbeit für uns. Danach per

./build-ca

die Zertifizierungsstelle ins Leben rufen. Um bei vielen Zertifikaten nicht durcheinander zu kommen, empfiehlt es sich im Feld “common name” den FQDN des VPN-Servers oder ähnlich sinnvolle Inhalte anzugeben. Im nächsten Schritt erstellen wir das Server-Zertifikat, also das Zertifikat, welches später der OpenVPN-Dienst auf dem VPN-Server verwendet.

./build-key-server <Servername>

“common name” füllen wir wieder sinnvoll aus. Zeit den ersten Client-Schlüssel zu erstellen:

./build-key <Clientname>

Beim Client-Zertifikat soll sich bitte jeder selbst überlegen, ob ein “Challenge Password” Sinn ergibt oder nicht. Effektiv bedeutet das nichts anderes, als das der Benutzer ein Passwort eingeben muß um den Tunnel zu starten.

Als letzte Aktion vorerst, generieren wir noch die Diffie Hellman Parameter (nicht nachfragen – wer’s wirklich wissen will, Google hilft weiter.) und sind dann bereit für die OpenVPN-Config.

./build-dh

Im Unterverzeichnis keys finden sich nun die relavanten Dateien der Zertifkate, die wir an die richtige Stelle im Verzeichnisbaum kopieren.

cp ca.crt ca.key dh1024.pem <Servername>.crt <Servername>.key /etc/openvpn

Die Datei /etc/openvpn/openvpn.conf ist der nächste Schritt. Der Inhalt sollte in etwa so aussehen:

port 1194
proto tcp
dev tun
ca ca.crt
cert <Servername>.crt
key <Servername>.key
dh dh1024.pem
server 172.16.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
comp-lzo
user nobody
group users
persist-key
persist-tun
status openvpn-status.log
verb 3
client-to-client

Wer verhindern möchte, daß die verbundenen Clients miteinander kommunizieren können, entfernt die letzte Zeile. Die Zeile server 172.16.0.0 255.255.255.0 enthält das Range an IP-Adressen, die den VPN-Clients ausgegeben werden (recht ähnlich zu DHCP). Hier bitte natürlich ein valides Subnetz eintragen.

Mit /etc/init.d/openvpn start starten wir den OpenVPN-Dienst, und ein beherztes ifconfig bzw. ip ad sh sollte uns ein tun0 Interface zeigen.

Nun zum Client.

Die OpenVPN-Config des Clients sollte in etwa diesen Inhalt haben:

client
dev tun
proto tcp
remote <Servername> 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert <Clientname>.crt
key <Clientname>.key
comp-lzo
verb 3

Die Dateien ca.crt, <Clientname>.crt und <Clientname>.key müssen natürlich vorher vom Server auf den Client übertragen werden. Wenn der Client nun gestartet wird, sollte eine Verbindung zum VPN-Server aufgebaut werden. Falls nicht, Ruhe bewahren und Log-Dateien ansehen.

Was fehlt noch? Auf dem VPN-Server müssen wir noch IP-Routing aktivieren, um das VPN-Client Netz mit dem lokalen Netz zu verbinden. Auf Linux geht das recht simpel per:

echo 1 > /proc/sys/net/ipv4/ip_forward

Diese Zeile möchte man wohl in einem der init-Scripte oder im Firewall-Script verstecken, oder per post-up hook in der /etc/network/interfaces definieren.

Das war’s. Eigentlich einfach, oder? Soll ein weiteres Zertifikat für einen weiteren Client erstellt werden, einfach die Zeile ./build-key <Clientname> wiederholen. Es empfiehlt sich die Zertifikate nicht auf dem VPN-Server liegen zu lassen, also das ganze easy-rsa-Verzeichnis nach getaner Arbeit auf eine andere Maschine zu verschieben. Ebenfalls bitte regelmäßig Backups davon anfertigen.

Je nach Setup muß die Route in das VPN-Client Netz noch auf den anderen Maschinen gesetzt werden.

Auf Linux per route add -net 172.16.0.0/16 gw a.b.c.d und auf Windows per route -p add 172.16.0.0 mask 255.255.0.0 a.b.c.d.

Linux

Last year the former German AFS workshop turned into an European event. It got organized outside Germany in Graz, Austria. This year the meeting is hosted in Rome, Italy, and we would like to encourage participation from more than the German speaking countries.

… und wer würde nicht gerne mal nach Rom?

The workshop is mainly a platform for system administrators to exchange their knowledge and report use cases. Topics of interest include related technologies like Kerberos or LDAP and all supported operating systems.

Das Datum: 28. – 30. September 2009

Mehr Infos? Hier und hier.

Kerberos, LDAP, OpenAFS

Grade per Twitter erfahren.

The Debian Project is pleased to announce the official release of Debian GNU/Linux version 5.0 (codenamed Lenny) after 22 months of constant development.

[From Debian -- News -- Debian GNU/Linux 5.0 released ]

Wurde aber auch Zeit.

So lasset die Update-Orgien beginnen…

Linux