Wiki:packages/openvpn

Version 10 (geändert von MaxMuster, vor 7 Jahren) (Diff)

Fix sample client config not matching screenshot cipher setting

OpenVPN freetz Package

OpenVPN ist ein Programm zur Herstellung eines Virtuellen Privaten Netzwerkes (VPN) über eine verschlüsselte TLS-Verbindung.

Version

In den aktuellen Versionen des freetz ist OpenVPN 2.1_rcXX (rc=ReleaseCandidate) enthalten. Es kann im menuconfig wahlweise mit und ohne LZO2 Komprimierung ausgewählt werden.

Häufige Fragen / Howto

Die Dokumentation auf der OpenVPN Webseite ist sehr gut und ausführlich. Dort findet man wohl auf die meisten Fragen die passende Antwort.

http://openvpn.net/faq.html oder http://openvpn.net/howto.html

Viele hilfreiche Informationen zu OpenVPN findet man auch hier im ippf-Wiki.

Konfigurationsanleitung

Dies ist eine (sicher nicht ganz vollständige) Anleitung zur Konfiguration des OpenVPN Pakets. Sie soll aufzeigen, wie man eine OpenVPN Konfiguration mit der zugehörigen GUI erstellt. *Was* ein VPN ist und welche Parameter man grundsätzlich braucht, kann hier *nicht* gefunden werden.

Portweiterleitung

Soll (was wohl meistens der Fall ist), die Verbindung auf die Box über das Internet aufgebaut werden, so muss dafür eine "Portweiterleitung" eingerichet werden, damit die Box die VPN-Pakete annimmt. Standardmäßig nutzt OpenVPN den IP-Port 1194 mit UDP oder TCP, und die Pakete dafür müssen von der Box angenommen werden. Die naheliegende Idee, dieses in der Fritzbox GUI einzurichten wird von AVM unterbunden, indem keine Weiterleitungen "auf die Box selbst" erlaubt werden. Prinzipiell gibt es drei Möglichkeiten, das zu "umgehen":

  1. Indem die Box eine zusätzliche IP-Adresse bekommt, von der die GUI "nichts weiss" und damit die Einrichtung über die GUI vornehmen. Dafür kann das Paket Virtual IP genutzt werden und dann in der GUI eine Weiterleitung auf diese IP eingerichtet werden. Mittlerweile gibt es einige User, die damit Probleme gemeldet haben (vermutlich wegen der "Startreihenfolge" der Pakete). Als Alternative dazu bietet es sich an, in der debug.cfg eine weitere IP anzulegen (zum Beispiel mittels des Eintrags "ifconfig lan:1 192.168.178.253" in dieser Datei).
  2. Man verwendet das Freetz-Paket avm-firewall. Hierdurch kann man einfach im Freetz-GUI eine Portweiterleitung auf die IP-Adresse 0.0.0.0 eintragen. Anschließend ist der Port vom Internet aus offen (Achtung: UDP als Protokoll auswählen!).
  3. Oder man editiert die Datei "/var/flash/ar7.cfg", wozu der Zugriff auf die Box mit Telnet/SSH nötig ist, was jedoch mit freetz kein Problem darstellt. Obwohl diese Methode etwas "risikoreicher" ist ( weil eine "falsch editierte Datei" den Start der Box verhindern kann) würde ich sie empfehlen.

