Tutorials - OpenVPN Tutorial

Sprachenübersicht/Betriebssysteme/Linux/Security

OpenVPN Tutorial

Diese Seite wurde 505486 mal aufgerufen.

Dieser Artikel wurde in einem Wikiweb System geschrieben, das heißt, Sie können die Artikel jederzeit editieren, wenn Sie einen Fehler gefunden haben, oder etwas hinzufügen wollen.

Editieren Versionen Linkpartnerschaft Bottom Printversion

Keywords: OpenVPN, Tutorial, SSL, sicheres WLAN, VPN

Inhaltsverzeichnis

• Vorwort
  
• Installation
  
• Schlüssel erzeugen, und richtig plazieren
  
• Ausgangslage
  
• TCP oder UDP
  
• Server konfigurieren
  
• OpenVPN Client
  
• Routing
  
• Theoretische Absicherung eines WLAN-Netzwerks mit OpenVPN
  
• Clientspezifischer Zugriff
  
• OpenVPN über einen Proxy Server
  
• Weitere Optionen
  
• Probleme
  
• Beispielkonfigurationen
  
• Weblinks
  

Vorwort Top

OpenVPN ist eine VPN-Lösung, die eine sichere, verschlüsselte Verbindung für alle *BSD-, Linux-, Mac OS X- und Windows-PCs beinhaltet.

Dieses Tutorial lehrt den Umgang mit OpenVPN, als Voraussetzung sollte man die Grundlagen der Netzwerktechnik, und die Grundlagen vom eigenen System kennen. Der Server wird nur für eine Linux Version erklärt, es sollte aber kein Problem sein, einen Windows Server zu betreiben.

Wenn Kenntnisse in einem Gebiet fehlen -> einfach im Forum fragen, wir haben auf fast alles eine Antwort

Installation Top

• Debian
  
  Unter Debian kann man OpenVPN mit apt-get install openvpn installieren lassen.
  

• Gentoo
  
  Unter Gentoo kann man OpenVPN mit emerge openvpn installieren lassen.
  

• RedHat / CentOS / Fedora (RPM)
  
  Auf RedHat Systemen, dem binärkompatiblen CentOS oder artverwandten Distributionen wie Fedora kann zur Installation auf das Programm "yum" zurückgegriffen werden.
  
  yum install openvpn
  
  sollte den OpenVPN Server installieren.
  Pakete die im Zusammenhang mit OpenVPN stehen können leicht mit:
  
  yum search openvpn
  
  gefunden werden.
  Oftmals empfiehlt sich eine suche mit search im Vorfeld generell da in Ausnahmefällen die Pakete je nach Distribution etwas anders benannt sein können.
  
  Falls Ihr gerne mit einer GUI arbeiten möchtet werdet Ihr so auch z.B. unter CentOS NetworkManager-openvpn finden das mit:
  
  yum install NetworkManager-openvpn
  
  installiert werden kann und euch die VPN konfiguration grafisch in den Gnome Netzwerk Manager mit einbindet.
  

• Source Code
  
  Den Quellcode können wir unter www.openvpn.org herunterladen, in unserem Fall ist es openvpn.net/release/openvpn-2.0.1.tar.gz, als Grundlage brauchen wir ein installiertes OpenSSL.
  
  Nachdem wir die Datei heruntergeladen haben, können wir openvpn installieren:
  
  
  Code:
  
  
  workstation:/usr/src# tar -xzvf openvpn-2.0.1.tar.gz
  workstation:/usr/src# cd openvpn-2.0.1
  workstation:/usr/src/openvpn-2.0.1# ./configure
  workstation:/usr/src/openvpn-2.0.1# make
  workstation:/usr/src/openvpn-2.0.1# make install
  

  
  
  Wir sollten folgende Pakete zusätzlich installieren:lzo, lzo-devel, pam, pam-devel
  
  Wenn wir lzo nicht wollen, können wir ./configure --disable-lzo machen.
  
  Bei meinem Debian System erschien folgende Meldung: OpenSSL Crypto headers not found.
  Das habe ich mit folgenden Parametern gelöst:
  
  ./configure --with-ssl-headers=/usr/local/ssl/include/ --with-ssl-lib=/usr/local/ssl/lib/, das Verzeichnis kann natürlich anders sein.
  
  Wir müssen noch sicher gehen, das tun/tap vom Kernel unterstützt wird, mit make menuconfig findet man das z.B. unter Device Drivers/Network Support/Universal TUN/TAP device driver support [*].
  
  Jetzt sollte alles installiert sein.
  

