Datum
Kommentare Keine

Das Betreiben eines Servers hinter dem eigenen DSL- oder Kabel-Router ist normalerweise keine große Sache und dank integrierter Weboberflächen mit einigen Klicks erledigt. Komplizierter ist die Sache bei einem Anschluss, der im sog. Dual-Stack Lite (DS-Lite) läuft. Dabei handelt es sich um einen Anschluss, der nicht über eine öffentliche IPv4-Adresse erreichbar ist. Eine Möglichkeit ist es, das Gerät (den Server, das NAS o. ä.) so zu konfigurieren, dass es über IPv6 aus dem Internet erreichbar ist. Dafür muss es aber (ebenso wie der Router) IPv6-kompatibel sein, was auch heute noch nicht selbstverständlich ist. Auf der anderen Seite muss der Client ebenfalls IPv6 unterstützen (auch nicht selbstverständlich). Praktikabel ist der IPv6 Weg also (noch) nicht.

Als Ausweg gibt es diverse Portmapper, die für relativ viel Geld einzelne IPv6-fähige Geräte auf IPv4 Mappen, sodass diese über eine öffentliche IPv4-Adresse erreichbar sind. Zwei Nachteile wurden hierbei schon genannt: die Kosten sowie die Tatsache, dass sie IPv6-kompatibel sein müssen.

Eine flexiblere und in vielen Fällen auch günstigere Möglichkeit ist der Einsatz eines vServers: Dieser kann dazu genutzt werden, an ihn gestellte Anfragen zu einem per VPN verbundenen Server weiterzuleiten. Hierzu eignet sich hervorragend OpenVPN als einfach umzusetzende VPN-Lösung. Die Umleitung an den Server regelt hierbei ein kleines iptables-Skript. Das Prinzip hiervon verdeutlicht die folgende Zeichnung.

Da der vServer lediglich das VPN bereitstellen und Anfragen umleiten muss, ist der Ressourcenbedarf gering. Somit kommen auch minimal ausgestattete vServer in Frage, die es bereits ab wenigen Cent pro Tag (3 Cent aufwärts, oft prepaid) gemietet werden können.

OpenVPN-Konfiguration

Mit apt-get install openvpn installieren wir OpenVPN.

Erstellung der Zertifikate
Bevor wir uns aber an die eigentliche Konfiguration von OpenVPN machen, müssen wir uns um die Erstellung der nötigen Zertifikate kümmern. Hinweis: Idealserweise erfolgt aus Sicherheitsgründen die Erstellung von Zertifikaten auf einem separaten System, das nur für diesen Zweck genutzt wird.

Neben grafischen Lösungen zur Verwaltung von Zertifikaten (wie z. B. tinyca) bietet sich die easy-rsa-Skriptsammlung an, die unter Debian bei der Installation von OpenVPN unter /usr/share/doc/openvpn/examples/easy-rsa/2.0/ zu finden ist. Unter Ubuntu existiert ein eigenes Paket easy-rsa. Wir wechseln in das Verzeichnis von easy-rsa.

Erstellung der CA

  1. Anpassung der vars-Datei an die eigenene Bedürfnisse. Hier werden Standardwerte konfiguriert, die bei der Erstellung von Zertifikaten zum Einsatz kommen. Die Variable KEY_SIZE sollte auf jeden Fall auf 2048 gesetzt werden (der höhere Rechenaufwand ist selbst für moderne ARM-Boards vertretbar). Des Weiteren können noch die Gültigkeitsdauer der Certificate Authority (CA) und der eigentlichen Zertifikate sowie allgemeine Informationen zur CA (KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG und KEY_EMAIL) angegeben werden. Die weiteren Werte sind für uns nicht weiter interessant.
  2. Wir führen source ./vars zum Laden der eben angepassten Informationen aus.
  3. ./clean-all legt Dateien an, in denen Infos über erzeugte Zertifikate eingetragen werden. (Darf nach der Erstellung der CA auf keinen Fall mehr ausgeführt werden, da dies sonst sämtliche Zertifikate und Schlüssel löscht!)
  4. ./build-ca erzeugt schließlich die CA. Hierbei wird die Konfiguration von eben nochmal durchgegangen. Die meisten können mit Enter bestätigt werden, bei Organizational Unit Name, Common Name und Name kann z. B. CA eingetragen werden.