Ich würde vorschlagen, die Datei im RAM zu editieren und dann, wenn alles "zufriedenstellend" erfolgt ist, die Datei zurück zu kopieren. Zum "Kopieren" nutzt man hier das "Auslesen und Umleiten", da diese Datei keine normale Datei ist. Die Stelle, an der man ändern muß, findet man am einfachsten, indem man zuvor in der AVM-GUI unter Einstellungen → Erweitertet Einstellungen → Internet → Portfreigabe → Neue Portfreigabe eine aussagekräftige Portfreigabe erstellt, z.B. "MeineFreigabe". Diese kann in der im vi geöffneten /var/tmp/ar7.cfg gesucht werden mit /MeineFreigabe.

  cat /var/flash/ar7.cfg > /var/tmp/ar7.cfg
  vi /var/tmp/ar7.cfg

  # Mini-Anleitung zu vi: 
  # i  Insert  - an dieser Stelle etwas eingeben
  # a  append  - nach dieser Stelle etwas eingeben
  # o          - Zeile nach der aktuellen Zeile einfügen
  # O          - Zeile vor der aktuellen Zeile einfügen
  # /<Ausdruck>- Suche vorwärts nach Ausdruck
  # A  Append  - am Ende der Zeile etwas eingeben
  # r  replace - den Buchstaben unter dem Cursor ersetzen
  # x  delete  - den Buchstaben unter dem Cursor löschen
  # <Zahl>     - den nächsten Befehl so oft ausführen (z.B. 10x -> 10 Zeichen löschen)
  # dd         - Zeile Löschen
  # D          - Rest der Zeile ab aktuellem Zeichen löschen
  # <ESC>      - Editier- / Eingabe-Modus verlassen
  # :w  write  - Änderungen Speichern
  # :q  quit   - vi verlassen
  # :q!        - vi verlassen, auch wenn ungesicherte Änderungen waren
  #
  #
  # Hier nun im vi die Freigabe eintragen und die Datei mit ":wq" abgespeichert

  # Wenn alles richtig war, kann diese neue Datei zurückgeschrieben werden:
  cat /var/tmp/ar7.cfg > /var/flash/ar7.cfg

Im Ergebnis muss zu den "forwardrules" eine der folgenden Art hinzugefügt werden, natürlich mit dem richtigen Protokoll (TCP/UDP) und der richtigen Port-Nummer. Zu beachten ist, dass die Zeilen mit "," abzuschließen sind, die letzte Zeile mit ";":

  ## falls es **nicht** die letzte Zeile ist so, 
  ## wenn es **die letzte** ist, bitte ein ";" statt des ","
  "udp 0.0.0.0:1194 0.0.0.0:1194" ,

Das Format dafür ist: <Protokoll> <In IP>:<In IP-Port> <Out IP >:<Out IP-Port> Hier ist das erste "0.0.0.0" jeweils alles eingehende das zweite "0.0.0.0" steht für "die Box selbst". Der "ausgehende" Port ist hier wie der eingehende der Standardport von OpenVPN: 1194.

Nach dem Editieren der ar7.cfg muss die Änderung übernommen werden, z.B. mittels ar7cfgchanged oder einem Reboot.

Relativ neu: Mittels dieses Patches ist auch eine Freigabe über die "normale" Portfreigabe in der AVM-GUI auf die Box selbst mit 0.0.0.0 möglich.

Static Key

Die einfachste Variante ist der Betrieb mit statischem Schlüssel:

  • es kann sich immer ein Client gleichzeitig mit dem Server verbinden
  • beide Seiten verwenden den selben statischen Schlüssel zur Authentifizierung
  • beim ersten Start des Dienstes wird ein Schlüssel automatisch erzeugt
  • Der Schlüssel kann unter "Einstellungen → Static Key" ausgelesen und eingestellt werden
    (eventuell vorher die Sicherheitsstufe einstellen)
  • die IP-Zuweisung erfolgt manuell auf Client und Server

Hier mal ein Beispiel mit folgenden Daten:

  Server-IP 192.168.200.1
  Client-IP 192.168.200.2
  Netzwerk hinter Fritzbox 192.168.178.0/255.255.255.0

In der GUI wäre der Server dann so zu konfigurieren:

OpenVPN Webinterface: static server OpenVPN Webinterface: static server

Eine passende Windows-Client-Konfiguration dazu, die sich auf die Box verbinden kann:

  remote meinserver.dyndns.org
  proto udp
  dev tun
  ifconfig 192.168.200.2 192.168.200.1
  route 192.168.178.0 255.255.255.0
  secret "D:\\Eigene Dateien\\OpenVPN\\fritzbox.key"
  tun-mtu 1500
  float
  mssfix
  nobind
  verb 3
  keepalive 10 120

