OpenVPN mit "dev tap" statt "dev tun" - wie kann man das einrichten?

GregorM

Benutzer
Mitglied seit
26. Apr 2011
Beiträge
12
Punkte für Reaktionen
0
Punkte
0
OpenVPN mit "dev tap" statt "dev tun" - wie kann man das einrichten?

Hallo Forum,

vielleicht hat jemand eine Idee, wie man folgendes in OpenVPN einrichten kann:

Möchte OpenVPN auf der DiskStation (aktuelle DSM und VPNCenter installiert) von dem Standard-Modus "dev tun" auf "dev tap" ändern, um über OpenVPN meine TimeCapsule (nicht die in DiskStation, sondern eine "echte") im Heimnetzwerk für Mac OS X Backups nutzen zu können:
http://davidatenney.wordpress.com/2010/07/20/timemachine-over-openvpn/

Habe dazu die Datei in /volume1/@appstore/VPNCenter/etc/openvpn/server.conf die Einstellung auf "dev tap" geändert und die DiskStation neu gestartet, da ich nicht wusste, wie ich den VPN-Dienst per Terminal neu starten könnte (weiß das jemand? oder reicht "Reset" in GUI aus?). Die openvpn.conf habe ich auch angepasst, damit diese dann die richtige Einstellung beinhaltet.

Leider funktioniert das nicht. Es ist weiterhin "dev tun" aktiv. Benutze allerdings nicht Tunnelblick sondern shimo für den Zugriff von meinem Mac aus, was aber kein Unterschied sein sollte. Dort kann ich bequem von "tun" auf "tap" umschalten. Wenn ich mich mit "tun" anmelde, dann komme ich auf die DiskStation drauf, mit "tap" leider nicht, obwohl die Verbindung aufgebaut wird.

Ich vermute, dass die Einstellungen in der DiskStation evtl. an anderer Stelle vorgenommen werden und die oben aufgeführte Stelle nur die Originaldateien beinhaltet.

Hat jemand eine Idee, wie man das OpenVPN auf "dev tap" umstellen kann?

Danke für jede Hilfe im Voraus.

VG,
Gregor
 

ubuntulinux

Benutzer
Mitglied seit
23. Jan 2010
Beiträge
2.063
Punkte für Reaktionen
0
Punkte
82
Hi und willkommen im Forum :)