Erstellung des Server-Zertifikats
Zur Ausstellung von Nutzerzertifikaten brauchen wir ein Server-Zertifikat, mit dem unser OpenVPN-Server arbeiten wird. Dieses erstellen wir mit ./build-key-server openvpn.local. Statt openvpn.local tragen wir unseren Fully Qualified Domain Name (FQDN) ein, sofern denn eine Domain vorhanden ist (falls nicht, ist es auch nicht schlimm: OpenVPN funktioniert auch mit openvpn.local o. Ä.). Neben weiteren optionalen Angaben wird nach einem challenge password gefragt, das wir mit Enter bestätigen, da wir die Signierungs-Anfrage nicht an eine externe CA schicken, sondern jetzt gleich signieren: Sign the certificate? bestätigen wir mit y, ebenso wie die folgende Frage.

Nun erstellen wir mit ./build-dh einen Schlüssel für das Diffie-Hellmann-Verfahren, der sich anschließend in ./keys/dh2048.key befindet.

Im nächsten Schritt erstellen wir einen Pre Shared Key (PSK), der zusätzlich zur Authentifikation auf dem Server und allen Clients verteilt wird. Das wäre im Grund nicht zwingend nötig, verringert aber bei einer fehlgeschlagenen Authentifikation den Rechenaufwand und schwächt somit z. B. DoS-Attaken ab.
openvpn --genkey --secret ./keys/hmac.key

Erstellen des Nutzerzertifikats
Für die Nutzerzertifikate rufen wir einfach ./build-key servername auf — in unserem Fall für unseren Webserver z. B. ./build-key www. Wir beantworten wieder die gestellten Fragen entsprechend unserer Bedürfnisse, vergeben kein challenge password und lassen die Zertifikate signieren.

Jetzt haben wir sämtliche Zertifikate und Schlüssel, die wir brauchen:

  • openvpn.local.crt, openvpn.local.key und dh2048.key nutzen wir auf dem VPN-Server.
  • www.crt, www.key nutzen wir auf dem Webserver.
  • ca.crt hmac.key werden sowohl vom VPN-Server als auch vom Webserver genutzt.
  • Die csr-Dateien brauchen wir nicht mehr.

Server-Konfiguration von OpenVPN

Nehmen wir an, wir wollen OpenVPN über UDP / Port 2345 betreiben. Die OpenVPN-Konfigurationsdatei könnte dann z. B. wie folgt aussehen:

Server-IP: 10.1.2.1
/etc/openvpn/server.conf:


# Port, Layer-3-Kommunikation (TUN) und Protokoll konfigurieren
port 2345
dev tun
proto udp
topology subnet
# Adresspool des VPN-Servers
server 10.1.2.0 255.255.255.0
#
# Zertifikate und Schluessel
dh /etc/openvpn/keys/dh2048.pem
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/openvpn.local.crt
key /etc/openvpn/keys/openvpn.local.key
# TLS-Auth mit PSK (schwaecht DoS-Attaken ab)
tls-auth /etc/openvpn/keys/hmac.key
#
keepalive 10 60
# Komprimierung aktivieren
comp-lzo
persist-key
persist-tun
# nur Clients mit CCD-Konfiguration zulassen
client-config-dir /etc/openvpn/ccd
ccd-exclusive
#
# Logs und Log-Ausgabe-Level konfigurieren
status /var/log/openvpn/status.log
log-append /var/log/openvpn/openvpn.log
verb 3