Zertifikate

Wenn man mehrere gleichzeitige Verbindungen ermöglichen will, muss man mit Zertifikaten arbeiten.

  • es können sich mehrere Clients gleichzeitig mit dem Server verbinden
  • Zertifikate müssen erstellt und auf Server und Client hinterlegt werden
  • Die Zertifikate werden über "Einstellungen" eingetragen (Zuordnung siehe weiter unten)
  • die IP-Zuweisung erfolgt dynamisch durch den Server
  • einfache Konfiguration der Clients durch Push/Pull

Wie man ganz einfach Zertifikate erstellen und auf die Box laden kann, erklären u.a. dieser Wiki-Eintrag sowie die offizielle OpenVPN Hilfe zum Thema Public Key Infrastructure. Die Zertifikate werden auch mit Hilfe der GUI auf die Box geladen werden. Dafür öffnet man im Freetz das Menu Einstellungen und wählt den entsprechenden Eintrag aus (z.B. OpenVPN: Box Cert). Mit einem Editor öffnet man nun die entsprechende Datei (z.B. Server.crt) und kopiert den Inhalt in das Freetz Fenster. Mit Übernehmen überträgt nun die GUI das Zertifikat auf die Box.
Hinweis: Bevor man unter "Einstellungen" Dinge eintragen kann, muss man ggf vorher die Sicherheitsstufe entsprechend ändern, das geht z.B. mit

echo 0 > /var/tmp/flash/security && modsave

Zuordnung der Schlüssel und Zertifikate auf der Box:

GUI-Name Datei-Name Beispiel / Bemerkung
Box Cert <Name>.crt server.crt od. client01.crt
Private Key <Name>.key server.key oder client01.key
CA Cert ca.crt Zertifikat der CA
DH Param dh<Länge>.pemdh1024.pem od. dh2048.pem
Static Key wird generiert muss auf Server und Client gleich sein
CRL leer lassen Liste zurückgezogener Zertifikate

In der folgenden Beispiel-Konfiguration soll der Server auf der Box mit mehreren Clients genutzt werden können und im TAP-Modus laufen. Die meiste Konfiguration der Clients (IP- und Netzwerkeinstellungen, Routing, usw.) erfolgt ebenfalls durch den Server.
Der Server vergibt an die Clients IP-Adressen ab der 192.168.200.100 bis 192.168.200.150. Er übergibt dem Client auch eine Route zu seinem LAN, dem Netz 192.168.178.0. Für das "Abholen" dieser Parameter sorgt das pull in der Client-Konfiguration.

OpenVPN Webinterface: certificate serverOpenVPN Webinterface: certificate server

Ebenfalls wieder eine Client-Konfiguration dazu, die sich mit diesem Server verbinden könnte:

  remote meinserver.dyndns.org
  proto udp
  dev tap
  tls-client
  ns-cert-type server
  ca "D:\\Eigene Dateien\\OpenVPN\\ca.crt"
  cert "D:\\Eigene Dateien\\OpenVPN\\client.crt"
  key "D:\\Eigene Dateien\\OpenVPN\\client.key"
  tls-auth "D:\\Eigene Dateien\\OpenVPN\\static.key" 1
  tun-mtu 1500
  mssfix
  nobind
  pull
  cipher AES-128-CBC
  verb 3

Dass der Name des Servers (hinter "remote") und die Pfade zu den Zertifikaten ggf. anzupassen sind, versteht sich hoffentlich von selbst ;-). Man sieht, dass der Client keine eigene IP Konfiguration oder Routing Einträge hat, diese Parameter bekommt er mit dem pull vom Server.

Routing vs. Bridging

Für die meisten Anwendungsfälle ist Routing (TUN) die beste Wahl, doch in einigen Fällen kann es auch sinnvoll sein, das VPN Netzwerk mit einer Brücke (TAP) zu realisieren. Eine ausführliche Beschreibung der Unterschiede findet man auf der OpenVPN Webseite