Die Config wird meines Wissens nach bei jedem Reboot neu angelegt :( Somit bleibt dir glaubs nichts anderes übrig, als OpenVPN selber mit IPKG zu installieren.

Gruss
ubuntu
 

joku

Benutzer
Mitglied seit
06. Mrz 2011
Beiträge
6.664
Punkte für Reaktionen
2
Punkte
164
Habe dazu die Datei in /volume1/@appstore/VPNCenter/etc/openvpn/server.conf die Einstellung auf "dev tap" geändert und die DiskStation neu gestartet, da ich nicht wusste, wie ich den VPN-Dienst per Terminal neu starten könnte (weiß das jemand? oder reicht "Reset" in GUI aus?).
Hallo Gregor,
Im Packetzentrum
VPN-Server
Ausführen und Stop

oder Konsole
/volume1/@appstore/VPNCenter/scripts/openvpn.sh restart
und wegen dem device, schau mal in die openvpn.sh
ab Zeile 21
# Make device if not present

Gruß Jo
 

GregorM

Benutzer
Mitglied seit
26. Apr 2011
Beiträge
12
Punkte für Reaktionen
0
Punkte
0
Hallo Jo,
vielen Dank für die Infos. Ausführen und Stopp im Paketzentrum konnte ich nicht machen, da ich unterwegs war und per PPTP die OpenVPN Konfiguration vornehmen wollte. Damit hätte ich mich selber ausgesperrt. (Re-)Starten per Script ist genau die Lösung, die ich gesucht habe.

Noch eine Frage zu openvpn.sh: kann ich /dev/net/tun einfach gegen /dev/net/tap in dem Script austauschen? Können die Parameter einfach übernommen werden? Später kommt noch beim Stopping /sbin/rmmod tun. Vermute mal, dass man hier dann auch tap stoppen muss, oder?

Was ist mit der Aussage von ubuntulinux? Stimmt das, dass das Script jedes Mal überschrieben wird?

Gruß
Gregor
 

joku

Benutzer
Mitglied seit
06. Mrz 2011
Beiträge
6.664
Punkte für Reaktionen
2
Punkte
164

GregorM

Benutzer
Mitglied seit
26. Apr 2011
Beiträge
12
Punkte für Reaktionen
0
Punkte
0
Hallo Jo,
okay, habe das mal alles getestet, aber leider immer noch ohne Erfolg.
- /volume1/@appstore/VPNCenter/scripts/openvpn.sh => Änderung von tun auf tap vorgenommen
- /volume1/@appstore/VPNCenter/etc/openvpn/server.conf => dev tun auf dev tap
- /volume1/@appstore/VPNCenter/etc/openvpn/openvpn.conf => dev tun auf dev tap und persist-tun auf persist-tap geändert (dies dürfte ja nur für das heurnterladen der Konfig gelten und das Importieren in Tunnelblick)
- /dev/net/tun und /dev/net/tap sind vorhanden, bzw. mit ls sichtbar

Nach Restart klappt es aber immer noch nicht.

Dann habe ich mir openvpn.sh genauer angeguckt. Dort werden oben die Pfade definiert und CONF_DIR steht auf /usr/syno/etc/packages/VPNCenter/openvpn => openvpn.conf
dort habe ich dann auch dev tun auf dev tap und persist-tap geändert und log-append auskommentiert, aber leider finde ich das openvpn.log in /var/log nicht. OpenVPN startet jetzt auch nicht mehr. Ohne Log ist es echt schwer dahinter zu kommen, was ich falsch mache. Allerdings scheint die openvpn.conf in usr der richtige Weg zu sein, da der Dienst dann nicht mehr startet. Irgendwie scheint aber die Konfiguration mit der Ändeurng von tun auf tap nicht abgeschlossen zu sein. Oder ist das Package bei Synology ggf. nicht komplett, so dass man nur tun nutzen kann? Eine Idee, was ich noch machen könnte?

Vielen Dank für die Geduld und Hilfe im Voraus. Bin bei Linux/Unix nicht so fit, um an dieser Stelle selber weiter zu kommen...

Gruß
Gregor
 

joku

Benutzer
Mitglied seit
06. Mrz 2011
Beiträge
6.664
Punkte für Reaktionen
2
Punkte
164

GregorM

Benutzer
Mitglied seit
26. Apr 2011
Beiträge
12
Punkte für Reaktionen
0
Punkte
0
Hallo Jo,
okay, habe 1.1.2256 drauf. Hatte mit den Versionen vorher auch Probleme. Diese scheint endlich stabil zu laufen.
Das ipkg habe ich auch bereits drauf. Muss das mal heute Abend aktualisieren und openvpn daraus installieren. Wollte eigentlich den bequemen Weg über die GUI des DSM gehen und beim Standard bleiben. Grundsätzlich finde ich die Entwicklung des DSM super, aber bei solchen Spezialfällen stößt man leider immer wieder auf Probleme. Habe auch SSODS auf meiner 411+ laufen, da das Squeezebox Paket von Sysnology leider nicht alle Funktionen beeinhaltet... Aber das nur am Rande...
Bin schon sehr gespannt, ob sich das opnvpn aus ipkg auf tap umstellen lässt. Melde mich dazu noch einmal hier.
Danke schon einmal für die bisherige Hilfe.
Gruß
Gregor
 

GregorM

Benutzer
Mitglied seit
26. Apr 2011
Beiträge
12
Punkte für Reaktionen
0
Punkte
0
Hallo Jo,
ich glaube, dass ich tap nun mit dem Standard-Packet hinbekommen habe. Kann das aber leider nicht so einfach verifizieren und leider läuft meine TimeMachine auch nicht, wobei alle anderen Zugriffe super gehen. In Messages stand nur drin, dass persist-tap nicht bekannt ist, daher habe ich das wieder auf persist-tun umgestellt, aber mit dev tap oben in der Config. Shimo veribindet sich anstandslos mit der Einstellung tap. Als ich openvpn aus ipkg installieren wollte, habe ich in einem Wiki gelesen, dass man bei openvpn auch eine Route im Router (auf die 10.8.0.0, falls die in OpenVPN eingetragen ist) mit dem Ziel der DiskStation für dieses Netz eintragen muss. Macht auch irgendwie Sinn, damit der ganze Traffic über das Interface der DiskStation geleitet wird. Nach diesem Eintrag lief es dann mit tap.

Vielleicht hat schon jemand im Forum eine TimeCapsule bzw. TimeMashine per OpenVPN zum Laufen gebracht. Wäre über jeden Tipp dankbar.

Gruß
Gregor
 

joku

Benutzer
Mitglied seit
06. Mrz 2011
Beiträge
6.664
Punkte für Reaktionen
2
Punkte
164
Hallo Gregor,

das sieht ja ganz gut aus :)
Lassen wir uns überraschen ob Du der erste bist oder schon wer was zu laufen gebracht hat.

