Open VPN am QNAP

[MarkusAT]

@blurrrr da bin ich schneller als gedacht mit meiner ersten Beobachtung schon wieder hier:

Nach über 20h war die Verbindung wieder verlässlich weg.
Was ich definitiv mal ausschließen kann ist irgendein zeitlicher Vorgang, die letzten male stieg der VPN meistens Nachts aus, heute mitten am Tag.

Das Verbindungsprotokoll auf Server Seite (NAS_DE, 2- Eintrag) sagt:



Das Verbindungsprotokoll auf Server Seite (NAS_AT) sagt:


Was mir hier auffällt, dass der Server die Verbindung bereits fast 1 Minute vorher "aufgegeben" hat, als der Client. Kann ich daraus schon schließen, dass das Problem Serverseitig liegt und der Client das erst später mitbekommt?

Was mir auch noch auffällt:
- Der Client empfängt immer deutlich weniger als der Server sendet, umgekehrt stimmt das aber ziemlich gut überein. Kann das an der VPN Komprimierung liegen, oder verliere ich bei jedem Sync eine Menge Daten?

Beide Dinge sind mir auch schon in älteren Verbindungsprotokollen aufgefallen...

Genauere logs gibt es in QVPN nicht, aber ich durchsuche mal den Dumplog, vermute aber, dass die QVPN logs dort nich zu finden sind.

Liebe Grüße und Danke fürs anschauen,
Markus


P.S.:
Trotz Trennung, ist der Remote-VPN-Server hier zu sehen:

 

[MarkusAT]

So was ich im Log so alles gefunden habe:

- Im Kernel log taucht der VPN so gar nicht auf
- Im Eventlog scheinen nur die manuellen Trennungen auf, die VPN Trennung heute um 12:53 Uhr gar nicht:



Die einzelnen Unterlogs wollen erst noch durchforstet werden

Flog übrigens schon wieder raus, somit half das Häckchen der Reconnection neu setzen (was ich heute am Nachmittag vor dem erneuten Login um 16:37 gemacht hatte), auch nicht.



Interessant auf Client Seite (aktuell) ist auch, dass ich eine Laufzeit habe (erst einige Sekunden), obwohl keine Verbindung besteht (VPN-Client-IP und Öffentliche-IP sind leer):

Kurz manuell trennen und verbinden, und alles läuft wieder...



Was mir gerade auffällt, wenn ich keine Verbindung habe, steht bei Protokoll OpenVPN UDP dabei, wenn die Verbindung besteht, "nur" OpenVPN.

 

[blurrrr]

Was mir hier auffällt, dass der Server die Verbindung bereits fast 1 Minute vorher "aufgegeben" hat, als der Client. Kann ich daraus schon schließen, dass das Problem Serverseitig liegt und der Client das erst später mitbekommt?

Das "Problem" könnte auch einfach ein 24h-Disconnect sein (?), oder irgendwas beim ISP, so dass die Verbindung kurzzeitig unterbrochen ist. Theoretisch sollte sich die auftretende Problematik aber eigentlich via keepalive lösen lassen. Kommt manchmal vor, dass der Client nicht mitbekommt, dass die Verbindung nicht mehr da ist (Client ist dann der Meinung, dass noch alles prima wäre, hab ich auch schon öfters bei Fritzboxen erlebt) und so hat er Client natürlich keinen Grund, sich nochmal einzuwählen, die Verbindung steht ja augenscheinlich. Ein keepalive sollte dann dafür sorgen, dass die Verbindung zum einen überprüft wird und zum anderen, bei Bedarf wieder neu aufgebaut wird.

EDIT: OpenVPN läuft standardmässig via UDP (kann aber auch auf TCP geschaltet werden, ist dann aber etwas langsamer).

EDIT2: Hast Du an irgendeinem Standort statische öffentliche v4-Adressen? (oder zumindestens etwas länger gleich bleibende öffentliche IPs)

 

[MarkusAT]

Das "Problem" könnte auch einfach ein 24h-Disconnect sein (?)

