NAS nicht erreichbar bei aktivierter VPN Verbindung

mike69

Nein.

Nur wenn anstatt des hide.me Server die des Kumpels Server den VPN-Server gibt und der speedtest zeigt mir ein Test-Server in der Nähe an. Nutzt mein NAS dann die VPN-Verbindung?
Wie checke ich das, mit traceroute am besten, wa?

Übrigens, mit dem Masquerading funktioniert es super, Zugriff von aussen klappt, und der Host nutzt die VPN-Verbindung. Schaue morgen weiter, danke @viragomann .

viragomann

@mike69 said in NAS nicht erreichbar bei aktivierter VPN Verbindung:

Nutzt mein NAS dann die VPN-Verbindung?

Nein, tut es nicht für Verbindungen, die es selbst initiiert.
Dennoch ist es mit dem VPN-Server in einem gemeinsamen (virtuellen) Netzwerk, und dieses nutzt es, um mit ihm zu kommunizieren. Das Default-Gateway wird nur für Verbindungen genutzt, deren Ziel-IP außerhalb des / der eigenen Netze(s) liegt.

So wie ich deine Herausforderung verstanden habe, wird die VPN benötigt, damit dein Freund von seinem PC (dem VPN-Server) auf dein NAS darüber zugreifen kann. Und das sollte er unabhängig von der Standardroute am Client können, wenn er die VPN-IP des Clients als Ziel verwendet, was er ja wohl ohnehin tut.

Grüße

mike69

@viragomann said in NAS nicht erreichbar bei aktivierter VPN Verbindung:

@mike69 said in NAS nicht erreichbar bei aktivierter VPN Verbindung:
So wie ich deine Herausforderung verstanden habe, wird die VPN benötigt, damit dein Freund von seinem PC (dem VPN-Server) auf dein NAS darüber zugreifen kann. Und das sollte er unabhängig von der Standardroute am Client können, wenn er die VPN-IP des Clients als Ziel verwendet, was er ja wohl ohnehin tut.

Grüße

Guten Morgen.

Wir wollen unser Content zusammenfügen, jeder kann auf den anderen NAS zugreifen, das ist der Plan. Sein Server bauen wir am WE auf.

Um das richtig zu verstehen, sein Server erwartet den Clienten auf einer dyn. Adresse (zB: example1.dyndns.org) und der Client fragt bei example2.dyndns.org an. Da sein VPN-Server nur auf eine Adresse wartet und nicht wie bei den großen Diensten auf mehrere, braucht es dann ein routing auf unsere IPs? Nach meinem Verständnis schon.

Alter Schwede, hier tun sich Lücken auf...

viragomann

Morgen,

eine Grafik, die die gewünschten Zugriffe skizziert könnte zum Verständnis beitragen.
Wie bereits erwähnt, ich bin davon ausgegangen, dass nur der PC deines Kumpels (= OpenVPN-Server) auf dein NAS (=OpenVPN-Client) zugreifen möchte.

Wenn du von "Content zusammenfügen" sprichst, könnte auch gemeint sein, dass auf jeder Seite der VPN ein Speicher steht, der jeweil auch von der anderen Seite (mehrere Geräte) genutzt werden soll.
Dieses ist aber nicht so einfach einzurichten, wenn die VPN nicht der Router macht, weil andere Geräte alle anfragen, die ein Ziel außerhalb ihres eigenen Netzwerks haben, zum Router (Standardgateway) schicken.
Du müsstest also auf jedem Gerät, das auf das Remote-Netz zugreifen können soll eine statische Route definieren, die auf den VPN-Endpunkt verweist.

Vom Routing her die bessere Lösung wäre hier ein Tranfer-Netz zwischen Standardgateway und VPN Client einzurichten, also das NAT in ein eigenes Subnetz bringen. Dann wäre nur einmal eine Route am Standardgateway nötig.

@mike69 said in NAS nicht erreichbar bei aktivierter VPN Verbindung:

