Inhaltsverzeichnis

OpenVPN

OpenVPN ist eine Software zur Herstellung eines Virtuellen Privaten Netzwerkes (VPN) über eine verschlüsselte TLS-Verbindung. Zur Verschlüsselung werden die Bibliotheken des Programmes OpenSSL benutzt. OpenVPN verwendet wahlweise UDP oder TCP zum Transport.

Die Vorteile von OpenVPN gegenüber anderen Lösungen liegen in der (relativ) einfachen Konfiguration und der Verfügbarkeit für alle wichtigen Plattformen (u.a. Android, iOS, Linux, Solaris, versch. BSDs, Mac OS X und Microsoft Windows) bei gleichzeitig sehr guter Sicherheit.

Wizards und Hilfen

Installation

Server

Man muss sich entscheiden zwischen tun und tap-Konfiguration.

  1. ein tun-Gerät liegt auf Layer 3 (des ISO/OSI-Modells) und bietet IP-Zugang, was auch für die meisten Anwendungen ausreichen sollte
  2. braucht man andere Protokolle als IP bzw. Kontrolle über Layer 2 muss man ein tap-Gerät konfigurieren.

Im folgenden wird eine tun-Konfiguration beschrieben.

Schlüssel und Zertifikate generieren

:!: Der folgene Teil gilt für die easy-rsa 3.x:

Einrichtung:

Server-cert anlegen:

Clients hinzufügen:

easy-rsa v2 (veraltet)

:!: Der folgende Abschnitt ist für neue Server nicht mehr empfohlen

Als erstes sollte man die Beispielkonfiguration und das Verzeichnis zur Schlüsselerzeugung an einen geeigneten Ort entpacken: 

sudo cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn/
sudo gunzip /etc/openvpn/server.conf.gz
sudo cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0 /etc/openvpn/easy-rsa2

Die gegenseitige Authentifizierung zwischen Server und Client findet bei OpenVPN über kryptografische Schlüssel und Zertifikate statt, die als erstes erstellt werden müssen. Dazu wechselt man zuerst in das Verzeichnis /etc/openvpn/easy-rsa2/ und editiert dort die Datei vars mit Root-Rechten.

In der vars findet man am Ende folgende Einträge: 

  export KEY_COUNTRY=DE
  export KEY_PROVINCE=NRW
  export KEY_CITY=Düsseldorf
  export KEY_ORG=”Vpntest”
  export KEY_EMAIL=”onlyspam@myhomepage.net”

Diese Einträge sollten auf die eigenen Einstellungen angepasst werden.

Aufgrund eines Fehlers wird manchmal das Unterverzeichnis für die Keys nicht erstellt. Man sollte dies darum von Hand nachholen: 

sudo mkdir keys

Danach muss die oben angepasste Datei vars „gesourct“ (d.h. in die Umgebungsvariablen aufgenommen) werden: 

source ./vars

Es erscheint eine Warnmeldung, worauf mit den folgenden Skriptaufrufen das Master-Zertifikat und der Master-Schlüssel erstellt werden: 

sudo -E ./clean-all
sudo -E ./build-ca

Jetzt muss noch das Zertifikat und der Schlüssel für den Server erstellt werden: 

sudo ./build-key-server server

Wichtig dabei ist, dass bei Common Name der Name eingegeben werden sollte, mit dem auf den Server später zugegriffen wird. Das kann z.B. auch der DynDNS-Name sein. Das Challenge Password kann leer gelassen werden. Um die Datenbank zu aktualisieren, muss danach zweimal mit Y bestätigt werden.

Anschließend müssen nun die Schlüssel für die Benutzer angelegt werden: 

sudo ./build-key ersterclient
sudo ./build-key zweiterclient
sudo ./build-key dritterclient

Das geschieht nach dem gleichen Prinzip wie gerade eben beim Server, jedoch muss nun bei Common Name jeweils der Name des Clients eingetragen werden.

Benötigt man zu einem späteren Zeitpunkt weitere Zertifikate, muss zuerst die vars als root (sudo -s) erneut gesourcet werden. Danach können wie gewohnt neue Zertifikate mittels ./build-key erstellt werden.