Schließe ich auch, da ich schon Verbinundgen von über 48h hatte, aber auch schon Verbindungen von unter 4h

oder irgendwas beim ISP, so dass die Verbindung kurzzeitig unterbrochen ist.

Das ist meine Vermutung, aber das sollte ja eben der reconnect beheben

Theoretisch sollte sich die auftretende Problematik aber eigentlich via keepalive lösen lassen. Kommt manchmal vor, dass der Client nicht mitbekommt, dass die Verbindung nicht mehr da ist (Client ist dann der Meinung, dass noch alles prima wäre, hab ich auch schon öfters bei Fritzboxen erlebt) und so hat er Client natürlich keinen Grund, sich nochmal einzuwählen, die Verbindung steht ja augenscheinlich. Ein keepalive sollte dann dafür sorgen, dass die Verbindung zum einen überprüft wird und zum anderen, bei Bedarf wieder neu aufgebaut wird.

Das mit dem keepalive will ich eigetnlich lassen, dass hat ja der WG auch, aber dann hab ich das Problem, dass der alle 10 Sekunden (wann halt der Keepalive los geht) ein log Eintrag geschrieben wird ==> Die HDD's schlafen nie, aber vor allem man hört (im Wohnzimmer) alle paar Sekunden den Schreibkopf...
Vor allem, der Client bekommt ja mit (zwar etwas später), dass die Verbindung weg ist, macht aber nichts dagegen ^^

EDIT: OpenVPN läuft standardmässig via UDP (kann aber auch auf TCP geschaltet werden, ist dann aber etwas langsamer).

Naja, er wechselt die Anzeige ja von selbst, also ohne das ich was mache. Verbindung da, steht "OpenVPN", Verbindung weg "OpenVPN UDP"

EDIT2: Hast Du an irgendeinem Standort statische öffentliche v4-Adressen?

Nein, sind an beiden Standorten dynamische (öffetnliche v4), die aber meistens über mehrere Tage gleich bleiben (Aktuell haben beide Standorte seit mindestens Sonntag die lgieche IPv4)

Was für mich die einfachste Lösung wäere (und funktioniert):
15 Minuten vor dem täglichen Sycn über den Energieplaner einen Neustart der Clients machen (nach neustart verbindet er sich sauber).

Mein Problem dabei: Jeder(viele?) sichert Daten gerne über Nacht (so auch meine Mutter). Wenn Sie gerade in dem Zeitpunkt, über die Laufwerksanbinung in Windows Datensicherung laufen lässt, wäre das kontraproduktiv.
Im NAS selbst habe ich nur die Lösung gefunden, dass ein Restart verhindert wird, während ein Syncjob läuft, aber damit sind halt die QNAP Tools gemeint...

Mein nächster Test wäre:
Meine Eltern lassen zu Hause, im gleichen Netz in dem auch das NAS steht, einen PC mit OpenVPN laufen und sich auch mit meinem NAS verbinden. Dieser OpenVPN Client bekommt die gleiche Konfigdatei zu lesen wie das NAS dort.
Sollte der PC durchgehend eine Verbindung haben, während das NAS weg ist, kann ich (so glaube ich) die Probleme auf das NAS_AT schieben oder?

Weil irgendeine andere Störung in der Verbindung, die ja 1:1 dieselbe ist (außer das LAN-Kabel NAS_AT zu Router_AT) hätte auch den PC_AT raus schmeißen müssen ^^

 

[MarkusAT]

So, kurzes Update hier:
Viel habe ich leider nicht geschafft, Gesundheit, Handwerker und Renovierung wollen nicht so ganz wie ich im Moment.
Ich habe aber mal Server/Client getauscht ==> NAS_AT macht den Server, NAS_DE jetzt den Client.

Fehler tritt der gleiche auf. Ich brauch nicht mal auf eine schlechte Verbindung warten, sondern kann den Fehler ganz einfach provozieren:

