Wer einen Server im Internet betreibt muss heute einige Sicherheitsmaßnahmen treffen, damit das System nicht kompromittiert wird. Konkret bedeutet dieses, es darf nicht die Tür für jeden offen stehen. Dennoch gibt es aber Türchen die geöffnet sein müssen, damit die Services auf dem System erbracht und gemanged werden können. Ein VPN Tunnel in das heimische vertraute Netzwerk ist ein Schritt in die richtige Richtung.Die Situation ist wie folgt. Im heimischen Netzwer befindet sich für die Netzwerkadminisration ein IPCop Server. Dieser läuft entweder als dediziertes System oder wie bei mir virtualisiert auf einem zentralen VMWare ESXi Host. Der Linux Server im Internet soll über einen VPN Tunnel in das heimische Netzwerk angebunden werden. Dazu wird eine Konfiguration unter openvpn auf dem IPCop erzeugt und als Ergebnis kommt die Konfigurationsdatei mit dem entsprechenden .P12 File heraus.
Auf dem Linux Host wird ebenfalls das Paket openvpn installiert, die Konfigurationsdatei final angepasst (die IP/FQDN des IPCop Servers erreichbar im Internet) und schon kann man einen ersten Test machen. Durch den Aufruf von openvpn –config configFile.opvn und eingabe des Kennwortes wird der Tunnel aufgebaut. Nun sind 2 Dinge unschön an der Sache.
a) Das Terminalfenster ist nun blockiert, da der Aufruf jede weitere Eingabe verhindert. Die Shell befindet sich ja nun in dem ausgeführten openvpn.
b) Die Eingabe des Kennwortes hindert die automatische Herstellung der Verbindung. Eine Umleitung einer Datei mit dem Kennwort in den Aufruf schlägt übrigens fehl. (openvpn –config configFile.opvn < password.txt)
Folgender Lösungsansätze gibt es nun.
a) Der Aufruf des Verbindungsaufbaus erfolgt als Service und wird in den Hintergrund des Servers verlagert. Beispeilsweise beim Start des Systems. Beim start wird das kennwort eingegeben und danach vertrau man einfach auf den Reconnect Mechanismus von openVPN (Nicht gerade eine gute Lösung)
b) Irgendenein Automatismus wird die erwartete Eingabe des Kennwortes machen und etwas Monitoring der Leitung ist hilfreich.
Punkt B des Lösungsansatzes ist der entscheidende Punkt um eine wirkliche Automatisierung zu erreichen. Da eine Umleitung aus einer Datei hier nicht funktioniert muss also eine andere Lösung her. Ich verwende hierzu das Paket expect. Expect dient dazu Programme fernzusteuern und hat im wesentlichen 4 Befehle: spawn, expect, send und interact.
In einer Datei steht nun folgendes:
#!/usr/bin/expect
spawn /usr/sbin/openvpn –config /etc/openVPNTunnel/Strato-TO-IPCop.ovpn
send "*******n"
sleep 5
Das Kennwort wird jetzt nicht über eine Datei an das Skript übergeben, sondern expect macht das nun für uns. Und siehe da, nun klappt es auch voll automatisch. In dem Beispiel ist mein Kennwort natürlich durch die * ersetzt. Das n steht hier für die ENTER Taste.
Nun bleibt noch das starten des Tunnels. Eigentlich sollte der Tunnel aufgebaut werden sobald das System startet. Das erfolgt normalerweise in dem im entsprechenden Runlevel ein Script gestartet wird. Ich habe mich hier für eine andere Lösung entschieden. Ein weiteres Script prüft ob der Tunnel besteht. Wie auch immer dieser Test ausschaut kann beliebig kompliziert gemacht werden. Ping, IFCONFIG, Prozesse abfragen, … es gibt viele Wege und Entscheidungskriterien. Ich prüfe einfach ob in IFCONFIG die IP Adresse angezeigt wird. Ist dieses der Fall muss nichts gemacht werden. Ist dieses nicht der Fall wird das expect Script gestartet. Dieser Ansatz funktioniert dann auch, sollte der Prozess mal abstürzen.
In dem Skript selbst kann man nun viele Themen noch unterbringen die zur Entscheidung dienen und auch zur Dokumentation/ logging.
Fazit: Es gibt immer eine Lösung. Der Weg über Expect und das Monitoringscript für den VPN-Tunnel ist eine gute Basis um automatisiert den Tunnel aufzubauen und ggf. nachzustarten. Es gibt viele Postings im Internet zu openvpn und Thema Kennworteingabe. Leider habe ich keine gefunden die wie ich es gemacht habe auf expect basiert. Vielleicht ist es so einfach und jeder kennt es, das es nicht notwendig ist danach zu suchen. Sollte es dennoch jemand brauchen – hier ist es jetzt. Expect sollte eigentlich für alle gängigen Distributionen verfügbar sein.

Links:

imported from www2.georg-keller.eu