VPN für Arme

Ob Projekt mit überall auf der Welt sitzenden Mitarbeitern, virtuelle Firma oder Pärchen mit getrennten Wohnorten – seit das Internet es möglich macht, von überall her auf gemeinsame Rechner zuzugreifen, liegt die Idee eines virtuellen lokalen Netzwerks nahe: Nicht mehr die räumliche Nähe einer Büro- oder Wohngemeinschaft bestimmt die Grenzen des LANs, sondern die Zugehörigkeit zu einem Team. Doch solche "lokalen" Netze, bei denen das Internet die Aufgabe des Netzwerkkabels übernimmt, müssen abgesichert werden, damit die darüber übertragenen Daten tatsächlich privat bleiben. Das geht mit Hilfe eines Tunnels: Vom Internet aus ist nur die äußere Tunnelhülle sichtbar, die darin fließenden Daten bekommen lediglich die Rechner an den Endpunkten desselben zu Gesicht.

Mit vpn-pppssh von [1] oder der Heft-CD existiert eine skriptbasierte Möglichkeit, ein solches virtuelles privates Netzwerk (VPN) aufzusetzen. Ihr Vorteil: Sie verwendet ausschließlich Software, die ohnehin auf jedem Linux-Rechner vorhanden ist. Eine einzige Befehlszeile im Skript reicht aus, um den VPN-Tunnel aufzubauen. Der restliche Code sorgt für etwas Komfort und das richtige Routing der Datenpakete.

Für die zuverlässige Verschlüsselung der Daten auf dem Weg durch's Internet sorgt die auf Seite 81 ff. vorgestellte Secure Shell ssh [2]; das "Point-to-Point-Protokoll" PPP sorgt dafür, dass alle möglichen Netzwerk-Basis-Protokolle wie TCP, UDP, ICMP und sogar IPX den VPN-Tunnel passieren können (vgl. Kasten 1).

Trotz ihrer Einfachheit beschränkt sich diese Lösung nicht darauf, zwei Standorte miteinander zu verbinden. Mit etwas Zusatzaufwand lassen sich auch zwei oder drei Einzelnetzwerke oder Rechner zu einem großen virtuellen Netz zusammenschließen.

Natürlich hat solch eine Simpelstlösung auch Nachteile. So "repariert" sich die Verbindung nach einem unerwarteten Verbindungsabbruch nicht automatisch. Auch liegt die erreichbare Datenrate unterhalb des bei einer DSL-Verbindung zu erwartenden Werts: Jedes ins andere Teilnetz übertragene Datenpaket wird in ein anderes Datenpaket eingepackt, was den Overhead erhöht. Daher sollte man mit dieser doch sehr einfachen Methode nicht allzuviele Netze verbinden: Mit jedem weiteren Knoten sinkt die Zuverlässigkeit der Verbindung, und ab einer bestimmten Grenze nehmen die Verbindungsabbrüche derart überhand, dass das VPN kaum noch ernsthaft benutzbar bleibt.

Das Szenario

Ob Sie jetzt zwei Wohngemeinschaften mit internem Netzwerk, Windows- und Linux-Rechnern sowie einem DSL-Zugang ins Internet verbinden, das Wort "Wohngemeinschaft" gegen "Firmensitz" oder ähnliches ersetzen, ist dabei in der Praxis egal: Es kommt nur auf die Technik an.

Abbildung 1: Einfacher VPN-Tunnel mit DSL-Verbindung zum Intranet

Der leistungsfähigere Gateway-Rechner übernimmt dabei die Aufgabe des Servers am Tunnelende, der leistungsschwächere bekommt die Rolle des Client zugeteilt. In unserem in Abbildung 1 skizzierten Beispiel zweier WGs hat der Rechner in Haus 2 einen besseren Prozessor als die Gegenstelle in Haus 5, womit die Rollenverteilung fest steht: Haus 2 hostet den Server.

vpn-pppssh als Shell-Skript ruft einige Programme auf, die zusätzlich installiert sein müssen. Dazu gehört besagte Secure Shell, die den Datentunnel aufbaut und für die verschlüsselte Übertragung der Pakete durch's Internet sorgt. Als Transportprogramm kommt der pppd zum Einsatz. Sowohl das SSH-Paket, als auch der PPP-Daemon müssen auf beiden Rechnern am Tunnel installiert sein, damit eine Kommunikation mit dem jeweils anderen Ende des Tunnels zustande kommt.

