QNAP VPN Server ohne Port Forwarding

MarkusAT

Member
Hallo wieder mal,

Ich hoffe das passt zum QNAP-Thema, und ist kein generelles VPN Thema.

Kurz zur Konfiguration:
Standort 1 (DE), da bin ich jetzt):
- Vodafone Station, kein Port weitergeleitet
- VPN Server am QNAP gehostet
Standort 2 (AT):
- über einen normalen Open VPN Client (nicht über den QNAP Client) erflogreich eingewählt
- ich kann in AT das NAS in DE erfolgreich als Netzwerklaufwerk einbinden und so Daten zwischen den beiden NAS kopieren (wenn auch brutalst langsam nur ein paar 100 KB/s)
Achja, RTRR findet den anderen Part übrigens nicht.

Ich hab jetzt mal (bin heute an den neuen Standort von NAS 1 gefahren), die VPN Verbindung direkt über den QNAP getestet. Langfristig sollen ja das ein Router oder RaspPi ersetzen.
Funktioniert 1A, nur was mich wundert (und schockiert?):

Die VPN Verbindung geht ohne ein Portforwarding:
1641343140661.png

1641343202745.png

Ist das denn normal?
Hatte in der Vodafone Station Port freigegeben (den, den OPVN im QNAP nutzt), was getestet (RTRR), ging nicht, also direkt Port weider zu. So, VPN Verbindung läuft aber weiter und ist aufrecht und auch Daten können übertragen werden. Zwar geht RTRR nicht (aber auch nicht mit Port Forwarding), aber ich kann z.B. in Österreich über das Netzlaufwerk beide NAS einbinden und z.B. über FreeFileSync die beiden NAS abgleichen (wenn auch nur sehr sehr langsam, nur ein paar 100 KB/s)

Das dürfte doch nicht normal sein. Oder hab ich hier Grundlegend was falsch verstanden?

Danke und LG,
CB
 

tiermutter

Well-known member
Hatte in der Vodafone Station Port freigegeben (den, den OPVN im QNAP nutzt), was getestet (RTRR), ging nicht, also direkt Port weider zu.
Erste Vermutung: Der Router braucht nen Neustart oder so damit das deaktivierte Portforwarding beendet wird. Fritten zB haben da auch so ihre Macken mit Weiterleitungen.

UPnP ist denke ich auszuschließen?!
 

blurrrr

Well-known member
Nö, ich mach den Job nur schon ein paar Jahrzehnte und der Spruch "have u tried to turn it off and on again?" kommt auch nicht von ungefähr ;) Grundsätzlich ist es IMMER ratsam das System mal einfach neuzustarten, wenn man Dinge macht, die eigentlich so funktionieren sollten, es dann aber doch nicht tun. Alternativ lässt sich z.B. etwas nicht umstellen... neustarten, ggf. lässt es sich dann umstellen, nochmal neustarten, dann sollte es auch passen... Hab auch schon Switche gehabt, da konnteste problemlos die VLANs durchkonfigurieren, alles gespeichert, hat den Switch jetzt aber auch erstmal weniger interessiert. Sah alles gut aus, hat null funktioniert... reboot, läuft. Grade von den Fritzboxen kenn ich das auch sehr stark in Bezug auf die Portklamotten... Legste was an... geht nicht... löschte was... geht nicht... also unter'm Strich bleibt halt einfach ein "Reboot tut gut" stehen, wenn es mal nicht so will, wie es eigentlich sollte. Schlimm ist dabei (grade für Anfänger), dass man sehr leicht in die Denke rutscht, dass man selbst irgendwas verzapft hat... man startet das System nicht neu und verstellt lieber noch 27 andere Dinge, was dann mitunter zur Folge hat, dass es selbst nach einem Reboot (dann irgendwann) dann eben nicht mehr so funktioniert wie es sollte (was es vorher vllt getan hätte, aber eben durch die "Fummelei" verhunzt wurde).

Ebenso kann man beim Troubleshooting eine ungeschönte Wahrheit beherzigen...

"OSI-Schichtenmodell von unten (Layer 1) nach oben (Layer 7) abarbeiten" (und NICHT anders herum)

...was für normale Menschen heisst:

Geht irgendwas nicht (z.B. Computer hat kein Internet), fangen wir NICHT an zig Dinge in der Software am Computer zu verstellen, ggf. Treiber anderweitig auf USB-Sticks zu laden und drüber zu installieren und und und (da bewegt man sich schon recht weit oben im OSI-Schichtenmodell), sondern wir fangen UNTEN an... unten bedeutet: Als ALLERerstes mal die beteiligten Kabel auf korrekten Sitz überprüfen, ggf. mal ein Kabel wechseln (das geht schnell und ist einfach). Somit wird also erstmal die "Strecke" überprüft. Falls die anderen Geräte auch kein Internet haben (Reboot Router? Da isser wieder...😁), ansonsten auch mal Rechner neustarten... Erstmal die einfachen rudimentären Dinge testen. Danach geht es dann weiter nach oben im OSI-Schichtenmodell... Kriegt der PC überhaupt eine IP zugewiesen (ggf. hat er auch eine statische), kann er andere "interne" Netzteilnehmer erreichen? Wieder ein bisschen weiter wären wir dann bei Fragen wie: Funktioniert die Namensauflösung? Kann ich externe Geräte erreichen? Beliebt ist da immer sowas wie "ping 8.8.8.8" (ohne Namensauflösung) und "ping dns.google" (mit Namensauflösung). Also immer schön step-by-step, zumal es nach oben hin im Modell auch immer komplexer wird.
 
Zuletzt bearbeitet:

the other

Well-known member
Moinsen,
weil der Tag doof war und ich eben mit genau jener Schicht heute zu tun hatte:
zu beachten ist IMHO hierzu:
Ebenso kann man beim Troubleshooting eine ungeschönte Wahrheit beherzigen...

"OSI-Schichtenmodell von unten (Layer 1) nach oben (Layer 7) abarbeiten" (und NICHT anders herum)
Es ist unbedingt erforderlich das sog. Erweiterte OSI-Schichtenmodell hinzu zuziehen: das 8 Schichten Modell.
In vielen Problemfällen hilft es da dann, die Schichten VON OBEN zu bearbeiten, also mit Layer-8 unbedingt zu beginnen (gefühlt ist das Problem dann in 87,23 % der Fälle behoben.)..:ninja:


;)
 

the other

Well-known member
ps...hilft auch bei nicht-Netzwerkbezogenen Problemen oft...und WIE die Layer-8 bearbeitet wird ist deutlich situationsabhängig, sowie auch die Wahl der Werkzeuge und Instrumente zur Bearbeitung. Oft helfen da auch analoge Dinge aus Holz.
:ninja:
 

Zurzeit aktive Besucher

Letzte Anleitungen

Statistik des Forums

Themen
969
Beiträge
14.049
Mitglieder
500
Neuestes Mitglied
McKay1408
Oben