Gruß Jo
 

GregorM

Benutzer
Mitglied seit
26. Apr 2011
Beiträge
12
Punkte für Reaktionen
0
Punkte
0
Hallo,
man muss einige Sachen einfach nur besser lesen... In meinem ersten Link zu TimeMachine wird auf ein Zusatzprogramm avahi verwiesen, was die Broadcasts auch über das VPN Netz schickt, wenn ich das richtig verstanden habe. In ipkg ist es auch drin, so dass ich das mal installieren werde. Aber heute ist mir das schon zu spät...
Werde berichten, ob das die Lösung ist.
Gruß
Gregor
 

madeda

Benutzer
Mitglied seit
11. Mrz 2012
Beiträge
4
Punkte für Reaktionen
0
Punkte
0
Hallo Gregor

Hallo Jo,
Als ich openvpn aus ipkg installieren wollte, habe ich in einem Wiki gelesen, dass man bei openvpn auch eine Route im Router (auf die 10.8.0.0, falls die in OpenVPN eingetragen ist) mit dem Ziel der DiskStation für dieses Netz eintragen muss. Macht auch irgendwie Sinn, damit der ganze Traffic über das Interface der DiskStation geleitet wird. Nach diesem Eintrag lief es dann mit tap.

Wo genau hast Du diese Route eingetragen? Im Router?

Gruß madeda
 

GregorM

Benutzer
Mitglied seit
26. Apr 2011
Beiträge
12
Punkte für Reaktionen
0
Punkte
0
Hallo,

ja im Router.
Bildschirmfoto 2012-09-25 um 17.38.37.png

192.168.10.6 ist meine Synology.

Damit geht es auf jeden Fall, sowohl mit tun und der Standardkonfiguration, und auch mit tap mit den oben beschriebenen Änderungen.
Habe leider noch keine Zeit gehabt, das kleine avahi zu installieren und es mal auszuprobieren. Habe das aber nicht vergessen und werde es demnächst mal angehen.

Gruß
Gregor
 

madeda

Benutzer
Mitglied seit
11. Mrz 2012
Beiträge
4
Punkte für Reaktionen
0
Punkte
0
Hallo Gregor,

das ging ja schnell :)

Ich verstehe das nicht ganz. Du möchtest also, dass alle Anfragen im Heimnetz an 10.8.0.0 (z.B. von der Time Capsule) die den Router als Standard Gateway erreichen an die Synology weitergeleitet werden? Wo hattest Du den diesbezüglichen Hinweis im Wiki gefunden?

Bei mir funktioniert das nämlich ohne einen solchen Routing Eintrag, zumindest zum Teil. Mir geht es (zunächst) nicht um die Time Machine sondern um UPNP und/oder Itunes Server. Und siehe da: Itunes erkennt den Server nun über VPN. Leider macht das aufgrund der Menge an Dateien offenbar keinen Sinn, da I-Tunes das gesamte Musik Archiv öffnet und sich tot lädt. UPNP/DLNA ist hier etwas strukturierter und bietet Die Abfrage von Teilbäumen der Library, z.B. nach Ordnern oder Interpreten.

UPNP/DLNA funktioniert aber immer noch nicht.

Irgendwie wird hier Routing und Bridging vermischt. Das entfernte TAP Device sollte imho nun eine lokale Adresse aus dem Heimnetz haben und nicht eine aus 10.8.0.0 die gerostet oder per NAT umgeschrieben wurde. Da Bridging auf OSI Layer 2 also Ethernet abläuft sollte der Client sogar seine Adresse vom Heimnetzt DHCP Server erhalten der vermutlich auch bei Dir auf dem Router ist.