Um auf dem Server für ein Mindestmaß an Sicherheit gegenüber der angeschlossenen Clients zu sorgen, sollten VPN-Anforderungen von einem eigens dafür zuständigen System-Account ohne besondere Privilegien bearbeitet werden. Doch auch wenn sich das auf dem Client noch abzulegende VPN-Skript auf dem Server nicht als root anmeldet, benötigen einzelne, nach dem Login gestartete Prozesse (namentlich der pppd) doch Superuser-Berechtigungen. Aus dieser Zwickmühle hilft das Programm sudo. Sind ssh und pppd auf beiden Maschinen und auf dem Server, also dem Internet-Gateway-Rechner in Haus 2, zusätzlich noch sudo installiert, geht es an die Konfiguration des VPNs.

Arbeitstier

Den unprivilegierten User vpn, in dessen Namen sich das VPN-Skript auf dem Server einloggt, erzeugt man als root auf dem Server mit folgendem Kommandozeilen-Befehl:

adduser --system --shell /bin/bash --gecos "VPN Account"  --disabled-password --group vpn

Damit vpn den pppd im Skript per sudo aufrufen darf, muss der Server-Sysadmin aus Haus 2 dies in der sudo-Konfigurationsdatei /etc/sudoers extra erlauben. Diese Datei editiert er mit dem Befehl visudo. Durch diesen Aufruf startet der in der Umgebungsvariablen EDITOR oder VISUAL festgelegte Texteditor. Sehr wahrscheinlich ist dies der vi. Ihn schaltet man ggf. mit der Taste [i] in den Einfügemodus, schreibt die beiden folgenden Zeilen hinein, und beendet ihn anschließend mit [Esc] :wq:

vpn ALL=NOPASSWD:/usr/sbin/pppd
vpn ALL=NOPASSWD:/sbin/route

Die zweite Zeile erlaubt es vpn, mit Hilfe des Programms /sbin/route die Routing-Tabelle zu ändern.

Müsste man bei jedem Verbindungsaufbau zum Server das Login-Passwort für vpn von Hand eingeben, ginge das am Ziel des automatisierten VPN-Aufbaus vollkommen vorbei. Deswegen kommt statt der Passwortabfrage eine alternative Möglichkeit der Authentifizierung zur Anwendung, das Public-Key-Verfahren der Secure Shell. Versucht sich der Client auf dem Server einzuloggen, nimmt der dortige Secure-Shell-Daemon sshd den auf dem Server-Rechner hinterlegten öffentlichen Key des Clients. Damit verschlüsselt er eine kurze Nachricht und schickt sie an den Client zurück. Passt der auf dem Server abgelegte öffentliche Schlüssel zum privaten Key des Clients, ist dieser in der Lage, die "Challenge"-Nachricht ("Herausforderung") zu dechiffrieren. Er schickt dem Server einen Beleg dafür, worauf dieser einen kontrollierten, aber automatischen Login gestattet.

Liegt auf dem Client bislang kein Schlüsselpaar in den Dateien /root/.ssh/id_dsa und /root/.ssh/id_dsa.pub vor, muss eines mit dem Befehl ssh-keygen erzeugt werden (Listing 1). Der Parameter -t dsa legt die Verschlüsselungsmethode auf DSA fest. Auf die Frage nach der Passphrase antwortet man mit einem beherzten [Enter] nicht – sonst wäre bei jedem Verbindungsaufbau doch wieder ein Passwort fällig.

client:~# ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/root/.ssh/id_dsa):
Enter passphrase (empty for no passphrase): [Enter]
Enter same passphrase again: [Enter]
Your identification has been saved in /root/.ssh/id_dsa.
Your public key has been saved in /root/.ssh/id_dsa.pub.

Der öffentliche Schlüssel des gerade auf dem Client erzeugten Schlüsselpaares muss nun in den Schlüsselkatalog des Systemkontos vpn auf dem Server gebracht werden. Anders als zu erwarten, geht das nicht einfach durch Umkopieren der Datei /root/.ssh/id_dsa.pub vom Client nach /home/vpn/.ssh/authorized_keys auf dem Server!

In authorized_keys befinden sich unter Umständen sehr viele öffentliche Schlüssel anderer Rechner, dann nämlich, wenn ein Login per SSH-Public-Key-Verfahren von mehreren Rechnern aus erwünscht ist. Deswegen sollte man die Datei id_dsa.pub mit dem neu aufzunehmenden Schlüssel grundsätzlich zuerst auf den Server übertragen (hier bietet sich scp, ein USB-Stick oder auch eine Diskette an), um ihren Inhalt anschließend mittels cat an die Datei authorized_keys anzufügen:

cat /mnt/usb/id_dsa.pub >> /home/vpn/.ssh/authorized_keys