• Windows
  Als erstes müssen wir den Windows Client installieren, das sollte kein Problem sein, bei der Frage nach unsignieren Treibern mit JA Antworten.
  
  Jetzt finden wir unter
  Einstellungen->Systemsteuerung->Netzwerkverbindungen das neue tun Device. Es hat irgendeinen anderen Namen... Nach einem Rechtsklick auf das Device gehen wir auf Eigenschaften->Konfigurieren und dort auf die Registerkarte Erweitert.
  
  OpenVPN richtet ein tun Device ein, das man unter Systemsteuerung->Netzwerkumgebung findet. Mit F2 benennen wir es um, in meinem Fall: vsn-device. Jetzt machen wir einen Rechtsklick->Eigenschaften->Konfigurieren->Erweiterte Einstellungen, hier stellen wir das MTU auf 1492.
  

Schlüssel erzeugen, und richtig plazieren Top

Die Schlüssel erzeugen wir wie in unserem OpenSSL Tutorial.

Danach kopieren wir die Zertifikate, und Schlüssel in unser Arbeitsverzeichnis, hier, unter Debian: /etc/openvpn in den Ordner certs.

Ausgangslage Top

Wir haben 3 PC's:

- Linux Server im Netzwerk Home 192.168.0.1/24 und später 10.0.0.1 als VPN Adresse, im Internet existiert er unter vsn.test-host.de
- Rechner im Netzwerk Home 192.168.0.99/24
- Rechner im Internet 83.73.211.1/32 oder später 10.0.0.x als VPN Adresse

Wir haben auf dem Linux Rechner einen Webserver auf Port 80, und auf dem Windows PC einen Samba Server (445), der sich um die Datenfreigabe kümmert (hat standardmässig jeder Windows Rechner).

Jetzt wollen wir über das Internet auf den Samba -und Webserver zugreifen, dazu wird ein VPN zum Server aufgebaut, und danach per iptables zum Netzwerk Rechner geroutet.

Wenn wir keinen hostname im Internet haben, können wir ihn per dyndns einrichten. Dazu gibt es einige Dienste, z.B ProutDNS. Unter google sollte man einige finden.

TCP oder UDP Top

Als erstes müssen wir uns überlegen, was wir verwenden, entweder TCP, oder UDP. TCP über TCP ist eine schlechte Idee, da es in diesem Protokoll eine Fehlerkontrolle gibt, d.h. es wird nach Paketen die nicht ankommen nochmal gefragt, das bringt das ganze Protokoll durcheinander. Mehr dazu sites.inka.de/sites/bigred/devel/tcp-tcp.html.

Da wir einen TCP Dienst nutzen wollen, verwenden wir UDP als Protokoll für den Tunnel, wenn wir auschließlich UDP Dienste nutzen wollen wäre TCP eine feine Sache, da dann alle Pakete ankommen .

Server konfigurieren Top