Hier ein paar Vorteile von Bridging:

  • Der Client befindet sich nach Aufbau der Verbindung im gleichen Netz wie der Server
  • Broadcasts werden durch den VPN-Tunnel geleitet, das hat den Vorteil, dass z.B. NetBIOS Namen aufgelöst werden können (sinnvoll für PING, Netzwerkfreigaben etc)
  • Bridging leitet alle Ethernet-Protokolle über den Tunnel (IPv4, IPv6, IPX, AppleTalk etc.)

Hier ein paar Nachteile von Bridging:

  • weniger effizient als Routing (langsamer)
  • alle Broadcasts gehen durch das Netz

Um mit der Fritz Box ein echtes Bridging zu realisieren, ist es notwendig, den tap0-Adapter in die Liste der gebrückten Adapter der Fritz Box einzutragen. Dies geschieht wiederum in der ar7.cfg, die im oben beschriebenen Verfahren geändert werden muß. Unter dem Punkt "brinterfaces" → interfaces muß der tap0-Adapter ergänzt werden:

Also wieder:

  cat /var/flash/ar7.cfg > /var/tmp/ar7.cfg
  vi /var/tmp/ar7.cfg

Dann suchen nach /brinterfaces und den Eintrag "tap0" vor dem Semikolon einfügen.

  brinterfaces {
                name = "lan";
                dhcp = no;
                ipaddr = 192.168.178.1;
                netmask = 255.255.255.0;
                dstipaddr = 0.0.0.0;
                interfaces = "eth0", "usbrndis", "tiwlan0", "wdsup0", 
                             "wdsdw0", "wdsdw1", "wdsdw2", "wdsdw3", "tap0";
                dhcpenabled = yes;
                dhcpstart = 192.168.178.20;
                dhcpend = 192.168.178.100;

Zum Abschluß noch mal

  cat /var/tmp/ar7.cfg > /var/flash/ar7.cfg
  reboot

Die Konfiguration in der OpenVPN-Gui könnte für den FritzBox Standard dann folgendermaßen aussehen:

OpenVPN Webinterface: bridged serverOpenVPN Webinterface: bridged server

Die Windows-Client-Konfiguration dazu sieht so aus:

  client
  dev tap
  #udp/tcp je nachdem, was ausgewählt wurde
  proto tcp
  #Port entsprechend der Konfiguration
  remote meinserver.dyndns.org 443
  nobind
  persist-key
  persist-tun
  #hier die Zertifikate/Schlüssel, wie beim Erstellen benannt
  ca ca.crt
  cert client01.crt
  key client01.key
  # für TLS-Remote "ServerBox1" wie beim Erstellen benannt
  tls-remote ServerBox1
  tls-auth static.key 1
  auth SHA1
  cipher AES-256-CBC
  comp-lzo
  verb 3

Ein paar Tips wenn es nicht gleich so klappt

Meist versucht man gleich den schwierigsten Fall, über das Internet mit Zertifikaten und TLS-Authentifizierung zwei Netze zu verbinden und testet, indem man versucht eine Freigabe auf dem Fileserver im anderen Netz anzubinden ;-).

Schön, wenn es sofort klappt, dafür gibt es "unendlich" viele Fehlermöglichkeiten falls nicht…

