OpenVPN ds-mod Package

In den aktuellen Versionen des ds-mod ist OpenVPN 2.1 enthalten. Es kann im menuconfig wahlweise mit und ohne LZO Komprimierung ausgewählt werden.

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
http://openvpn.net/howto.html

Viele hilfreiche Informationen zu OpenVPN findet man auch gleich hier im Wiki unter openvpn.

Dies ist eine (sicher nicht ganz vollständige) Anleitung zur Konfiguration des OpenVPN ds-mod Package. 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.

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 zwei 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. Oder man editiert die Datei “/var/flash/ar7.cfg“, wozu der Zugriff auf die Box mit Telnet/SSH nötig ist, was jedoch mit dem ds-mod 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 /tmp/ar7.cfg gesucht werden mit /MeineFreigabe.

cat /var/flash/ar7.cfg > /tmp/ar7.cfg
vi /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 /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.

Ganz neu: Mittels dieses Patches wird in Zukunft auch eine Freigabe über die „normale“ Portfreigabe in der AVM-GUI auf die Box selbst mit 0.0.0.0 möglich sein.

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:

Eine 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

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 Them Public Key Infrastructure. Die Zertifikate werden auch mit Hilfe der GUI auf die Box geladen werden. Dafür öffnet man im DS-Mod 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 DS-Mod 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 > /tmp/flash/security && modsave

Zuordnung der Schlüssel und Zertifikate auf der Box:

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.

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
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.

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: http://openvpn.net/faq.html#bridge2

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 > /tmp/ar7.cfg
vi /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 /tmp/ar7.cfg > /var/flash/ar7.cfg
reboot

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

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

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 "Rudi-Shell" (wenn openvpn nicht mehr läuft):

  cat /mod/etc/openvpn*.conf | grep -v daemon > /var/tmp/ovpn.conf
  openvpn /var/tmp/ovpn.conf &
  sleep 10
  killall openvpn

  Das sollte (spätestens nach zehn Sekunden) die Startmeldungen und damit Hinweise auf den Fehler bringen.

• 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:
  - Nutzung der IP-Adresse, also \\192.168.178.12\meine_Daten
  - 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

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