Als erstes brauchen wir ein config Script für den Server, /etc/openvpn/server.conf (unter Windows OpenVPNInstallationsverzeichnis/config/server.ovpn, wie OpenVPN unter Windows installiert wird, kommt steht oben, Rechtsklick->"Start OpenVPN on this file" startet den Server unter Windows, unseres schaut so aus:

Mit cd /etc/openvpn/ && openvpn --config /etc/openvpn/server.conf können wir die Datei testen, jetzt schauen wir ob's klappt (mit verb 3):

Unter debian gibt es noch das nette Programm rcconfig, das uns das script automatisch mit openvpn startet, mehr dazu siehe Doku.

Falls es Probleme gibt, einfach im Forum melden

OpenVPN Client Top

• Windows
  
  Wir installieren den OpenVPN Client wie im Kapitel “Installation” beschrieben.
  
  Als erstes muss vpn-ca.pem, simon_lan_key.pem, und simon_lan_cert.pem in das Verzeichnis Installationsverzeichnis-OpenVPN/config, danach sollte die Zertifikat-Geschichte erledigt sein.
  
  Die config Datei kommt in dieses Verzeichnis: Installationsverzeichnis-OpenVPN/config. Mehr dazu, siehe weiter unten.
  
  Wenn die config Datei (weiter unten) erstellt wurde, können wir sie mit Rechtsklick->"Start OpenVPN on this file" starten.
  
  Wenn "Initialization Sequence Completed" kommt haben wir gewonnen
  
  Jetzt gehen wir auf Start->Ausführen, und geben da cmd ein:
  
  
  Code:
  
  
  Microsoft Windows 2000 [Version 5.00.2195]
  (C) Copyright 1985-2000 Microsoft Corp.
  
  D:\>ping 10.0.0.1
  
  Ping wird ausgeführt für 10.0.0.1 mit 32 Bytes Daten:
  
  Antwort von 10.0.0.1: Bytes=32 Zeit<10ms TTL=64
  Antwort von 10.0.0.1: Bytes=32 Zeit<10ms TTL=64
  
  Ping-Statistik für 10.0.0.1:
      Pakete: Gesendet = 2, Empfangen = 2, Verloren = 0 (0% Verlust),
  Ca. Zeitangaben in Millisek.:
      Minimum = 0ms, Maximum =  0ms, Mittelwert =  0ms
  STRG-C
  ^C
  D:\>
  

  
  
  Wir haben es geschafft, wir haben eine Verbindung.
  
  Unter Systemsteuerung->Verwaltung-Dienste können wir unter Rechtsklick->Eigenschaften "Dienst automatisch starten" auswählen, dann startet der Client alle .ovpn files automatisch.
  
  

• Linux
  
  Wir installieren OpenVPN wie beim Server, (siehe Kapitel Installation) und machen eine Datei /etc/openvpn/client.conf, danach kopieren wir die config die wir weiter unten finden rein.
  
  * ( missing: keys? )
  ** Die Windows-client-Installation beschreibt, welche zuvor auf dem Server erzeugten Schluessel noetig sind
  
  
  openvpn --config /etc/openvpn/client.conf startet den client, "Initialization Sequence Completed" bedeutet das alles OK ist.
  
  Jetzt öffnen wir ein Shell, und tippen folgendes rein:
  
  
  Code:
  
  
  home:/etc/openvpn# ping 10.0.0.1
  PING 10.0.0.1 (10.0.0.1): 56 data bytes
  64 bytes from 10.0.0.1: icmp_seq=0 ttl=128 time=3.2 ms
  64 bytes from 10.0.0.1: icmp_seq=1 ttl=128 time=2.4 ms
  
  --- 10.0.0.1 ping statistics ---
  2 packets transmitted, 2 packets received, 0% packet loss
  round-trip min/avg/max = 2.4/2.8/3.2 ms
  

  
  
  Wir haben es geschafft, wir haben eine Verbindung.
  
  Wie beim Server können wir rcconfig benutzen, damit das ganze läuft.
  
  

Jetzt müssen wir die config Datei noch unter dem Namen xyz.ovpn erstellen:

Routing Top

Jetzt haben wir eine Verbindung zum Server, über einen Tunnel, jetzt müssen wir nur noch das Zeug von 445 in das interne Netz leiten.

Dazu haben wir 2 möglichkeiten

• Die schnelle, unsaubere Möglichkeit wenn wir kein vorhandenes iptables Script haben
  
  Wir kommentieren #push "route 192.168.0.0 255.255.255.0" im Server Script aus, dadurch hat der OpenVPN Client zugriff auf das komplette interne Netzwerk 192.168.0.0/24, dabei sollten wir beachten das das Netzwerk vom Server nicht das selbe ist wie das vom OpenVPN Client.
  
  

• Die gute, sichere Methode: iptables - Ports einzeln forwarden
  
  Dazu fügen wir 2 commands in unser iptables Script ein:
  
  
  Code:
  
  
  IPTABLES=/sbin/iptables
  
  #finden wir mit ifconfig heraus
  VPN_DEV=tap0
  
  #VPN Netzwerk
  VPN_NET=10.0.0.0/24
  
  #internes netzwerk
  INT_DEV=eth0
  
  #Leitet alles was per Port 445 kommt zum Internen Netz um, auf Port 445 darf auf dem Server nichts laufen
  $IPTABLES -t nat -A PREROUTING -i $VPN_DEV -p tcp --dport 445 -j DNAT --to 192.168.0.99
  
  #Lässt alles in's VPN durch
  $IPTABLES -A FORWARD -i $INT_DEV -o $VPN_DEV -s $VPN_NET -p tcp -j ACCEPT
  $IPTABLES -A FORWARD -i $INT_DEV -o $VPN_DEV -s $VPN_NET -p udp -j ACCEPT
  

  
  
  Wie man ein iptables Script einrichtet erfahren wir hier.
  
  

• Die gute, sichere Methode: iptables - Netzwerk per NAT routen
  
  Wir brauchen wie in der zweiten Methode ein iptables Script, dort fügen wir folgendes hinzu:
  
  
  Code:
  
  
  IPTABLES=/sbin/iptables
  
  #finden wir mit ifconfig heraus
  VPN_DEV=tap0
  
  #VPN Netzwerk
  VPN_NET=10.0.0.0/24
  
  #internes netzwerk
  INT_DEV=eth0
  
  #--m multiport wegnehmen, wenn nur 1 Port geforwardet werden soll
  NAT_FORWARDING_TCP_PORT_TO_VPN="21,22"
  
  #--m multiport wegnehmen, wenn nur 1 Port geforwardet werden soll
  #Ports im internen Netzwerk
  NAT_FORWARDING_TCP_PORT_TO_LAN="445,80"
  
  $IPTABLES -A POSTROUTING -t nat -p tcp -o $EXT_DEV -s $INT_NET -j MASQUERADE
  $IPTABLES -A POSTROUTING -t nat -p icmp -o $EXT_DEV -s $INT_NET -j MASQUERADE
  $IPTABLES -A FORWARD -p tcp ! --syn -j ACCEPT
  
  #Der interne PC soll auf die Ports vom OpenVPN Client zugreifen können.
  $IPTABLES -A FORWARD -i $INT_DEV -o $VPN_DEV -s $INT_NET -p tcp -m multiport --dport $NAT_FORWARDING_TCP_PORT_TO_VPN -j ACCEPT
  
  #Die Ports vom internen Netzwerk sollen erreichbar sein
  $IPTABLES -A FORWARD -i $VPN_DEV -o $INT_DEV -s $VPN_NET -p tcp -m multiport --dport $NAT_FORWARDING_TCP_PORT_TO_LAN -j ACCEPT
  
  #icmp
  $IPTABLES -A FORWARD -m state --state NEW -p icmp -j ACCEPT
  $IPTABLES -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
  

  
  
  Jetzt müssen wir noch im Client das Gateway einstellen.
  
  Linux
  #Wir setzen 10.0.0.1 als gateway für 192.168.99.0 fest.
  route add -net 192.168.99.0 netmask 255.255.255.0 metric 1 gw 10.0.0.1 tap
  
  Windows
  route add 192.168.99.0 mask 255.255.255.0 10.0.0.1 metric 1 -p
  
  Unter Windows sorgt -p dafür das es permanent ist, unter Linux kann sich das je nach Distribution unterscheiden.
  
  Das war's
  

Theoretische Absicherung eines WLAN-Netzwerks mit OpenVPN Top

Die WEP Verschlüsselung von WLAN-Netzwerken ist unsicher, und unbrauchbar, deshalb würde ich bei einem WLAN-Netzwerk auf jeden Fall auf OpenVPN ausweichen.

Ich würde das so aufbauen:

Ein Server mit einer WLAN-Karte, der als Accesspoint dient, dieser Server dient als NAT-Router zwischen dem internen, dem WLAN, und dem Internet-Netzwerk. Jeder PC würde in's Internet geroutet werden(optional, kann man auch weglassen ), aber alle Pakete, die in das interne oder in das WLAN-Netzwerk wollen, müssen vom VPN-Tunnel, der mit OpenVPN aufgebaut wird, kommen.

Clientspezifischer Zugriff Top

Es kommt oft vor, dass man für unterschiedliche Leute den Zugriff auf das Netzwerk regeln will.

Nehmen wir an, Sie haben drei Zugriffsklassen, Angestellte, Systemadministratoren, und Partnerfirmen. Sie wollen den Systemadministrator auf das gesammte Netzwerk routen, die Angestellten nur auf den Samba Server und die Partnerfirmen auf einen speziellen Server zugreifen können.

Die meisten Leute sind Angestellte, Sie bekommen die ganz normalen Regeln von der Server-Konfigurations Datei, d.h. sie sind in 10.0.0.0/24.

Der Administrator bekommt das Netzwerk 10.0.1.0/24. Und die Partnerfirma 10.0.2.0/24.

In der Server Konfiguration wird ganz normal die Option server benutzt, ausserdem müssen noch routen für die anderen Netzwerke erstellt werden:

Jetzt bekommt jeder normale Benutzer eine IP-Adresse von 10.0.0.0/24. Unsere "speziellen" Benutzer müssen noch mithilfe des common names vom Zertifikat spezielle Regeln bekommen, dazu gibt es den Befehl client-config-dir <Verzeichnis>.

Je nach common name vom Zertifikat wird jetzt die Konfiguration clients/<common name> aufgerufen.

Jetzt brauchen wir nur noch Dateien für die entsprechenden Benutzer erstellen:

ifconfig-push weißt den Clients eine virtuelle IP zu, die kann dann per routing auf die entsprechenden Server gerouted werden. Die erste IP-Adresse gibt 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.

OpenVPN über einen Proxy Server Top

In einigen Fällen ist es notwendig OpenVPN über einen proxy Server laufen zu lassen. Dazu gibt es einige Punkte zu beachten:

• Protokolle
  Die meisten Proxies erlauben nur TCP-Verbindungen, ein udp-tunnel ist deshalb nicht umsetzbar.

• Ports
  Die meisten Proxies erlauben nur eine begrenzte Anzahl an Ports, meist wird für SSL Verbindungen nur der HTTPS Port (443) freigehalten.

• Timeouts
  Nach zu langen Timeouts wird die Verbindung getrennt, es sollte deshalb mit keepalive regelmässig die Verbindung benutzt werden.

• Proxy-Parameter
  
  Es gibt eine Option für http-proxies:
  
  
  Code:
  
  
  --http-proxy server port [authfile] [auth-method]
  Connect to remote host through an HTTP proxy at address server and port port. If HTTP Proxy-Authenticate is required, authfile is a file containing a username and password on 2 lines, or "stdin" to prompt from console.
  auth-method should be one of "none", "basic", or "ntlm". 

Beispiele:

• Keine Authentifizierung:
  
  
  Code:
  
  http-proxy proxy.it.test 1080

• Base Authentifizierung:
  
  
  Code:
  
  http-proxy proxy.it.test 1080 stdin basic

• NTLM Authentifizierung
  
  
  Code:
  
  http-proxy proxy.it.test 1080 stdin ntlm

Weitere Optionen Top

• Verschlüsselung abstellen
  
  Mit dem Befehl cipher none können Sie in der Konfiguration die Verschlüsselung abstellen. Achten Sie darauf, dass Sie eine Passwortauthentizifierung haben, wenn Sie diesen Befehl nutzen.

• Passwort-Authentifizierung
  
  Mit dem Befehl auth-user-pass-verify <file> <option> können Sie eine Passwort-Authentifizierung beim Server einstellen.
  
  <option> kann entweder via-env (via Enviroment) oder via-file sein. Der Server ruft für die Authentifikation die Datei auf. Bei via-env wird eine Enviroment-Variable username und password angelegt, das Script <file> muss diese Datei überprüfen. Wenn Sie <option> als via-file wählen wird eine Datei erzeugt, die den Benutzernamen und die Datei enthält, der Dateiname wird <file> als erstes Parameter übergeben. Nach dem Aufruf von <file> wird die Datei wieder gelöscht.
  
  Falls der Exitcode der Datei 0 ist darf der Benutzer connecten, andernfalls darf er es nicht.
  
  Damit der Client den Benutzername und das Passwort abfragt, müssen Sie den Befehl auth-user-pass <file> beim Client benutzen. Der Parameter <file> ist optional, damit können Sie das Passwort und den Benutzernamen aus der Datei holen.
  
  Natürlich können Sie ihrem Zertifikat auch eine passphrase geben, dann wird jedesmal diese passphrase abgefragt.
  

• Sich mit mehreren Servern verbinden
  
  Wenn Sie mehrere Server benutzen wollen, können Sie einfach mehrere remote Befehle benutzen. Mit remote-random können Sie einen zufälligen Server auswählen lassen.

• Die Verbindung automatisch wiederherstellen
  
  Mit connect-retry <seconds> können Sie die Zeit angeben, nach der, nach einem Verbindungsabbruch, wieder versucht wird eine Verbindung aufzubauen. Mit connect-retry-max <n> können Sie einstellen wie oft das Versucht wird.

Probleme Top

• Verdacht das die Zertifikate falsch erstellt wurden
  
  Wenn Sie den Verdacht haben, dass der Fehler an den Zertifikaten liegt (ein Großteil der Fehler entsteht tatsächlich durch das falsche Erstellen von Zertifikaten), dann können Sie es mit den Beispielzertifikaten versuchen, die ich erstellt habe. Setzen Sie diese Zertifikate nur zu Testzwecken ein, ein Angreifer könnte sonst mit diesen Zertifkaten in ihr VPN eindringen. Einen Downloadlink finden Sie hier.
  
  Häufige Fehler beim Erstellen von Zertifikaten:
  
  
  • Doppelter Common Name
    Der Common Name muss bei jedem Zertifikat einzigartig sein. Vergewissern Sie sich, dass Sie nicht zwei Zertifikate benutzen die den gleichen Common Name benutzen.

  
  
  

  • Die tls-server Option
    Vergewissern Sie sich, dass Sie in den Client-scripts den Common Name des Serverzertifikats in der Option tls-remote <common name server> angegeben haben.

  
  

• 
  
  Quote:
  
  Socket bind failed on local adress [undef]:1194: Adress already in use.

  
  
  Diese Fehlermeldung bedeutet das der Port den sie für OpenVPN benutzen wollen (in diesem Fall 1194) schon von einem Programm belegt wurde. Entweder wurde OpenVPN schon gestartet, ein Programm das auf einen Server zugreift benutzt ihn, oder ein anderes Programm hat den Dienst an diesen Port gebunden.
  
  Sie müssen das Programm schließen, bevor sich OpenVPN an den Port hängen kann. Sie können auch einen anderen Port benutzen indem Sie im Script(auf dem Server und auf allen Clients) alle Ports auf einen neuen ändern.
  
  Der Befehl netstat -lnp --ip zeigt ihnen unter Linux die belegten Ports und das dazugehörige Programm an.
  
  Unter Windows lautet der Befehl mit den dazugehörigen Parameter netstat -ano. Allerdings wird nur die PID (Prozess ID) ausgegeben, das dazugehörige Programm finden Sie im Taskmanager. Starten Sie den Taskmanager, und gehen Sie auf den Reiter Prozesse. Hier sehen Sie alle Programme und die dazugehörige PID. Falls die PID nicht angezeigt wird, gehen Sie auf Ansicht->Spalte auswählen-> PID.
  

• Quote:
  
  Sun Oct 10 21:34:41 2006 Note: Cannot open TUN/TAP dev /dev/net/tun: No such file or directory (errno=2)
  Sun Oct 10 21:34:41 2006 Note: Attempting fallback to kernel 2.2 TUN/TAP interface
  Sun Oct 10 21:34:41 2006 Cannot allocate TUN/TAP dev dynamically

  
  
  Wenn man diese Fehlermeldung bekommt, fehlt meistens das tun/tap Modul. Versichern Sie sich, das Sie das Modul geladen, oder einkompiliert haben.
  
  Versichern Sie sich, das Sie die Option CONFIG_TUN (Device Drivers->Network Device Support>Universal TUN/TAP Device Driver Support) auf y oder Module gestellt und gegebenenfalls das Modul geladen haben.
  

• Probleme bei Routing
  Prüfen ob auf dem Gateway ip_forward aktiviert ist:
  
  Code:
  
  
  cat /proc/sys/net/ipv4/ip_forward
  0    # 1 = aktiv, 0 = deaktiviert
  
  # routing aktivieren mit:
  echo 1 > /proc/sys/net/ipv4/ip_forward
  

  
  
  Zusätzlich kann es noch in die Konfigurationdatei sysctl.conf eingetragen werden, damit die Option nach einen Neustart automatisch gesetzt wird.
  
  

  /etc/sysctl.conf:
  
  
  net.ipv4.ip_forward=1
  

  
  

Beispielkonfigurationen Top

• Tun Device, dass in das Netz 192.168.1.0/24 vom Server routed.
  
  
  Code:
  
  
  # OpenVPN 2.0 client.conf
  # Die Maschine ist Client
  client
  
  # UDP als Transportprotokoll
  proto udp
  
  # Routing-Modus mit /dev/tun
  dev tun
  
  # IP-Adresse oder FQDN des OpenVPN-Servers sowie Port 1194
  remote <IP vom Server> 1194
  
  # Unendlich versuchen, den Hostnamen des Servers zu ermitteln.
  # Hilfreich bei nur temporär mit dem Internet verbundenen Rechnern.
  resolv-retry infinite
  
  # Keine Bindung an lokale Portnummer
  nobind
  
  # Anonyme Benutzer/Gruppe nobody mit UID/GID 65534
  #user nobody
  #group nobody
  
  # Bei unerwartetem Verlust der Verbindung: Schlüssel behalten
  #und Interface nicht herunterfahren.
  persist-key
  persist-tun
  
  # Name und Pfad der Zertifikate/Schlüssel-Dateien
  ca certs/vpn-ca.pem
  cert certs/simon_lan_cert.pem
  key certs/simon_lan_key.pem
  
  # Kompression benutzen
  comp-lzo
  
  # Meldungen an Syslog mit Verbose-Level 3
  verb 3
  
  route 192.168.1.0 255.255.255.0 10.8.0.1
  
  # OpenVPN 2.0 server.conf
  
  # Explizites Setzten des Server-Ports
  port 1194
  
  # UDP als Transportprotokoll
  proto udp
  
  # Routing-Modus mit /dev/tun
  dev tun
  
  # Name und Pfad der Zertifikate/Schlüssel-Dateien
  ca certs/vpn-ca.pem
  cert certs/servercert.pem
  key certs/serverkey.pem
  
  # Schlüssellänge des Diffie-Hellman: 1024
  dh certs/dh1024.pem
  
  # VPN-Subnetz für Clients; Server benutzt 10.8.0.1
  server 10.8.0.0 255.255.255.0
  
  # Zuordnung von Client-IP-Adressen zu VPN-Adressen in ipp.txt
  #führen. Wichtig für Re-Connects.
  ifconfig-pool-persist ipp.txt
  
  # In ccd liegen Client-spezifische Konfigurationen
  client-config-dir ccd
  
  # Ein Ping ähnlicher Mechanismus prüft alle 10 Sekunden, ob die
  #Gegenseite noch da ist. Nach 120 Sekunden gilt die Verbindung als
  #getrennt.
  keepalive 10 120
  
  # Clients im selben Subnet können auch andere Clients sehen
  client-to-client
  
  # Kompression benutzen
  comp-lzo
  
  # Anonyme Benutzer/Gruppe nobody mit UID/GID 65534
  user nobody
  group nobody
  
  # Bei unerwartetem Verlust der Verbindung: Schlüssel behalten und
  #Interface nicht herunterfahren.
  persist-key
  persist-tun
  
  # Protokolliere alle momentanen Verbindungen
  status openvpn-status.log
  
  # Meldungen an Syslog mit Verbose-Level 3
  verb 3
  
  push "route 192.168.1.0 255.255.255.0"
  

• Eine Konfiguration für Notebooks, dass das VPN zum tunneln von Traffic aus unsicheren Netzwerken über den Server benutzt
  
  Code:
  
  
  #client.conf
  
  client
  float
  dev tap
  
  #MTU
  tun-mtu 1492
  #fragment 1300
  mssfix
  
  #device name, unter linux nicht mehr auskommentieren (# löschen)
  #dev-node OpenVPN
  
  #tcp oder udp
  #proto udp
  proto tcp
  
  #Server IP
  #Tunnelt über 443 da das in den meisten
  #Netzwerken erlaubt ist (Vorsicht -> 
  #teilweise Kündigungsgrund falls in der 
  # Netzwerk policy)
  remote <server> 443
  
  #force authentication
  tls-remote openvpn.open4free.org
  
  ca ca_cert_open4free.pem
  cert openvpn_cert_simon_hecht.pem
  key openvpn_key_simon_hecht.pem
  
  #PROXY
  #http-proxy <proxy> 8080
  
  auth SHA1
  #cipher aes-256-cbc
  nobind
  comp-lzo
  persist-key
  persist-tun
  verb 3
  
  #keep-alive 10 120
  
  # Default route ueber VPN
  
  #Neuer DHCP Server
  #dhcp-option DNS 195.58.160.194 
  route-gateway 10.0.0.1
  redirect-gateway
  
  #Ich will auf 172.20.1.43 über das 
  #lokale Netzwerk zugreifen
  #route 172.20.1.43 255.255.255.255 192.168.0.1
  
  #Beispiel Netz das über 10.0.0.1 gerouted wird, wegen default Netzwerk unnötig
  #route 62.2.100.201 255.255.255.255 10.0.0.1
  
  #server.conf
  
  # Port
  port 443
  
  # TCP oder UDP?
  proto tcp-server
  #proto udp
  mode server
  tls-server
  
  # tun oder tap?
  # Das tun Device erstellt einen IP Tunnel,
  # während das tap Device einen Ethernet Tunnel erstellt.
  #tun or tap device
  #tun is an IP tunnel,
  #tap an ethernet tunnel
  dev tap
  
  #Our Server IP
  ifconfig 10.0.0.1 255.255.255.0
  
  #dynamic clients from 10.0.0.2-10.0.0.254
  ifconfig-pool 10.0.0.2 10.0.0.254
  
  #Paths to the certs
  ca certs/ca_cert_open4free.pem
  cert certs/openvpn_cert_server.pem
  key certs/openvpn_key_server.pem
  
  #Diffie-Hellmann Parameters
  dh certs/dh2048.pem
  
  #Same Ip in the next session
  ifconfig-pool-persist ipp.txt
  
  #Routes the packages to the intern network, you should use iptables instead of $
  #push "route 192.168.0.0 255.255.255.0"
  
  #Tests the connection with a ping like paket. (wait=120sec)
  keepalive 3 120
  
  #Authenication
  auth SHA1
  
  #Our encryption algorithm
  #cipher aes-256-ecb
  #openvpn --show-ciphers for testing
  
  push "dhcp-option DNS 192.168.100.1"
  
  #comp
  comp-lzo
  
  #Sets new rights after the connection
  user nobody
  group nogroup
  
  #We need this because of user nobody/group nobody.
  persist-key
  persist-tun
  
  #Logging 0, (testing:5)
  
  verb 0
  

Weblinks Top

Die offizielle Dokumentation
www.mathematik.uni-marburg.de/~schmidtm/openvpn_slides.pdf
Ein Mini Howto
Ein gutes Tutorial
Ein wikiweb Tutorial
Ein Tutorial von Linux-Magazin.de
www.sans.org/rr/whitepapers/vpns/1459.php
www.netzmafia.de/skripten/sicherheit/sicher2.html
www.join.uni-muenster.de/Dokumente/Howtos/Howto_OpenVPN_Tunnelbroke...
www.sauff.org/blog/static.php?page=mtu-mini-faq#1

Gibt es noch irgendwelche Fragen, oder wollen Sie über den Artikel diskutieren?

Editieren Versionen Linkpartnerschaft Top Printversion

Haben Sie einen Fehler gefunden? Dann klicken Sie doch auf Editieren, und beheben den Fehler, keine Angst, Sie können nichts zerstören, das Tutorial kann wiederhergestellt werden

Sprachenübersicht/Betriebssysteme/Linux/Security/OpenVPN Tutorial