Diese Konfiguration tragen wir in die Datei /etc/openvpn/server.conf ein. Unser VPN-Server nutzt die IP-Adresse 10.1.2.1 die eben erstellten Schlüssel- und Zertifikatsdateien kopieren wir, wie angegeben, in den Ordner /etc/openvpn/keys/.

Unter /etc/openvpn/ erstellen wir nun einen Ordner ccd, der als Client Config Dir bezeichnet wird und es ermöglicht, nur von den Clients eine Verbindung aufbauen zu lassen, die eine Datei mit ihrem Common Name im ccd-Verzeichnis besitzen.
Für unseren Webserver mit dem Common Name www kann dies z. B. wie folgt aussehen (/etc/openvpn/ccd/www):


ifconfig-push  10.1.2.2 255.255.255.0
push "topology subnet"

Dem Client wird also die IP-Adresse 10.1.2.2 zugewiesen.

Mit openvpn /etc/openvpn/server.conf sollte sich nun der VPN-Server starten lassen.

VPN-Konfiguration auf dem OpenVPN-Client

Auf dem Client legen wir eine Datei /etc/openvpn/client.ovpn mit folgendem Link an:


remote STATISCHEIP 2345
dev tun
proto udp
client
tun-mtu 1500
#
ca ca.crt
cert server.crt
key server.key
# PSK fuer TLS-Auth
tls-auth hmac.key
#
comp-lzo
verb 3

Den Platzhalter STATISCHEIP ersetzen wir durch die statische IP-Adresse unseres vServers. Die angegebenen Schlüssel- und Zertifikatsdateien kopieren wir in den selben Ordner, wie die ovpn-Datei.

Nun tragen wir in /etc/rc.local (überhalb von exit 0) noch folgendes ein:
cd /etc/openvpn && openvpn ./client.ovpn &.
Anschließend sollte bei einem Systemstart automatisch der Tunnel aufgebaut werden. Getestet werden kann dies mit openvpn /etc/openvpn/client.ovpn.

iptables-Konfiguration

Wenn der Aufbau des Tunnels funktioniert, müssen wir auf dem vServer noch die iptables-Konfiguration nachholen:

Das iptables-Skript leitet Anfragen an die Ports 80 (HTTP) und 443 (HTTPS) an den per VPN verbundenen Server weiter und kann leicht an die eigenen Bedürfnisse angepasst werden. Während der Arbeit am Skript ist bei einem Zugriff über SSH Vorsicht geboten, ansonsten ist es schnell passiert, dass man sich vom SSH-Zugang selbst aussperrt!

Zunächst wird einiges an “Vorarbeit” erledigt und kurzzeitig die Filterketten auf ACCEPT gesetzt, bis das Regelwerk formuliert wurde sowie ggf. schon vorhandene Regeln zurückgesetzt:


# temporaer Default Policy auf ACCEPT setzen und Filterketten zuruecksetzen:
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -F

Zudem wird das Loopback Interface (lo) von der Firewall-Konfiguration ausgeschlossen:

iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

Anschließend werden der SSH-Zugang und DNS sowie ggf. ICMP zugelassen:

# SSH zulassen
# Fuer alle IP-Adressen auf Port 22
# (kann zur Sicherheit weiter eingeschraenkt und auf einen anderen Port gestellt werden)
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -p tcp --sport 22 -j ACCEPT
#
# ICMP zulassen (z.B. fuer Ping)
# iptables -A OUTPUT -p icmp -j ACCEPT
# iptables -A INPUT -p icmp -j ACCEPT
#
# DNS zulassen
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -A INPUT -p udp --sport 53 -j ACCEPT

Nun werden Anfragen an OpenVPN zugelassen (der Interface-Name (venet0) muss entsprechend des auf dem vServer genutzten angepasst werden):