Jetzt müssen noch die Diffie-Hellman-Parameter generiert werden. Diese sind von Nöten, um kryptografische Schlüssel sicher über unsichere Kanäle auszuhandeln. Das geschieht mit 

sudo ./build-dh

Die Erstellung kann je nach System einige Zeit dauern.

Wenn die Erstellung erfolgreich gewesen ist, liegen nun alle benötigten Dateien im Verzeichnis /etc/openvpn/easy-rsa2/keys/. Die Dateien mit der Endung .key sind die geheimen Schlüssel, die nur auf dem entsprechenden Rechner, zu dem sie gehören, gespeichert werden sollten. Die .crt-Dateien sind die Zertifikate, die nicht geheim gehalten werden müssen. Die Client-Schlüssel und -Zertifikate müssen nun auf die Clients transferiert werden, server.key und ca.key bleiben wo sie sind.

Außerdem muss jeder Client noch die Datei ca.crt erhalten, damit er den Server einwandfrei identifizieren kann. Zusätzlich muss noch darauf geachtet werden, dass die Dateien nie im ASCII-Modus übertragen werden. Dies kann dazu führen das die Datei nicht mehr entschlüsselt werden kann und somit ein Verbinden mit dem openVPN-Server nicht möglich ist. Fehlermeldung: „Error: private key password verification failed“. Am besten umgeht man das Problem indem man alle zu übertragenden Dateien in ein .tar- oder .rar-Archiv packt.

Konfiguration

Nun muss noch die Server-Konfigurationsdatei /etc/openvpn/server.conf angepasst werden. Wichtig ist, dass die Pfade zu den Schlüsseln angepasst werden. Alle anderen Einstellungen sind schon ganz brauchbar. 

  ca ./easy-rsa/keys/ca.crt
  cert ./easy-rsa/keys/server.crt
  key ./easy-rsa/keys/server.key    # Diese Datei geheim halten.
  dh ./easy-rsa/keys/dh2048.pem     # Diffie-Hellman-Parameter

Zur Verbesserung der Sicherheit sollte man den Daemon unter einer unprivilegierten Benutzerkennung laufen lassen, indem man folgende Zeilen aktiviert: 

  # Downgrade privileges after initialization (non-Windows only)
  user nobody
  group nogroup

Noch besser ist es, hier nicht auf die Kennung nobody/nogroup zurückzugreifen, sondern eine eigene spezialisierte openvpn/openvpn-Identität zu schaffen, wobei man die Shell auf /bin/false setzen kann. 

sudo adduser --system --disabled-login --no-create-home openvpn
sudo addgroup --system --disabled-login --no-create-home openvpn

Wer den Server in einem privaten LAN stehen hat, muss noch Port-Forwarding auf seinem Router aktivieren. OpenVPN nutzt standardmäßig den Port 1194 (UDP), der auf die interne IP-Adresse des VPN-Servers weitergeleitet werden muss. Wer einen Linux-Router betreibt, kann dafür das nathelper-Skript verwenden. Besitzer eines Hardware-Routers sollten bei Bedarf dessen Betriebsanleitung oder die Webseiten des Router-Herstellers zu Rate ziehen.

Jetzt kann der Server folgendermaßen gestartet werden: 

sudo /etc/init.d/openvpn restart

hilft eventuell der Abschnitt Fehlerbehebung weiter.

LAN einbeziehen