Daher der Apell, tastet euch langsam an das ganze heran!

  • Erster "Fehlerkandidat" ist der Zugang über das Internet, der über eine "virtuelle IP" oder in der Datei "/var/flash/ar7.cfg" freigeschaltet werden muss (siehe oben, ich bevorzuge persönlich die zweite Methode). Diesen Faktor kann man prüfen, indem man die Verbindung zunächst mal "intern" testet, also über die LAN-Schnittstelle. Klappt es so, aber nicht über das Internet, habt ihr den Fehler eingegrenzt.
  • Wenn es was anderes ist, hilt nur noch der Vergleich der Konfigurationen Punkt für Punkt. Eigentlich gibt es nur zwei Arten von Parametern:
    Solche, die identisch sein müssen und solche, die "spiegelverkehrt" auftreten müssen.
    • Die "identischen" sind z.B. Cipher, "comp-lzo", tls-auth, das benutzte Protokoll (UDP/TCP) und der Port,
    • "Spiegelbildlich" sind die IPs beim TUN, die Routing-Einträge, die Server- / Client-Parameter wie "tls-server/tls-client", push und pull.
  • Die Config auf der Box kann man am einfachsten in der Rudi-Shell ausgeben lasssen, indem man dort
    cat /mod/etc/openvpn*.conf
    ausführt. Diese Config kann man dann gut mit der Config der "Gegenseite" vergleichen.
  • Erste Hilfe für mehr Infos, z.B. wenn die Ausgabe nur lautet
    Starting OpenVPN …failed.
    In der Rudi-Shell (wenn openvpn nicht mehr läuft) sollten so (spätestens nach zehn Sekunden) die Startmeldungen Hinweise auf den Fehler bringen.:
      cat /mod/etc/openvpn*.conf | grep -v daemon > /var/tmp/ovpn.conf
      openvpn /var/tmp/ovpn.conf &
      sleep 10
      killall openvpn
    
  • Und noch ein Hinweis für die "Windows-Nutzer": Wenn der Rechner, der eine Freigabe hat, nicht im gleichen Netz ist (also zum Beispiel über VPN verbunden ist), muss zum einen die Firewall Zugriffe aus einem anderen Netz zulassen zum anderen funktioniert die Windows Namensauflösung nicht. Kann man im LAN die Freigabe in der Art
    Der_PC_mit-Freigabe\meine_Daten

    nutzen, so ist das über das VPN nicht möglich. Es gibt dann zwei Möglichkeiten:
    1. Nutzung der IP-Adresse, also
      192.168.178.12\meine_Daten
    2. Nutzung der Datei <Windowsverzeichnis>\system32\drivers\etc\lmhosts, in die man Rechnername und IP einträgt. Dann kann die Freigabe weiterhin über den Namen genutzt werden

Verschlüsselung: Welcher "Cipher" ?

Der Verkehr zwischen Client und Server wird normalerweise verschlüsselt übertragen, um die Inhalte vor dem Ausspähen zu schützen. Die Wahl des Verschlüsselungsalgorithmus erfolg über die "Cipher" Auswahlbox. Momentan sind dort diese Cipher wählbar, in Klammern jeweils die OpenVPN Bezeichnung, wie sie aus dem OpenSSL übernommen wurde:

Blowfish (BF-CBC)
AES 128 (AES-128-CBC)
AES 256 (AES-256-CBC)
Triple-DES (DES-EDE3-CBC)

Um die Frage der durch die Verschüsselung erzeugte Last auf der Box nachzugehen, habe ich mal mit openssl speed des aes blowfish einen "Leistungsvergleich" der Verfahren auf einem Speedport 701 gemacht (nur für die wählbaren Optionen):

available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: times
The 'numbers' are in 1000s of bytes per second processed.
type              16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
des cbc           1827.26k     1909.78k     1931.44k     1935.13k     1888.51k
blowfish cbc      2940.90k     3187.67k     3257.75k     3245.84k     3108.06k
aes-128 cbc       1936.58k     1984.45k     2019.82k     2004.45k     1940.50k
aes-256 cbc       1500.48k     1532.26k     1541.70k     1510.14k     1494.16k

Man sieht, dass von den verfügbaren Algorithmen "Blowfish" den größten Durchsatz hat. Bei intensiver Nutzung könnte das von Interesse sein. Für tiefergehende Vergleiche der Algorithmen sei z.B. auf Wikipedia verwiesen.

Diskussion

Fragen und Anmerkungen zu diesem Paket werden in diesem Thread diskutiert.