# OpenVPN zulassen
iptables -A OUTPUT -o venet0 -p udp --sport 2345 -j ACCEPT
iptables -A INPUT -i venet0 -p udp --dport 2345 -j ACCEPT

Im nächsten Schritt werden die umzuleitenden Dienste konfiguriert — in diesem Fall HTTP und HTTPS:

# HTTP zulassen
iptables -A FORWARD -d 10.1.2.2 -p tcp --dport 80 -j ACCEPT
iptables -A FORWARD -s 10.1.2.2 -p tcp --sport 80 -j ACCEPT
iptables -t nat -F PREROUTING
iptables -t nat -A PREROUTING -d STATISCHEIP -p tcp --dport 80 -j DNAT --to-destination 10.1.2.2
#
# HTTPS zulassen
iptables -A FORWARD -d 10.1.2.2 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -s 10.1.2.2 -p tcp --sport 443 -j ACCEPT
iptables -t nat -A PREROUTING -d STATISCHEIP -p tcp --dport 443 -j DNAT --to-destination 10.1.2.2

Danach müssen IP Forwarding und NAT aktiviert werden. Die folgenden auskommentierten Zeilen sind nur nötig, wenn der VPN-Server als Gateway für z. B. Systemupdates genutzt wird.

# Forwarding aktivieren
echo "1" > /proc/sys/net/ipv4/ip_forward
#
# NAT zulassen
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
# -----------------------
# Noetig, wenn VPN-Server als Gateway genutzt wird:
# Ausgehenden HTTP(S)-Datenverkehr erlauben (z. B. fuer Updates)
# iptables -A FORWARD -s 10.1.2.2 -p tcp --dport 80 -j ACCEPT
# iptables -A FORWARD -d 10.1.2.2 -p tcp --sport 80 -j ACCEPT
# iptables -A FORWARD -s 10.1.2.2 -p tcp --dport 443 -j ACCEPT
# iptables -A FORWARD -d 10.1.2.2 -p tcp --sport 443 -j ACCEPT
# iptables -A FORWARD -p icmp -j ACCEPT
# iptables -A FORWARD -p udp --dport 53 -j ACCEPT
# -----------------------

Abschließend erfolgt ein sehr wichtiger Schritt: Die Default Policy der Filterketten INPUT, FORWARD und OUTPUT wird auf DROP gesetzt und damit die Firewall-Funktion aktiviert:

# Default Policy auf DROP setzen
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

Nun muss das iptables-Regelwerk nur noch beim Serverstart automatisch geladen werden. Hierzu können wir uns einen Dienst anlegen; unter Debian reicht es aber auch aus, einen Eintrag in /etc/rc.local zu erstellen, der das Skript beim Systemstart ausführt: /etc/firewall.sh. Zusätzlich muss die Datei natürlich noch mit chmod u+x firewall.sh ausführbar gemacht werden.

Wenn bis hierin alles geklappt hat, ist nun der Webserver im lokalen Netz per IPv4-Adresse aus dem Internet erreichbar. Vielleicht noch ein kleiner Schönheitsfehler: Es fehlt nur noch ein Domain-Name, der auf unseren Server zeigt ;).

Autor

Datum
Kommentare Keine

Vor allem bei der Nutzung von offenen Hotspots (z. B. vom Freifunk-Netz) ist es interessant, seine Netzwerkverbindung über VPN abzusichern. So kann man sicherstellen, dass die eigenen Daten nicht unverschlüsselt übertragen und einfach mitgelesen werden können.

Bei Laptops ist das kein Problem, hier kann beispielsweise das einfach zu konfigurierende OpenVPN eingesetzt werden. Für Android existiert ebenfalls OpenVPN – im Gegensatz zu Windows Phone: Wer ein Smartphone von Microsoft sein Eigen nennt, ist bei der Nutzung von VPN deutlich eingeschränkter. IPsec wäre eine Möglichkeit, jedoch ist die Konfiguration eines IPsec-VPNs etwas aufwändiger und ein Windows Phone sehr wählerisch, wenn es um die zu nutzende IPsec-Variante geht (es wird z. B. nur IKEv2 unterstützt).