• Server VPN 1. mal ausschalten ==> Client trennt sich (QVPN und Windows)
• Server VPN wieder einschalten (nach 1 Min) ==> Client (QVPN und Windows) verbindet sich erflogreich wieder
• Server VPN 2. mal ausschalten ==> Client trennt sich (QVPN und Windows)
• Server VPN wieder einschalten (nach 1 Min) ==> QVPN Client bleibt getrennt, Windows Client verbindet sich wieder

Das ist 1:1 so mehrfach reproduzierbar, egal welche Seite Client / Server ist.

 

[blurrrr]

Teste das nochmal und dieses mal auf beiden Seiten ein Ping auf die jeweilige Gegenstelle (interne NAS-IP) laufen lassen. Mitunter muss der Tunnelaufbau erst noch extra getriggert werden. Falls nicht... hört sich irgendwie schwer nach QNAP-Support an. Zumal der Haken für die Aufrechterhaltung der VPN-Verbindung gesetzt ist... da würde ich nicht lange fackeln und direkt den Support damit nerven... Ist ja jetzt keine total abstruse Sonderlocke.

 

[MarkusAT]

Teste das nochmal und dieses mal auf beiden Seiten ein Ping auf die jeweilige Gegenstelle (interne NAS-IP) laufen lassen.

Generell ist mir in den letzten paar Tagen der Tunnel von selbst nie öfter als einmal getrennt worden (und hat sich alleine wieder verbunden). Habe ich ein 2. mal "manuell" die Störung eingebracht, jedoch keine erneute Verbindung... auch nicht mit ping :O

Geht (nachdem anderen Ticket) wohl wirklich auch mal an den Support :O

 

[MarkusAT]

Es scheint hier eine Lösung zu geben. QNAP schreibt in die config datei

auth-nocache

Wenn man diese Zeile entfernt, zeigen erste Versuche einen funktionierenden Aufbau der Verbindung.
Ich werde es die nächsten Tage über verifizieren.

Mit einem Kumpel von mir, der viel Ahnung von Linux (aber nicht von QNAP) hat, haben wir die logs vom Client angesehen und schnell folgendes festgestellt:

• Der Client erkennt, wenn die Verbindung weg ist
• Der Client probiert alle paar Sekunden eine neue Verbindung aufzubauen
• Der Client erkennt auch, sobald der Server wieder erreichbar ist

ABER dann geht los

es kommt folgende Zeile im Log:

ERROR: could not read Auth username/password/ok/string from management interface

das wird endlos probiert, bis ich die Verbindung des Client manuell trenne. Danach gibt's einen

Exiting due to fatal error

Daher die Vermutung:
QNAP übergibt danach einfach die Nutzerdaten nicht mehr. Mit der nocache Option sind die auch nicht mehr da, somit will sich der Client zwar verbinden, aber er bekommt nichtmal Nutzerdaten, die er probieren könnte.

Die Frage ist hier dann:
hat es einen Nachteil, wenn ich die Zeile einfach deaktiviere?

 

[rednag]

Ich würde es einfach mal ausprobieren und ein paar Tage damit testen. Kaputt machen kannst nicht viel. Ein "#" davor setzen.

 

[MarkusAT]

Ein "#" davor setzen.

Genauso läuft es jetzt aktuell

 

[tiermutter]

Wenn auth-nocache rausgenommen wird, muss (theoretisch) ständig wieder Username und Passwort angegeben werden, da diese nicht im RAM gespeichert werden.
Gut, die Daten sind in der GUI hinterlegt, aber vermutlich entsteht nun ein Fehler weil diese Daten erst beim Verbindungsaufbau gelesen werden, nicht aber wenn die Verbindung bereits besteht und reauthentifiziert werden muss. Eventuell hilft zusätzlich ein

auth-retry pass

Ich sehe das Problem aber eigentlich eher am Server, weil meine beiden QNAP problemlos im VPN bleiben, Server ist aber OPNsense.

 

[MarkusAT]

Wenn auth-nocache rausgenommen wird, muss (theoretisch) ständig wieder Username und Passwort angegeben werden, da diese nicht im RAM gespeichert werden.

Sollte es nicht umgekehrt sein?
Also wenn auth-nocache drinnen steht (also "aktiv" ist), werden die Daten nicht gespeichert? Und aus der GUI liest er die vermutlich danach nicht mehr aus (so wäre unsere Erklärung des Fehlers gewesen).