Um dem Client nicht nur den Server selber, sondern auch das LAN über das VPN zugänglich zu machen, muss nochmal die server.conf bearbeitet werden. Dort wird im betreffenden Bereich folgendes eingetragen: 

  push "route 192.168.2.0 255.255.255.0"
  1. Der hier genannte IP-Bereich muss natürlich durch das korrekte serverseitige LANs ersetzt werden.
  2. Außerdem muss noch das IP-Forwarding am Server aktiviert werden:
    sudo sysctl -w net/ipv4/ip_forward=1

    Um diese Änderung permanent zu machen, kann man sie in die Datei /etc/sysctl.conf eintragen: 

    net.ipv4.ip_forward=1
  3. Wenn der OpenVPN-Daemon nicht auf dem Default-Gateway des lokalen Netzes läuft, so muss auf diesem Default-Gateway/Router noch eine Route erstellt werden, die den OpenVPN-Server als Gateway für das VPN festlegt. Handelt es sich dabei um einen Linux-Rechner, so lautet der Befehl wie folgt und kann bei Bedarf (ohne sudo) in die Datei /etc/rc.local eingetragen werden: 
    sudo route add -net 10.8.0.0 netmask 255.255.255.0 gw VPN.SERVER.I.P
  4. Weiterhin müssen bei einer evtl. vorhandenen Firewall Regeln (bei Iptables in der Forward-chain) eingerichtet werden, die die Kommunikation erlauben.

mehrere Instanzen betreiben

Wenn Openvpn auf mehreren Ports lauschen soll, muss für jeden Port eine eigene Instanz konfiguriert werden. , eine Doppelbelegung funktioniert nicht. Vorteilhaft ist dabei dann man jedes Interface mit speziellen Firewall-regeln versehen kann.

Damit jedoch nicht die unterschiedlichen Instanzen ihre Log- und Statusdateien überschreiben muss mindestens diese Einstellungen anders lauten:

- server - port und ggf. proto - ifconfig-pool-persist - status - log bzw. „log-append“ falls nicht syslog verwendet wird

Zusätzlich muss jede dieser Instanzen ein eigenes tun-devices benutzen, deshalb ist dieser Eintrag in der zweiten server-B.conf notwendig: 

dev tun1

Das Initscript sollte dann für jede der Konfigurationsdateien einmal openvpn starten. Hier das Script aus Debian Lenny: 

#!/bin/sh -e

### BEGIN INIT INFO
# Provides:          vpn
# Required-Start:    $network $local_fs
# Required-Stop:     $network $local_fs
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Openvpn VPN service
### END INIT INFO

# Original version by Robert Leslie
# <rob@mars.org>, edited by iwj and cs
# Modified for openvpn by Alberto Gonzalez Iniesta <agi@inittab.org>
# Modified for restarting / starting / stopping single tunnels by Richard Mueller <mueller@teamix.net>

. /lib/lsb/init-functions

test $DEBIAN_SCRIPT_DEBUG && set -v -x

DAEMON=/usr/sbin/openvpn
DESC="virtual private network daemon"
CONFIG_DIR=/etc/openvpn
test -x $DAEMON || exit 0
test -d $CONFIG_DIR || exit 0

# Source defaults file; edit that file to configure this script.
AUTOSTART="all"
STATUSREFRESH=10
if test -e /etc/default/openvpn ; then
  . /etc/default/openvpn
fi

start_vpn () {
    if grep -q '^[	 ]*daemon' $CONFIG_DIR/$NAME.conf ; then
      # daemon already given in config file
      DAEMONARG=
    else
      # need to daemonize
      DAEMONARG="--daemon ovpn-$NAME"
    fi

    if grep -q '^[	 ]*status ' $CONFIG_DIR/$NAME.conf ; then
      # status file already given in config file
      STATUSARG=""
    elif test $STATUSREFRESH -eq 0 ; then
      # default status file disabled in /etc/default/openvpn
      STATUSARG=""
    else
      # prepare default status file
      STATUSARG="--status /var/run/openvpn.$NAME.status $STATUSREFRESH"
    fi

    log_progress_msg "$NAME"
    STATUS=0

    # Check to see if it's already started...
    if test -e /var/run/openvpn.$NAME.pid ; then
      log_failure_msg "Already running (PID file exists)"
      STATUS=0
    else
      $DAEMON $OPTARGS --writepid /var/run/openvpn.$NAME.pid \
	      $DAEMONARG $STATUSARG --cd $CONFIG_DIR \
	      --config $CONFIG_DIR/$NAME.conf || STATUS=1
    fi
}
stop_vpn () {
  kill `cat $PIDFILE` || true
  rm -f $PIDFILE
  rm -f /var/run/openvpn.$NAME.status 2> /dev/null
}

