Open VPN am QNAP

MarkusAT

Member
Hallo zusammen,

da Wireguard (im Moment) am QNAP als VPN Lösung mal ausgeschlossen ist, geht's bei mir wieder mit OVPN weiter.
Da habe ich jedoch aktuell massiv Stabilitätsprobleme.
Massiv heißt hier nicht, dass die Verbindung verbunden/getrennt ist, sondern, dass die Verbindung zwischendurch mal über 12h getrennt ist und dann plötzlich wieder verbunden.
1642379995550.png

Wenn ich es gerade merke (weil ich Mails bekomme, dass der Sync fehlgeschlagen hat), kann ich manuell den VPN-Client deaktivieren und wieder aktivieren und die Verbindung ist sofort da (Server aktivieren/deaktivieren hilft da nicht). Mach ich das nicht, bleibt die Verbindung für Stunden getrennt, connected aber wieder von selbst.

Eine aktive Internetverbindung besteht hier auf beiden Seiten. Durchgehend.
Nun die Frage, hat von euch einer eine Idee, woran das liegen kann?

Am Client ist eingestellt, dass sich der VPN Server automatisch wieder verbinden soll.
Im QNAP kann man ja relativ wenig in der OPVN konfig ändern, könnte an den Einstellungen evtl etwas falsch sein?

1642379789624.png


Danke und LG,
Markus
 

FSC830

Active member
Wäre das nicht evtl. im QNAP Forum besser aufgehoben?
Was macht denn in der Zeit das QNAP, irgendetwas besonderes wie Raid Scrubbing, Disk Test, Jobs, ...?
CPU Auslastung?

Obwohl ich nicht sagen kann, ob es tatsächlich am QNAP oder am Client liegt, passt es aber irgendwie zum Gesamtbild bei QNAP, das es als NAS eigentlich gut funktioniert, aber sobald etwas darüber hinaus genutzt wird, nicht besonders zuverlässig ist. :rolleyes:

Gruss
 

MarkusAT

Member
Das wäre der nächste Weg, aber deswegen ist es ja hier in der QNAP Abteilung, ich mag das kleine Forum hier :D
Wie heißt es, zu viele Köche verderben den Brei ;)

Was macht denn in der Zeit das QNAP, irgendetwas besonderes wie Raid Scrubbing, Disk Test, Jobs, ...?
Gefühlt nichts, aber das Client QNAP schläft ja auch nie, also wird es was machen. Nur spucken die Logs nichts brauchbares aus...
~2%
Obwohl ich nicht sagen kann, ob es tatsächlich am QNAP oder am Client liegt
Sind ja beides QNAPS :)

LG,
Markus
 

blurrrr

Well-known member
Wäre das nicht evtl. im QNAP Forum besser aufgehoben?
Die Kompetenzbestien haben wir sowohl aus dem QNAP-, als auch aus dem Syno-Forum hier (da mag für den ein oder anderen Bereich zwar noch jemand fehlen, aber sei's drum). Also "so" schlecht ist es hier um das Forum definitiv nicht bestellt... 😜
Massiv heißt hier nicht, dass die Verbindung verbunden/getrennt ist, sondern, dass die Verbindung zwischendurch mal über 12h getrennt ist und dann plötzlich wieder verbunden.

Wenn ich es gerade merke (weil ich Mails bekomme, dass der Sync fehlgeschlagen hat), kann ich manuell den VPN-Client deaktivieren und wieder aktivieren und die Verbindung ist sofort da (Server aktivieren/deaktivieren hilft da nicht). Mach ich das nicht, bleibt die Verbindung für Stunden getrennt, connected aber wieder von selbst.
Vermutlich kommt der Reconnect, wenn wieder Pakete ins Remote-Netz sollen, vllt hilft ja ein keepalive (https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/ Schau dort einfach mal nach "keepalive") :)
 

MarkusAT

Member
ermutlich kommt der Reconnect, wenn wieder Pakete ins Remote-Netz sollen
wie meinst das genau?