Um das richtig zu verstehen, sein Server erwartet den Clienten auf einer dyn. Adresse (zB: example1.dyndns.org) und der Client fragt bei example2.dyndns.org an. Da sein VPN-Server nur auf eine Adresse wartet und nicht wie bei den großen Diensten auf mehrere, braucht es dann ein routing auf unsere IPs? Nach meinem Verständnis schon.

Dem Server ist es egal, welche IP der Client hat, solange du den Zugriff nicht einschränkst.
Der Client baut die Verbindung zum Server auf, demnach muss nur der Client wissen, wie der Server zu erreichen ist, also bspw. über den Hostnamen von einem DynDNS Dienst.

Ein Routing braucht es nur für die internen Netze, mit den öffentlichen IPs hat das nichts zu tun. Du musst bei einer VPN zwischen Server und Client IPs im öffentlichen Netz und dem virtuellen Netz (VPN Tunnel) unterscheiden. Die IPs im öffentlichen Netz sind nötig, um die VPN-Verbindung aufzubauen und nur dafür. Steht die Verbindung haben beide Seiten zusätzlich eine IP aus dem VPN Tunnel Subnetz, über welche die Kommunikation zwischen den beiden Seiten stattfindet. Also diese werden fürs Routing zwischen den beteiligten Netzen benötigt.
Ein Gerät, das keine IP im VPN Tunnel Subnetz hat, aber dennoch mit der anderen Seite kommunizieren soll, benötigt eine Route für das Remote-Netz zum VPN-Endpunkt, sofern diese nicht gleichzeitig Standardgateway ist, wie in deinem Fall. Alternativ, kann ein Hop mehr dazwischengestellt werden und die Route über das Standardgateway geführt werden. Dafür muss der VPN-Endpunkt aber in einem separaten Subnetz liegen.

Grüße

mike69

Hier die Skizze im Anhang, hoffentlich verständlich.

Ein Routing braucht es nur für die internen Netze, mit den öffentlichen IPs hat das nichts zu tun.

Jep, es ging um die internen IPs, kam so nicht rüber wenn ich das selbst geschriebene nochmal lese. :)
Die beiden Hosts sollen eine eigene IP im VPN Subnetz bekommen, und dann per nfs oder smb via VPN die Freigaben gesetzt bekommen. So der Plan.
Deswegen die Frage bezüglich Routing, braucht es ein Routing? Eigentlich nicht, oder? Es werden die IPs der Host im VLAN Subnetz direkt angesprochen, da brauch nichts geroutet werden.

JeGr

Also sorry, wenn ich mich kurz einmische, aber das ist doch bekloppt ;)

Warum stellst du nicht bei deinem Kumpel auch einfach fix ne pfSense hin und ihr macht nen stinknormalen einfachen Site2Site Tunnel und gut? Da gibts keine komischen Routings und Gebastel und sonstwas. Macht doch alles nur unnötig kompliziert!

viragomann

@mike69
Also nochmals, so wie ich es verstanden habe, brauchen nur NAS1 und NAS2 miteinander kommunizieren (die auch selbst die VPN-Endpunkte sind). Nein, hierfür sind keine Routen erforderlich, das geht über die virtuellen IPs des VPN Tunnels.

Ich verstehe aber nicht, was ihr davon habt. So kannst du bspw. nicht von deinem PC aus auf das NAS2 zugreifen (ohne spezielle Routen).
Ja, ihr könntet aber bspw. einen Datensynchronisation zwischen den beiden NAS einrichten. Dafür würde die Einrichtung in Ordnung gehen.
Ist das das, was ihr möchtet?

mike69

@JeGr said in NAS nicht erreichbar bei aktivierter VPN Verbindung:

JeGr Rebel Alliance Moderator vor etwa einer Stunde

Also sorry, wenn ich mich kurz einmische, aber das ist doch bekloppt ;)

Ja, so sind wir. :)
Er hat noch weniger Ahnung von der Materie wie ich, das ist dann sehr wenig. Und mit einer zweiten Sense, das ist nicht seins, abgesehen von den Kosten und glaube die Angst was neues zu erlernen. Also nehmen wir den steinigen Weg.

@viragomann said in NAS nicht erreichbar bei aktivierter VPN Verbindung:

@mike69
Also nochmals, so wie ich es verstanden habe, brauchen nur NAS1 und NAS2 miteinander kommunizieren (die auch selbst die VPN-Endpunkte sind). Nein, hierfür sind keine Routen erforderlich, das geht über die virtuellen IPs des VPN Tunnels.
Ich verstehe aber nicht, was ihr davon habt. So kannst du bspw. nicht von deinem PC aus auf das NAS2 zugreifen (ohne spezielle Routen).
Ja, ihr könntet aber bspw. einen Datensynchronisation zwischen den beiden NAS einrichten. Dafür würde die Einrichtung in Ordnung gehen.
Ist das das, was ihr möchtet?

Ja, so ähnlich. :)
Sobald die Verbindung steht, mounte ich die Freigaben ala

mount -t nfs ip_des_anderen:/datenfreigabe /mnt/datenfreigabe

Zumindest funktioniert das mit dem Smartphone über VPN mit smb Richtung Heimat.

Das ist nicht professionell, machen das aus Spaß zu privaten Zwecken. Zweck des Ganzen ist das bereitstellen der Daten für alle inkl Vergrösserung des Speicherplatzes. Das es bessere Methoden gibt, das wissen wir.

Übrigens, looft es zufriedenstellend mit dem Masquerading, obwohl ich einiges nicht verstehe:

@viragomann said in NAS nicht erreichbar bei aktivierter VPN Verbindung:

Also Firewall > NAT > Outbound. In den Hyprid-Modus schalten, falls es im automatischen arbeitet und eine Regel dem Interface, an dem das NAS hängt (LAN?), hinzufügen:
Source: any
Destination: NAS IP
Translation: Interface Address
Damit wird die Quell-IP in Paketen, die zum NAS gehen auf die Interface-IP der pfSense umgesetzt. Für das NAS kommen die Pakete damit von der pfSense (aus dem internen Netz) und es addressiert seine Antworten wieder an diese zurück.

Wird dann nicht alles Richtung NAS-IP geschickt? Auch was nicht hin soll? Wo kann man sich einlesen zu diesem Thema? Werde mal gogeln.

viragomann

@mike69 said in NAS nicht erreichbar bei aktivierter VPN Verbindung:

Sobald die Verbindung steht, mounte ich die Freigaben ala
mount -t nfs ip_des_anderen:/datenfreigabe /mnt/datenfreigabe

D.h. du bindest die Freigabe des Remote-NAS auf deinem ein und umgekehrt. Ja, da sollte funktionieren mit den entsprechenden Zugriffsrechten für die Clients.

@mike69 said in NAS nicht erreichbar bei aktivierter VPN Verbindung:

Wird dann nicht alles Richtung NAS-IP geschickt?

Nein, das ist eine NAT-Regel. Die dirigiert einen Traffic nicht irgendwo hin, sonder setzt nur IP oder Port, jeweils der Quelle oder des Ziels, um für Traffic, der ohnehin existiert, weil er durch irgendeine FW-Regel zugelassen wird.
In diesem wird die Quell-IP der Pakete, die ursprünglich z.B. eine öffentliche IP ist, durch die des pfSense LAN Interfaces ersetzt. Somit antwortet das NAS wieder der pfSense. Würde ein Paket mit öffentlicher Quell-IP am NAS ankommen, antwortet es Richtung Standardgateway, was ja der Remote-VPN-Endpunkt ist. Was aber auch nicht nötig ist, wie schon erwähnt.

Was mir hier Sorgen bereitet, ist, dass das NAS so sämtlichen Upstream Traffic über den VPN-Server schickt. Das sollte nicht sein. Daher "–route-nopull" setzen, die Kommunikation zwischen den beiden NAS wird dennoch funktionieren.

Grüße

mike69

@viragomann said in NAS nicht erreichbar bei aktivierter VPN Verbindung:

Was mir hier Sorgen bereitet, ist, dass das NAS so sämtlichen Upstream Traffic über den VPN-Server schickt. Das sollte nicht sein. Daher "–route-nopull" setzen, die Kommunikation zwischen den beiden NAS wird dennoch funktionieren.

Ok, Danke Dir.