case "$1" in
start)
  log_daemon_msg "Starting $DESC"

  # autostart VPNs
  if test -z "$2" ; then
    # check if automatic startup is disabled by AUTOSTART=none
    if test "x$AUTOSTART" = "xnone" -o -z "$AUTOSTART" ; then
      log_warning_msg " Autostart disabled."
      exit 0
    fi
    if test -z "$AUTOSTART" -o "x$AUTOSTART" = "xall" ; then
      # all VPNs shall be started automatically
      for CONFIG in `cd $CONFIG_DIR; ls *.conf 2> /dev/null`; do
        NAME=${CONFIG%%.conf}
        start_vpn
      done
    else
      # start only specified VPNs
      for NAME in $AUTOSTART ; do
        if test -e $CONFIG_DIR/$NAME.conf ; then
          start_vpn
        else
          log_failure_msg "No such VPN: $NAME"
          STATUS=1
        fi
      done
    fi
  #start VPNs from command line
  else
    while shift ; do
      [ -z "$1" ] && break
      if test -e $CONFIG_DIR/$1.conf ; then
        NAME=$1
        start_vpn
      else
       log_failure_msg " No such VPN: $1"
       STATUS=1
      fi
    done
  fi
  log_end_msg ${STATUS:-0}

  ;;
stop)
  log_daemon_msg "Stopping $DESC"

  if test -z "$2" ; then
    for PIDFILE in `ls /var/run/openvpn.*.pid 2> /dev/null`; do
      NAME=`echo $PIDFILE | cut -c18-`
      NAME=${NAME%%.pid}
      stop_vpn
      log_progress_msg "$NAME"
    done
  else
    while shift ; do
      [ -z "$1" ] && break
      if test -e /var/run/openvpn.$1.pid ; then
        PIDFILE=`ls /var/run/openvpn.$1.pid 2> /dev/null`
        NAME=`echo $PIDFILE | cut -c18-`
        NAME=${NAME%%.pid}
        stop_vpn
        log_progress_msg "$NAME"
      else
        log_failure_msg " (failure: No such VPN is running: $1)"
      fi
    done
  fi
  log_end_msg 0
  ;;
# Only 'reload' running VPNs. New ones will only start with 'start' or 'restart'.
reload|force-reload)
 log_daemon_msg "Reloading $DESC"
  for PIDFILE in `ls /var/run/openvpn.*.pid 2> /dev/null`; do
    NAME=`echo $PIDFILE | cut -c18-`
    NAME=${NAME%%.pid}
# If openvpn if running under a different user than root we'll need to restart
    if egrep '^[[:blank:]]*user[[:blank:]]' $CONFIG_DIR/$NAME.conf > /dev/null 2>&1 ; then
      stop_vpn
      sleep 1
      start_vpn
      log_progress_msg "(restarted)"
    else
      kill -HUP `cat $PIDFILE` || true
    log_progress_msg "$NAME"
    fi
  done
  log_end_msg 0
  ;;

# Only 'soft-restart' running VPNs. New ones will only start with 'start' or 'restart'.
soft-restart)
 log_daemon_msg "$DESC sending SIGUSR1"
  for PIDFILE in `ls /var/run/openvpn.*.pid 2> /dev/null`; do
    NAME=`echo $PIDFILE | cut -c18-`
    NAME=${NAME%%.pid}
    kill -USR1 `cat $PIDFILE` || true
    log_progress_msg "$NAME"
  done
  log_end_msg 0
 ;;

restart)
  shift
  $0 stop ${@}
  sleep 1
  $0 start ${@}
  ;;
cond-restart)
  log_daemon_msg "Restarting $DESC."
  for PIDFILE in `ls /var/run/openvpn.*.pid 2> /dev/null`; do
    NAME=`echo $PIDFILE | cut -c18-`
    NAME=${NAME%%.pid}
    stop_vpn
    sleep 1
    start_vpn
  done
  log_end_msg 0
  ;;