vllt hilft ja ein keepalive (https://openvpn.net/community-resources/reference-manual-for-openvpn-2-4/ Schau dort einfach mal nach "keepalive") :)
Keepalive würde ich gerne vermeiden (zumindest hat der bei WG) ein schreiben alle 10 Sekunden auf dem QNAP ausgelöst, weil er jedes "keepalive" logt.
Aber, sollte das Ganze nicht auch ohne funktionieren? Spätestens dann, wenn ich den OpenVPN Server Aus- und wieder Einschalte?
Bis jetzt habe ich ja den VPN Srever einfach mit der QVPN GUI aufgesetzt. Das würde dann nicht mehr gehen, oder?
 

MarkusAT

Member
So sehen übrigens die Einstellungen auf Client Seite aus:
1642425849731.png

Es ist halt seltsam, dass die automaitsche erneute Verbindung nicht klappt, aber das manuelle Neuverbinden (sprich auf disconnect klicken, danach wieder auf connected) sofort.
 

blurrrr

Well-known member
Okay.... Haken für keepalive scheint ja drin zu sein... ggf. mal Haken raus, speichern, Haken wieder rein? Die Logs auf der Client-Kiste (sofern vorhanden) dürften vermutlich auch recht aufschlussreich sein und serverseitig wäre die Frage, was ggf. an Firewall davor ist (Stichwort UDP-Flood-Protection, nicht, dass da die Firewall einfach Pakete verwirft). Wenn beim Server nix aufschlussreiches in den Logs zu finden ist, würde ich auf jeden Fall mal die Firewall-Logs prüfen.
 

MarkusAT

Member
Noch eine weitere Frage dazu, Serverseitig.
1642426973439.png

Sehe ich es richtig, dass wenn ich die gelb markierte Option markiert habe, der gesammte Internet Traffic (vom Client NAS, nicht aber vom Client Netzwerk) über mein Serverseitiges Internet läuft. Wenn ich das so lasse, wäre es unklug, sollte aber nicht die Verbindungsabbrüche erklären, korrekt?
 

MarkusAT

Member
Okay.... Haken für keepalive scheint ja drin zu sein... ggf. mal Haken raus, speichern, Haken wieder rein?
Werde ich probieren, Danke :)
Wobei wenn der Fehler daran liegen würde, warum verbindet sich der Client dann ab und zu nach 12h wieder?

Die Logs auf der Client-Kiste (sofern vorhanden)
Das werde ich auch abchecken (ob überhaupt vorhanden) und was ggf. drinnen steht :D

ggf. an Firewall davor ist (Stichwort UDP-Flood-Protection, nicht, dass da die Firewall einfach Pakete verwirft).
Klingt für mich logisch. Zur Verständnisfrage: warum würde dass dann einen Unterschied machen, wenn ich die VPN Verbindung für den Bruchteil einer Sekunde (na gut, lasst es eine ganze Sekunde sein) manuell deaktiviere (nur Clientseite) und wieder aktiviere.

Wenn beim Server nix aufschlussreiches in den Logs zu finden ist, würde ich auf jeden Fall mal die Firewall-Logs prüfen.
Selbst hier muss ich mal schauen, obs da was gibt. Glaube aber die VF-Station hat keine, die QNAP FW ist deaktiviert.
 

the other

Well-known member
Moinsen,
richtig: wenn du den Haken rausnimmst, dann geht NICHT mehr der gesamte Internetverkehr via VPN. Das sollte aber rein gar nix mit deinem Problem zu tun haben (ist zB für ein Road-Warrior Szenario eine doch oft praktische Einstellung).

Ich habe zwar null Erfahrung mit QNAP, finde aber auch, dass @blurrrr da vielleicht richtig liegt (also Haken raus bei keep-alive / "erneut verbinden wenn...", dann speichern, warten...dann Haken wieder rein, speichern, warten...überwachen, ob es jetzt verfrühstückt wurde), denn sowas machen (leider) einige andere Geräte auch: du setzt einen Eintrag, der dann aber irgendwie nicht übernommen wird.

Tja, so ganz ohne extra Firewall würde ich aus dem Bauch auch denken, dass die Flood-Protection nicht unbedingt vorhanden ist bzw. hier reingrätscht.

KeepAlive sonst ggf. noch manuell in die Konfigurationsdatei einfügen (so das denn bei dem Hersteller geht), vielleicht dann mit ner Zeitangabe...wäre auch meine letzte Idee dazu.

Ist ja nunmal leider oft so, dass die Konfigrationmöglichkeiten via GUI doch arg "kastriert" sind und nur einen Bruchteil der Möglichkeiten bieten. Ist bei Synology nicht anders. Einerseits toll, denn openVPN ist doch recht komplex (wie der link von @blurrrr ja zeigt). Andererseits aber auch mist, wenn der User eben einige weitere Einstellungen vornehmen will.