Seit Windows Phone 8.1 GDR1 wird die von Cisco stammende VPN-Variante AnyConnect unterstützt, mit der es möglich ist, eine VPN-Verbindung zu einem kompatiblen Cisco-Gerät herzustellen (bspw. Cisco ASA). Bei dieser Neuigkeit stieß ich auf das zu AnyConnect kompatible VPN-Projekt OpenConnect, das neben einem Client seit einiger Zeit auch einen Server (ocserv) umfasst. AnyConnect nutzt eine HTTPS-Verbindung (Standard: TCP auf Port 443) oder auch DTLS (Standard: UDP auf Port 443) und ist somit auch durch Firewalls hindurch nutzbar, die andere VPN-Techniken u. U. blockieren würden, da es sich vom Datenverkehr her im Prinzip wie ein regulärer Browser verhält, der per HTTPS eine Website aufruft. Mit ocserv hat man also mit geringem Konfigurationsaufwand einen VPN-Server, der Windows Phones ohne Probleme in offenen WLANs absichert.


Konfiguration des Servers


Bei meiner Umsetzung kam Debian 8 zum Einsatz. Ich habe hierfür einen x86-vServer genutzt, die Anleitung funktioniert aber 1:1 auch auf einem ARM-Board, wie z. B. einem Raspberry Pi oder Cubieboard (wobei vServer heutzutage teilweise extrem günstig angeboten werden (um die 3 Cent am Tag) und so u. U. sogar die günstigere Alternative darstellen).

Abhängigkeiten und Quellen
Sämtliche Befehle müssen mit root-Rechten ausgeführt werden!
Der erste Schritt zur Konfiguration stellt die Erfüllung der nötigen Abhängigkeiten dar:
apt-get update
apt-get install build-essential pkg-config gnutls-bin libgnutls28-dev

bei Bedarf zusätzlich nötig (im Zweifel einfach installieren):
apt-get install libwrap0-dev libpam0g-dev liblz4-dev libseccomp-dev libreadline-dev libnl-route-3-dev libkrb5-dev