*)
  echo "Usage: $0 {start|stop|reload|restart|force-reload|cond-restart}" >&2
  exit 1
  ;;
esac

exit 0

# vim:set ai sts=2 sw=2 tw=0:

MTU Config

Folgende Einstellungen sind möglich, müssen aber sowohl auf Server als auch auf Client-Ebene hinterlegt werden. 

# UDP-Pakete fragmentieren nach:
fragment 1400
# TCP-Verbindung den Wert signalisieren
mssfix 1350

weitere Einstellungen: 

# MTU auf tun-Ebene
tun-mtu n
# MTU auf Netzwerk-Ebene
link-mtu n

Auf Windows-Ebene:

:!: Achtung permante Einstellungen

LAN: 

netsh interface ipv4 set subinterface "Local Area Connection" mtu=1440 store=persistent

Wlan: 

netsh interface ipv4 set subinterface "Wireless Network Connection" mtu=1440 store=persistent

Authentifizierung

  1. per Zertifikat
  2. Passwort
  3. LDAP
  4. Kerberos
  5. ADS
  6. IMAP
  7. PAM-Module

Damit der OpenVPN-Client den Benutzer überhaupt nach einem Benutzernamen und Passwort fragt, muss er mit „–enable-password-save“ kompiliert worden sein, also 

./configure --enable-password-save

Siehe auch: Howto: Rootserver als OpenVPN-Gateway nutzen.

pam_imap

Falls Authentifizierung an IMAP erwünscht ist, muss pam_imap kompiliert werden (als Paket für Debian nicht verfügbar):

Authentifizierung individuell einstellen

  1. Zuerst PAM-per-User mit Konfigurationsdatei /etc/pam.d/openvpn konfigurieren: 
    auth    required    pam_per_user.so.1
account     required     pam_permit.so
  2. danach in /etc/pam_per_user.map 
    benutzer1: openvpn-ldap
benutzer2: openvpn-krb5
benutzer3: openvpn-imap
  3. benutzer1 meldet sich gegen LDAP an (Datei /etc/pam.d/openvpn-ldap):
    auth     required    pam_env.so
auth     required    pam_ldap.so
account     required    pam_ldap.so
  4. benutzer2 meldet sich gegen Kerberos an (Datei /etc/krb5.conf):
    auth     requisite     pam_krb5.so no_ ccache
account     required     pam_kermit.so
  5. benutzer3 kommt per IMAP-Account (Datei /etc/pam.d/openvpn-imap):
    PAM_PasswordString = Password for Mail-Server:
CertificateFile /usr/share/ssl/certs/imapd.pem
PAM_Server0 = imap.domain.tld:143
PAM_Blocklist = root, admin, Administrator, apache
PAM_HashEnable = no
PAM_HashFile = /etc/pam_imap.gdbm
PAM_HashDelta = 20
  6. in der server.conf muss nun das PAM-Plugin angegeben werden (damit wird /etc/pam.d/openvpn benutzt): 
    plugin /usr/lib/openvpn/openvpn-auth-pam.so openvpn
  7. :!: in der client.conf muss „auth-user-pass“ angegeben sein.

Konfiguration für einzelne Benutzer

Für individuellen Clients kann eine spezielle Konfiguration angelegt werden. Dazu muss folgende Zeile („ccd“ ist änderbar) in der server.conf hinzugefügt werden: 

client-config-dir ccd

Individuelle Konfigurationen gehen anhand des Common-Names (CN) des Benutzerzertifikats in /etc/openvpn/ccd/CN also z.B. /etc/openvpn/ccd/benutzer1: 

ifconfig-push 10.0.8.21 10.0.8.22
push "redirect-gateway"
push "route 10.0.8.0 255.255.255.0"

:!: Der push-Buffer hat nur 1024 Byte, man bekommt sonst Fehler der Art „Maximum length of push-Buffer (1024) has been exceeded“.

Bei ifconfig-push gibt die erste IP-Adresse die Adresse des virtuellen Clients an, die 2. des virtuellen Server endpoints.