Ich sehe das Problem aber eigentlich eher am Server, weil meine beiden QNAP problemlos im VPN bleiben, Server ist aber OPNsense.

Der Server zeigt im log aber keine Fehler. Der bekommt auch gar keine (zumindest sehe ich in Log nichts) Anfrage, der Userdaten und lehnt nichts ab.
Was natürlich sein kann, dass auth-nocache bei Dir in der config File, die der Server ausgibt, gar nicht drinnen steht. Dass also der Server durch den Eintrag den Fehler provoziert und der Client dann eben das Problem hat.

Aber ich lass die NAS jetzt einfach paar Tage durch laufen, dann sehe ich eh bald, ob das Problem so gelöst ist

 

[tiermutter]

Sollte es nicht umgekehrt sein?

Oops... links-rechts Schwäche oder so
Ja natürlich... da habe ich mich verrannt, sorry!

Was natürlich sein kann, dass auth-nocache bei Dir in der config File, die der Server ausgibt, gar nicht drinnen steht.

Jo, ich verwende auth-nocache nicht.

Zum Vergleich mal meine Config (bei der Config im QNAP stehen die Schlüssel/Certs natürlich direkt mit drin):

dev tun
persist-tun
persist-key
cipher AES-128-GCM
auth SHA256
client
resolv-retry infinite
remote xxx 54196 udp6
remote yyy 54196 udp6
remote zzz 54196 udp4
remote aaa 54196 udp4
lport 0
verify-x509-name "C=DE, ST=xx, L=xx, O=xx, emailAddress=xxx, CN=xx" subject
remote-cert-tls server
auth-user-pass
pkcs12 xxx_CA.p12
tls-auth xxx_CA-tls.key 1

 

[tiermutter]

Stimmen eigentlich die Uhrzeiten beider Systeme stets überein?

 

[MarkusAT]

Stimmen eigentlich die Uhrzeiten beider Systeme stets überein?

Also auf die Sekunde genau hatte ich es nich nie überprüft, beide beziehen die Uhrzeit automatisch und ein "grober" Fehler wäre mir nicht aufgefallen

 

[MarkusAT]

Stauts bis jetzt:
VPN Verbindung läuft weiter, immer mal wieder unterbrochen, aber wieder automatisch hergestellt...

Da war wohl tatsächlich

auth-nocache

der Übeltäter :O
Mit ist nur noch ein Rätsel, warum QNAP diesen Parameter Standardmäßig einbaut...

 

[tiermutter]

Eventuell ein Bug oder eine unüberlegte Geschichte? Wenn das Ding per default drin ist, dann sollte man meinen dass auch ein QNAP Client die Verbindung durch Neueinwahl wiederherstellt, und es nicht durch die im RAM gecachten Creds versucht, was durch den Server ja nun unterbunden ist.
Scheint ja auch schwer sein darauf zu kommen dass der Befehl hier Blödsinn ist, sonst wären wir in dem Thread ja auch nicht schon auf Seite 2

 

[rednag]

oder eine unüberlegte Geschichte?

Ist doch bei QNAP nichts neues.
Es will mir nicht einleuchten wie die Firma sich mit solch Spielzeug,- GefrickelOS so etablieren konnte. Das Marketing ist so ziemlich das einzige was bei denen funktioniert.

Es fällt mir schwer, aber ich werde mein Bashing etwas reduzieren, sonst bekomme ich vermutlich von einem Moderator noch eins auf den Deckel.

 

[root69]

Grundlos ist dein Ärger über QNAP ja nicht und daher angemessen wenn es zum Thema passt. Tut es hier aber nicht und bislang ist es nur eine Mutmaßung dass die Voreinstellungen seitens QNAP nicht stimmig sind. Daher bitte etwas zurückhalten damit das in diesem Thread behandelte Problem gelöst werden kann.

 

[rednag]

Ach guck an, das ging ja schnell. Aber ist ok, ich bin schon wieder ruhig.