wget ftp://ftp.infradead.org/pub/ocserv/ocserv-0.9.2.tar.xz
(Die neueste Version ist immer unter ftp://ftp.infradead.org/pub/ocserv/ zu finden. Bei der zurzeit aktuellen Version 0.10.8 klappte das Kompilieren nicht ohne Weiteres, 0.9.2 ließ sich bei mir aber problemlos erstellen.)

tar -xf ocserv-0.*
cd ocserv-0.*
./configure
make
make install

Konfiguration
Die Konfiguration von ocserv wird im Ordner /etc/ocserv abgelegt, den wir im nächsten Schritt erstellen müssen:
mkdir /etc/ocserv

In diesem Ordner legen wir eine neue Datei ocserv.config an:
vim ocserv.config

und tragen folgende Konfiguration ein:

auth = "plain[/etc/ocserv/ocservpasswd]"
isolate-workers = true
max-clients = 16
tcp-port = 443
udp-port = 443
listen-clear-file = /var/run/ocserv-conn.socket
keepalive = 32400
dpd = 900
mobile-dpd = 1800
try-mtu-discovery = true
server-cert = /etc/ocserv/server_cert.pem
server-key = /etc/ocserv/server_key.pem
compression = true
auth-timeout = 40
min-reauth-time = 120
cookie-timeout = 300
deny-roaming = false
rekey-time = 172800
rekey-method = ssl
use-utmp = true
use-occtl = true
pid-file = /var/run/ocserv.pid
socket-file = /var/run/ocserv-socket
run-as-user = nobody
run-as-group = daemon
device = vpns
ipv4-network = 192.168.154.0/24
dns = 8.8.8.8
ping-leases = false
cisco-client-compat = true

Mit der Option ipv4-network geben wir das Subnet an, aus welchem den Clients IP-Adressen zugewiesen werden sollen. Statt des Google-DNS-Servers 8.8.8.8 kann natürlich auch ein eigener eingetragen werden. Mit cisco-client-compat = true wird die Kompatibilität zu Cisco AnyConnect konfiguriert.
Der Rest ist zum Teil selbsterklärend, und für alles andere hilft in den heruntergeladenen Quellen eine Beispiel-Konfigurationsdatei in Form von …/doc/sample.config weiter. Diese enthält ausführliche Kommentare zu allen Optionen.

Mit server-cert und server-key wird auf die zur TLS-Verschlüsselung genutzten Zertifikate verwiesen. Da die bisher noch nicht erstellt wurden, holen wir dies nun nach.


Zertifikate erstellen


Wir erstellen zwei Zertifikate: eines für die Certificate Authority (CA) und eines als Server-Zertifikat, das von unserem CA-Zertifikat signiert wird. Sicherer ist es, die Zertifikate auf einem separaten System (offline) zu erstellen und den privaten Schlüssel der CA dort zu belassen, damit der Schlüssel vom Server nicht entwendet werden kann. Technisch ist es aber auch auf demselben System möglich:

CA-Zertifikat erstellen
Zunächst muss für die CA ein privater Schlüssel erstellt werden …
cd ~
certtool --generate-privkey --outfile ca_key.pem

… und danach mit Hilfe des erstellten Schlüssels ein selbst signiertes Zertifikat:
certtool --generate-self-signed --load-privkey ca_key.pem --outfile ca_cert.pem

Es folgen einige Rückfragen, die zu beantworten sind. Relevant sind hierbei vor allem

  • der Common name (z. B. VPN CA),
  • die Activation/Expiration time (Gültigkeitsdauer in Tagen, z. B. 730),
  • die Beantwortung von Does the certificate belong to an authority? (y/N): mit y,
  • und ebenso Will the certificate be used to sign other certificates? (y/N): mit y.

Der Rest kann intuitiv beantwortet bzw. mit ENTER bestätigt werden.
Nach der Beantwortung der Fragen werden die Informationen zum Zertifikat zusammengefasst; die Frage Is the above information ok? (y/N): beantworten wir mit y. Daraufhin wird unser CA-Zertifikat erstellt und neben dem zugehörigen Schlüssel (ca_key.pem) in der Datei ca_cert.pem abgelegt.

Server-Zertifikat erstellen
Zur Erstellung des Server-Zertifikats gehen wir ganz ähnlich vor und generieren wieder einen privaten Schlüssel:
certtool --generate-privkey --outfile vpnsrv_key.pem

Der nächste Befehl wird etwas umfangreicher, weil zusätzlich auf das CA-Zertifikat verwiesen werden muss:
certtool --generate-certificate --load-privkey vpnsrv_key.pem --load-ca-certificate ca_cert.pem --load-ca-privkey ca_key.pem --outfile vpnsrv_cert.pem

Die Fragen beantworten wir dieses Mal folgendermaßen:

  • Common name entspricht dem DNS-Namen des Servers, sofern verfügbar (also z. B. vpn.example.com)
  • Activation/Expiration time z. B. wieder mit 730 für zwei Jahre,
  • Is this a TLS web server certificate? (y/N) mit y
  • Enter a dnsName of the subject of the certificate mit dem DNS-Namen, wenn vorhanden
  • Enter the IP address of the subject of the certificate mit der statischen IP-Adresse, wenn vorhanden
  • Will the certificate be used for encryption (RSA ciphersuites)? mit y

Nach der Zusammenfassung der Infos und einer Bestätigung mit y wird das Zertifikat erstellt und in vpnsrv_cert.pem abgelegt.

Das erstellte Zertifikat sowie den zugehörigen Schlüssel kopieren wir jetzt in den Konfigurationsordner:
cp vpnsrv_cert.pem /etc/ocserv/
cp vpnsrv_key.pem /etc/ocserv/


Benutzer anlegen


Einen Benutzer sowie das zugehörige Passwort legen wir über folgenden Befehl an:
ocpasswd -c /etc/ocserv/ocservpasswd benutzer
Auf /etc/ocserv/ocservpasswd wird in der ocserv_-Konfigurationsdatei verwiesen (_auth = …). Diese Datei enthält die Benutzernamen und zugehörige Passwort-Hashes.


Startskript erstellen


Anschließend erstellen wir noch ein kleines Startskript:
vim /etc/ocserv/ocserv_start.sh
Und fügen folgenden Inhalt ein:
#!/bin/sh
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -j MASQUERADE
ocserv -c /etc/ocserv/config

Die erste Zeile aktiviert IP-Forwarding (alternativ kann dies durch echo 1 > /proc/sys/net/ipv4/ip_forward auch dauerhaft aktiviert werden). In der zweiten Zeile wird NAT aktiviert und die letzte Zeile startet schließlich ocserv mit unserer Konfigurationsdatei.

Hierdurch wird die Datei ausführbar:
chmod u+x /etc/ocserv/ocserv_start.sh

Zum Starten des VPN-Servers reicht es nun, die Datei mit root-Rechten auszuführen. Soll das VPN gleich beim Systemstart zur Verfügung stehen, hilft ein Eintrag in /etc/rc.local (oberhalb von exit 0).

In einem Produktivsystem ist es natürlich eleganter, ein richtiges Init-Skript zu schreiben, aber zur besseren Übersicht soll hier unser kleines Skript und dessen Eintragung in _/etc/rc.local reichen.

Windows-Phone-Client einrichten


Die Server-Konfiguration ist jetzt abgeschlossen, sodass wir mit der Einrichtung des Clients fortfahren können. Hierzu müssen wir die App Cisco AnyConnect aus dem Store installieren.

Außerdem sollten wir das CA-Zertifikat importieren. Dies geschieht am einfachsten über einen Webserver, auf den wir die Datei laden und anschließend mit dem Windows Phone die Datei über den Internet Explorer öffnen (nicht herunterladen) und dann importieren. Eine andere Möglichkeit besteht darin, sich das Zertifikat per E-Mail zu schicken und dann zu importieren.

Anschließend finden wir unter Einstellungen / VPN beim Hinzufügen eines VPNs den neuen VPN-Typen AnyConnect:

Wir fügen ein neues Profil hinzu und tragen dort den DNS-Namen bzw. die statische IP-Adresse, den eben erstellten Nutzer sowie dessen Passwort ein. Weiter unten stellen wir die Zertifikatprüfung ein und das automatische Verbinden aus.


Dann speichern wir die Konfiguration und können das VPN über einfaches Anklicken unseres eben erstellten Profils starten.


Falls die Verbindung nicht aufgebaut werden kann, hilft es, in der App AnyConnect die Option Block Untrusted Servers auf Off zu stellen:

Beim Aufbauen der VPN-Verbindung sollte dann der in einer Warnmeldung angezeigte Fingerabdruck überprüft werden, bevor man bestätigt (um zu verhindern, dass einem ein falsches Zertifikat untergeschoben werden kann).

Die aufgebaute VPN-Verbindung wird durch ein kleines Vorhängeschloss am Symbol der WiFi-Verbindung angezeigt:

Das VPN kann genauso gut auch über eine Mobilfunkverbindung aufgebaut werden. Zu beachten ist, dass es zu Verbindungsproblemen kommen kann, wenn das Handy mit eingeschaltetem VPN längere Zeit nicht genutzt wird. Hierbei hilft es, das VPN aus- und anschließend wieder einzuschalten.

Autor
Kategorien

← Älter Neuer →