Laut openvpn.org-HOWTO müssen Sie aus /30 subnets geholt werden, damit die Windows Clients/TAP-Win32 Treiber mitspielen.

Zitat von http://openvpn.net/howto.html (siehe auch: OpenVPN Tutorial): 

Specifically, the last octet in the IP address of each endpoint pair must be taken from this set:

[ 1, 2] [ 5, 6] [ 9, 10] [ 13, 14] [ 17, 18]
[ 21, 22] [ 25, 26] [ 29, 30] [ 33, 34] [ 37, 38]
[ 41, 42] [ 45, 46] [ 49, 50] [ 53, 54] [ 57, 58]
[ 61, 62] [ 65, 66] [ 69, 70] [ 73, 74] [ 77, 78]
[ 81, 82] [ 85, 86] [ 89, 90] [ 93, 94] [ 97, 98]
[101,102] [105,106] [109,110] [113,114] [117,118]
[121,122] [125,126] [129,130] [133,134] [137,138]
[141,142] [145,146] [149,150] [153,154] [157,158]
[161,162] [165,166] [169,170] [173,174] [177,178]
[181,182] [185,186] [189,190] [193,194] [197,198]
[201,202] [205,206] [209,210] [213,214] [217,218]
[221,222] [225,226] [229,230] [233,234] [237,238]
[241,242] [245,246] [249,250] [253,254]

Um zu verhindern, dass jemand ein fremdes Zertifikat benutzt (indem er das Zertifikat von einem anderen Benutzer präsentiert, zur Authentifizierung aber seine eigenen Daten verwendet) muss überprüft werden das der CN mit den Zugangsdaten zusammen passt.

Dazu das Script ucn.pl (s. u.) erstellen und in der server.conf folgende Zeile dazu geben: 

auth-user-pass-verify /usr/local/scripts/ucl.pl via-env

Dann übergibt OpenVPN über Umgebungsvariablen username und CN. 

!/usr/bin/perl ‑t
#
# OpenVPN ‑‑auth‑user‑pass‑verify script.
# Only authenticate if username equals Ucommon_name.
# In OpenVPN config file: auth‑user‑pass‑verify ./ucn.pl via‑env
$username = $ENV{'username'};
$common_name = $ENV{'common_name'};
@common_name_array = split(/\./, $common_Uname);
exit !(length($username) > 0 && Ulength($common_name) > 0 && $username eq U$common_name_array[0]);

individuelle Firewallregeln

learn-address /usr/local/scripts/openvpn-fw-conf

FIXME 

# Eine eigene Tabelle für den User anlegen
iptables ‑N chain‑$IP
# In der Forward‑Table ist diese das Sprungziel für die Source‑IP des Users:
iptables ‑I FORWARD ‑s $IP ‑j chain‑$IP
# ESTABLISHED‑Connections einfach ohne weiteres Matching durchlassen:
iptables ‑A chain‑$IP ‑s $IP ‑m state ‑‑state RELATED,ESTABLISHED ‑j ACCEPT
# Nun folgen individuelle Regeln für den Benutzer, beispielsweise den Zugriff auf den Zielrechner
$destHost, Port $destPort und das Protokoll $destProto:
iptables ‑A chain‑$IP ‑p $destProto ‑s $IP ‑d $destHost ‑‑dport $destPort ‑j ACCEPT
# Oder dasselbe mit mehreren Ports mit --dports:
iptables ‑A chain‑$IP ‑m multiport ‑p $destProto ‑s $IP ‑d $destHost ‑‑dports $destPort ‑j ACCEPT
# Vollzugriff auf einen Host:
iptables ‑A chain‑$IP ‑s $IP ‑d $destHost ‑j ACCEPT
# Abschließend den ICMP‑Traffic erlauben:
iptables ‑A chain‑$IP ‑p icmp ‑s $IP ‑j ACCEPT
# und alles weitere verbieten:
iptables ‑A chain‑$IP ‑s $IP ‑j DROP

Client-Konfiguration