Also: erst mal alle logs sichten, Infos zusammentragen, schauen, ob da ein roter Faden zu sehen ist...dann mal gucken.
 

blurrrr

Well-known member
Das kommt wohl ganz darauf an, wie die Dinge konfiguriert sind und/ob nicht ggf. noch andere Faktoren dazu kommen. Wenn am Standort AT sonst nicht sonderlich viel los ist, fällt mitunter vllt auch garnicht auf, wenn z.B. die Leitung gestört ist, oder das Routing des ISP einfach ein bisschen rumwackelt. Könntest Dir die Strecke ggf. auch einfach mal via pathping anschauen (ein kostenloses Windows-Tool mit GUI dafür wäre z.B. "pingplotter"). Interessant wäre dann auch, ob sich die Hops auf dem Weg evtl. noch ändern (heisst, dass die ISP-Router dann Routen umschwenken)... Grundsätzlich würde ich erstmal a) in die Logs schauen, danach b) den "Weg" prüfen (ruhig auch etwas länger ggf. auch an verschiedenen Tagen) und weil man während dessen eh nix zu tun hat, 3) einfach an beiden Standorten mal 2 VMs fertig machen und darüber ein VPN laufen lassen und schauen, ob sich das ebenso verhält wie das VPN über die QNAP-Geräte, oder ob es stabiler mit den VMs läuft... So, nun haste erstmal genug zu tun für diese Woche 😁
 

MarkusAT

Member
Danke euch beiden, ich werden von meinen "Log-Erlebnissen" berichten :D

Wenn am Standort AT sonst nicht sonderlich viel los ist, fällt mitunter vllt auch garnicht auf, wenn z.B. die Leitung gestört ist
Das war meine erste Vermutung, aber Teamviewer/AnyDesk verbinden super und auch ein lokaler Speedtest verläuft erflogreich.

So, nun haste erstmal genug zu tun für diese Woche 😁
Da ich ja meist sehr sehr lange Arbeite glaube ich auch noch fürs Wochenende :D :D
 

blurrrr

Well-known member
aber Teamviewer/AnyDesk verbinden super und auch ein lokaler Speedtest verläuft erflogreich.
Guck Dir erstmal die Strecke an... und danach ggf. den Server-Standort... Mitunter wäre es evtl. auch nicht verkehrt, wenn man noch eine andere Teststellung laufen hätte - auch hier "könnten" wieder die billigen vServer ins Spiel kommen, alternativ Clients, oder ganz alternativ Freunde/Bekannte, mit denen man testweise mal sowas laufen lässt.
 

MarkusAT

Member
Ich mach doch mal einen einfachen Versuch:
  • Client 1: QNAP_AT
  • Client 2: mein Handy

Wenn immer nur QNAP_AT raus fällt, dürfte es ja nicht Server/FW seitig in DE sein, oder?
 

the other

Well-known member
Moinsen,
unbedingt richtig!
Bevor du jetzt mehr oder weniger im Blindflug zig Sachen nachjustierst (und dabei am Ende dann gar nicht mehr weisst, was wann wieso irgendwann mal lief) oder anfängst an Stellen Schrauben zu drehen, die kein Eingreifen erfordern: Infos einholen.

Bei mir auf Arbeit gab es da (in gänzlich anderem Zusammenhang, also nix IT) immer den Spruch: wenn Notfall erstmal weg vom Bett und eigenen Puls messen, dann loslegen.
Also: nicht kopflos gaaaaaanz viel gaaaaaaanz schnell machen, sondern lieber in relativer Ruhe schauen, was für Infos du aus der und über die Situation hast.

Zum Glück ist Dr. blurrrr :p (nix für ungut) und Team am Start und kann dir ggf. beim Auswerten von Logs helfen (ist jetzt nicht so mein Steckenpferd, aber es gibt hier ja durchaus einige echt fitte Leute).

Bin mal gespannt...good luck!! (y)
 

rednag

Well-known member
Ich finde, daß jeder einen @blurrrr haben sollte.
Und wenn man ihn nicht mehr braucht stellt man in die Ecke, beachtet ihn nicht mehr und gut ist. 🙃
 

Zurzeit aktive Besucher

Neueste Beiträge

Letzte Anleitungen

Statistik des Forums

Themen
956
Beiträge
13.925
Mitglieder
487
Neuestes Mitglied
hendrik2022
Oben