Gruß madeda
 

ubuntulinux

Benutzer
Mitglied seit
23. Jan 2010
Beiträge
2.063
Punkte für Reaktionen
0
Punkte
82
Normalerweise wird auf der DS genattet. Man kann also nicht von einem PC im LAN auf einen VPN Client zugreifen. Wenn die Route vorhanden ist, kann man das.
 

GregorM

Benutzer
Mitglied seit
26. Apr 2011
Beiträge
12
Punkte für Reaktionen
0
Punkte
0
Ich meine, dass VPNs immer ein anderes Netz haben (müssen). Auch das lokale und das Zielnetz sollten in zwei unterschiedlichen Netzen sein, damit man vernünftig routen kann.
Bei der Forderung zu UPNP müsste im Prinzip das gleiche erfüllt sein, wie bei der TimeCapsule, nämlich, dass alle Pakete (auch Broadcasts) im Netzwerk auch über den Tunnel geschickt werden, wenn ich das richtig verstanden habe. Dann wird der UPNP Server nämlich auch von den Zielgeräten erkannt. Wenn ich das alles richtig verstanden habe, dann werden die Broadcasts mit dem kleinen Tool avahi dann aus dem lokalen Netz über das VPN zum Zielnetz geschickt. So reime ich mir das zusammen... Bin da jetzt auch kein Profi, auch wenn ich das eine oder andere hinbekomme...
 

madeda

Benutzer
Mitglied seit
11. Mrz 2012
Beiträge
4
Punkte für Reaktionen
0
Punkte
0
Hallo Gregor, ubuntulinux

das ist das was ich meinte: Bridging und Routing wird vermischt.

Hier gehts doch darum von Layer3 Tunneling auf IP Ebene auf Layer 2 Tunneling auf Ethernet Ebene umzusteigen. Das Tun Device ist ein virtuelles Netztwerkinterface auf Layer 3 Ebene. Wenn ich über dieses tunnele muss ich routen, und dabei befinden sich Start und Endpunkt in 2 verschiedenen Subnetzen. Dann macht eine statische Route im auf dem Standard Gateway des Heimnetzes tatsächlich Sinn, damit Pakete aus dem Heimnetz ins VPN finden.

Mit dem Wechsel auf das Tap Device versuche ich ein VPN im Bridging Mode aufzubauen (und das war der Grund weshalb ich diesen Post gefunden und verfolgt habe :). Dabei befinden sich Start und Ende des Tunnels im gleichen Subnetz, mit 2 verschiedenen IPs natürlich. Etwas tricky ist dabei die Vergabe der IP auf dem entfernten Rechner. Entweder lasse ich DHCP aus dem Heimnetz in den VPN Tunnel "durchrufen" oder OpenVPN macht sein eigenes DHCP für den Tunnel, wobei sich diese Adressen nicht mit denen aus dem heimischen DHCP Server überschneiden dürfen. Fazit: Wenn Bridging per Tap richtig läuft ist es nicht mehr notwendig zu routen, da kein unterschiedliches Subnetz verwendet wird.

Wozu das Ganze: Damit wird der entfernte Rechner quasi zum Bestandteil des Heimnetzes, und zwar nicht weil durch den Tunnel IP Pakete geroutet werden, sondern weil Ethernetframes auf MAC Adressebene ihren Weg durch den Tunnel finden soll(t)en. Hilfreich ist das für alle Dinge die klassischerweise nicht ohne weiteres geroutet werden, wie z.B. Broadcast oder Multicast IP Traffic. Und hier treffen sich unsere Interessen: Die TimeCapsule nutzt wie UPNP/DLNA Broadcasts.

@ubuntulinux: Wo gibt es einen Zusammenhang mit NAT? Routing bedeutet nicht gleichzeitig NAT. Ein NAT erfolgt in der Regel nur bei einem Wechsel (per Routing) aus privaten in öffentliche Netze. Wieso meinst Du die Synology Kiste macht auch ein Nat/Masquerading beim VPN Routing? Auszuschliessen wäre es nicht aber mir erschliesst sich der Sinn nicht (vielleicht genau wegen der Routing Problematik?**) Bei einem tatsächlichen Layer2 VPN gibt's aber sicher kein NAT, da kein Routing.