Zuerst muss auch auf den Clients das openvpn-Paket installiert werden, wie weiter oben beschrieben. Statt der Datei server.conf wird hier aber logischerweise die client.conf editiert. Dort ändert man die IP-Adresse unter der der Server erreichbar ist. Wer keine statische IP zur Verfügung hat, kann dort auch seine dyndns-Adresse angeben 

remote ich.dyndns.org

Die Pfade der einzelnen ca, cert, usw. müssen hier nicht unbedingt angepasst werden, wenn die einzelnen Dateien auf dem Client im gleichen Ordner liegen wie die client.conf und die voreingestellten Dateinamen besitzen. Natürlich müssen sie erstmal vom Server herüberkopiert worden sein.

Die Authentifizierung des OpenVPN-Servers ist für einen ersten Test nicht notwendig, für die spätere Benutzung aus Sicherheitsgründen aber empfohlen. Dazu wählen wir eine der Methoden die auf der Seite http://openvpn.net/howto.html#mitm beschrieben ist. Bei einem aktuellen Ubuntu (ab hardy) mit OpenVPN-Version ab 2.1 funktioniert: 

remote-cert-tls server

Andernfalls bekommen wir bei jeder Verbindung eine Warnung („WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info.“)

Openvpn 2.4 (Windows)

Mit dem neuen openvpn 2.4 ist es möglich unter Windows eine Openvpn-Einwahl auch ohne Admin-Rechte machen zu können.

  1. Download
  2. Installation folgen (Lizenz annehmen, Filtertreiber installieren usw.)
  3. die passende config nehmen (s.o.) und diese Config in das Verzeichnis „C:\Program Files\OpenVPN\config“ kopieren (Admin-Rechte einmalig erforderlich)
  4. openvpn gui starten
  5. rechte Maustaste aufs Symbol openvpn manager symbol → Einstellungen - Launch on Windows startup + OK

Falls es nicht gehen sollte:

Linux

OpenVPN-Paket installieren: Debian, Ubuntu: 

aptitude install openvpn

Vorraussetzung: openvpn über den Paketmanager installieren, (falls nötig aktuelleres Repo einbinden)

Bei internen DNS-Servern (nicht öffentlich auflösbare interne Zonen) wird vom VPN-Server der DNS-Server via push-option übermittelt. Leider setzt dies openvpn nicht selbstständig um.

bei systemd-resolved

Direktdownload, ablegen in /etc/openvpn/scripts : 

# LINUX only
script-security 2
up /etc/openvpn/scripts/update-systemd-resolved
down /etc/openvpn/scripts/update-systemd-resolved
down-pre

Quelle:

Methode resolvconf

ohne networkmanager: Paket resolvconf muss installiert sein.

Damit die Namensauflösung funktioniert muss in der ovpn-Config-Datei diese Zeilen anhängt werden: 

# LINUX only! (needs resolvconf installed!)
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf
# for resolvconf and openvpn >= 2.1:
script-security 2

Network-Manager/VPN Plugins

Die Network-Manager VPN Plugins bieten eine Oberfläche für die VPN-Einwahl an:

sudo apt install network-manager-openvpn network-manager-openvpn-gnome

Openvpn-Dienst als Client

Wenn die Verbindung bei jedem Systemstart automatisch aufbauen lassen will, muss folgende Zeile in der Datei /etc/default/openvpn aktivieren: 

AUTOSTART="$Profilname" # oder "all"

Android

Android enthält seit Version 4.1 standardmäßig einen Open-VPN-Client (ältere Versionen muss man ggf. „rooten“) aber auch die offizielle App OpenVPN Connect ist empfehlenswert.

iPhone / iPad

Den „OpenVPN Connect Client“ aus dem Store installieren.

OpenVPN über HTTP-Proxy

Sitzt man nicht direkt an einem Internetzugang (z.b. im Büro oder beim Kunden), so hat man oft keine Möglichkeit über Port 1194 ins Internet zu kommen. Üblicherweise ist aber der Port 443 (HTTPS) in jedem Netz freigeschaltet. Um vom Client über den HTTPS-Proxy ins Internet und zum heimischen OpenVPN-Server zu gelangen, müssen folgende Konfigurationen gemacht werden:

server.conf

# Which TCP/UDP port should OpenVPN listen on?
# If you want to run multiple OpenVPN instances
# on the same machine, use a different port
# number for each one.  You will need to
# open up this port on your firewall.
port 443
;port 1194
# TCP or UDP server?
proto tcp
;proto udp

Auf dem Server wird in der server.conf auf den Port 443 umgeschaltet. Zudem wird hier auf das Protokoll TCP umgeschaltet, was nicht zwingend ist, aber weniger Probleme verursacht bei der Benutzung eines HTTP-Proxys.

client.conf

# If you are connecting through an
# HTTP proxy to reach the actual OpenVPN
# server, put the proxy server/IP and
# port number here.  See the man page
# if your proxy server requires
# authentication.
http-proxy 192.168.4.1 1080
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]

Auf dem Client wird in der client.conf die Zeile http-proxy 192.168.4.1 1080 hinzugefügt. Wobei die Addresse des Proxy 192.168.4.1 und der Port 1080 mit den effektiven Angaben ersetzt werden müssen. Weitere Informationen zur Konfiguration von HTTP-Proxys sind unter http://openvpn.net/howto.html#http verfügbar.

Fehlerbehebung

Falls der Start von OpenVPN nicht klappt, finden sich im Protokoll (Logdatei) Hinweise zur Fehlerbehebung. Die Meldungen sollten je nach Distribution in /var/log/daemon.log, /var/log/syslog oder /var/log/messages stehen.

Cannot allocate TUN/TAP dev dynamically (virtualisierte Systeme)

Folgender Fehler im Protokoll (häufig bei virtualisierten Systemen der Fall): 

  openvpn[...]: Note: Cannot open TUN/TAP dev /dev/net/tun: Permission denied (errno=13)
  openvpn[...]: Note: Attempting fallback to kernel 2.2 TUN/TAP interface
  openvpn[...]: Cannot allocate TUN/TAP dev dynamically

Viele Provider bieten mittlerweile günstige virtualisierte Server an (auch VPS oder VServer). Bestimmte Funktionen lassen sich auf solchen Servern nur nutzen, wenn die entsprechenden Fähigkeiten auch in den Kernel des Host-Systems kompiliert wurden, auf dem die VPS läuft. Das gilt insbesondere für TUN/TAP und iptables. Bei vielen Providern genügt es, wenn man in einem Support-Ticket kurz erklärt, dass man TUN/TAP oder iptables nutzen möchte und sie wechseln den Kernel aus.

Funktioniert TUN/TAP dann immer noch nicht muss man das Gerät noch selbst erstellen: 

sudo mkdir -p /dev/net
sudo mknod /dev/net/tun c 10 200
sudo chmod 600 /dev/net/tun

Falls dies die Lösung bringt, ist die Anpassung des OpenVPN-Init-skripts (das die Befehle beim Start des Rechners ausführt) sinnvoll, da bei Neustarts /dev/net/tun wieder verschwunden ist.

In die Datei /etc/init.d/openvpn schreiben wir also an den Anfang: 

# Create /dev/net (not created in Xen-environment)
if [ ! -d /dev/net ]
then
    mkdir -p /dev/net
fi
if [ ! -c /dev/net/tun ]
then
    mknod /dev/net/tun c 10 200
fi
chmod 600 /dev/net/tun
# End of modifications

Replay-window backtrack occurred

Fehlermeldung: 

Replay-window backtrack occurred [63]

Bei der Konfiguration mit UDP kann es sein, dass manche Pakete nicht in der Reihenfolge eintreffen in der sie abgeschickt wurden, sondern später. Manchmal auch zu spät, wie diese Meldung dokumentiert. Eine Lösung ist die Anhebung des „replay-window calibration“, bei Debian werrtet

Als Startparameter: 

--replay-window 72

Als Option in der Konfigurationsdatei: 

replay-window 72

Links:

* [Openvpn-users] replay-window calibration