So, genug für heute. Es macht auch mehr Sinn das zu testen wenn man zu Hause vor der Kiste sitzt statt im Hotelzimmer, wo man sich ständig durch Fehlversuche aussperrt. Und SWMBO ist schon leicht gereizt vom ständigen Bitten wg. Neustarten der Syno :))

** Also dazu fällt mir dann doch noch etwas ein: Die Syno ist nicht der klassische Endpunkt eines Tunnels, der befindet sich sonst nämlich auf dem Router und hat eine öffentliche IP Adresse. Um mit der Syno VPN zu machen wird daher auf dem Router ein Port weitergeleitet. Nun fallen aus der Syno Pakete ins lokale Netz für irgendeinen dortigen Client. Wenn dieser antwortet wird er diese Antwortpakete (da der Ursprung in einem anderen Subnetz liegt) ans Standard Gateway schicken (also an den Router). Hier greift die Geschichte mit der statischen Route auf dem Router, der diese Pakete zurück an die Syno schickt, die diese dann in den Tunnel weiterreicht. Die Synology ist nämlich der einzige im Netz der etwas mit der entfernten IP 10.8.0.0 anfangen kann.

Irgendwie klappt aber VPN für gewisse Anwendungen per Default auch ohne diese statische Route, und da könnte ein NAT greifen: Macht die Synology ein NAT, werden die Pakete aus dem Tunnel mit einer neuen Absenderadresse versehen, nämlich der IP der Syno. Die Syno merkt sich zu diesem Paket aber, wo aus dem Tunnel es hergekommen ist. Nun kommt das Paket zum Client im Heimnetz, wird verarbeitet und die Antwort wird an die Syno geschickt. Mit der gemerkten IP kann die Syno das NAT quasi rückgängig machen und schiebt das Paket mit der original IP in den Tunnel. So etwa macht das Sinn.

Das Nat funktionert natürlich nur für Pakete die initial vom entfernten Client kamen und im Heimnetz beantwortet wurden und zurückgeschickt werden. Wird eine Verbindung initial aus dem Heimnetz aufgebaut hat sich die Syno ja nichts gemerkt und kann kein Revers-Nat machen. Geschweige denn weiß ein Heimnetz Client, dass sich ein VPN Client mit 10.8.0.x hinter der Synology verbirgt. Und da greift die statische Default Route.
Bei einem VPN das auf dem Roter terminiert ist das wurscht, da Router==VPN Endpunkt==Standardgateway im lokalen Netz.

Aber wie gesagt: Das alles sollte keine Rolle spielen bei einem Layer2 Tunnel.

So, viel geschrieben, aber funktionieren tut's immer noch nicht. Mein remote TAP hat eine IP aus dem Heimnetz, die Pakte werden aber nicht dorthin geschoben. Zunächst sieht es so aus als habe ich auf dem Remote Client nun auch dazu die falschen Routen. Merkwürdig.

2 Sachen die ich gerne noch hinterfragen würde, vielleicht weiß ja jemand etwas:
- Ich habe gelesen die Syno können kein TAP, die Kernel Unterstützung würde fehlen. An anderer Stelle finde ich den gegeteiligen Hinweis, das (singemäss) ein TUN Device meist auch TAP Device kann. Und irgendwie funktioniert das ja mit den Änderungen von Gregor
- Ich habe Teile hiervon http://openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethernet-bridging.html mit in meine Versuche eingebaut. Die "server-bridge" Directive funktioniert auch. Damit hört es aber auf: Das start Script tut so nicht, bridge-utils gibt es nicht und kenne ich nicht, und die Erläuterungen unter "Ethernet Bridging Notes" verstehe ich auch nur zum Teil. Kann jemand damit etwa s anfangen?

Viele Grüße
madeda
 

madeda

Benutzer
Mitglied seit
11. Mrz 2012
Beiträge
4
Punkte für Reaktionen
0
Punkte
0
So, habe die bridge-utils mal installiert, gab's als ipkg package. Hilft aber nix: brctl addbr bringt eine Fehlermeldung "add bridge failed: Package not installed". Komisch, brctl funktioniert nämlich grundsätzlich. Welches Package soll denn da fehlen. Dochn irgendeine Kernelunterstützung ...

Gruß madeda
 


 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat