myQNAPcloud Link - Der QNAP Vermittlungsserver
tiermutter
[PROLOG]
Portfreigaben insbesondere für den Zugriff auf Datendienste oder die Weboberfläche auf ein (QNAP) NAS sind gefährlich, das weiß fast jeder. Immer wieder wird deshalb strikt davon ab und stattdessen zu einem VPN geraten. Immer wieder wird dann auch der Link-Dienst von QNAP (myQNAPcloud LINK) ein Thema. Die Meinungen dazu gehen jedoch immer wieder auseinander: Ist das nun sicher oder nicht? Was passiert mit den Daten die hierbei übertragen werden?
Ich habe mir das mal schnell angeschaut und möchte darüber sowie über meine Gedanken dazu berichten.
[ALLGEMEINES]
Ein Fernzugriff ohne Portfreigabe und ohne VPN: Wie ist das möglich?
Ganz einfach über Vermittlungsserver. Die Technik, die sich allgemein dahinter verbirgt, nennt sich zumindest in der IPv4 Welt "NAT Traversal" (NAT-T) womit das Problem umgangen wird, dass Geräte in privaten Netzwerken nicht direkt ohne Portweiterleitung erreicht werden können.
Dabei bauen die Geräte (hier also das QNAP NAS und ein beliebiges Endgerät) eine Verbindung zu einem öffentlichen Server (in dem Fall von QNAP) auf.
Im einfachsten Fall wird dann alles über diesen Server abgewickelt, also sämtliche Kommunikation für Anmeldung, etc. sowie der Austausch von Daten wird zu diesem Server geschickt, der es dann entsprechend weiterleitet, allgemein bekannt unter dem Namen „TURN“ (Traversal Using Relay Around NAT).
Man kann es sich vorstellen wie zwei Telefone, die nur nach draußen telefonieren können: Beide rufen beim Vermittlungsserver an und dieser legt die beiden Hörer so aneinander, dass die beiden Teilnehmer miteinander sprechen können. Natürlich hört der Vermittlungsserver nicht mit, auch wenn er es ohne die Sprache zu verstehen könnte.
Bestenfalls, jedoch nicht unter allen Bedingungen umsetzbar oder sicher*, kommt das "STUN" Protokoll (Session Traversal Utilities For NAT) zum Einsatz. Hierbei dient der Vermittlungsserver tatsächlich nur der Vermittlung und sorgt dafür, dass die involvierten Geräte eine direkte Verbindung zueinander aufbauen und miteinander kommunizieren können; nach dem Verbindungsaufbau läuft sämtlicher Datenverkehr somit direkt zwischen den beteiligten Geräten ab.
Im Beispiel mit den Telefonen erklären beide also die Absicht privat miteinander sprechen zu wollen. Der Vermittlungsserver versucht nun einen geeigneten Weg durch das Leitungsnetz zu finden und die Leitungen so zu schalten, dass die beiden Telefone direkt verbunden sind und der Vermittlungsserver auflegen kann. Dabei muss bei unterschiedlichen Schaltstellen angefragt und geprüft werden, ob es hier mit dem Verbindungsaufbau weitergehen kann oder nicht.
* Auch bei STUN werden Ports von außen erreichbar geöffnet damit die Geräte miteinander kommunizieren können. Je nach Netzwerkumgebung wird der Port allerdings so geöffnet, dass er entweder für jedermann offen ist, oder eben nur für das berechtigte Gerät. Da der erste Fall einer normalen, wenn auch zeitlich beschränkten, Portfreigabe entspricht, sollte STUN in diesen Fällen nicht zum Einsatz kommen. In manchen Fällen ist STUN generell nicht möglich.
Der hauptsächliche Vor- bzw. Nachteil liegt dabei auf der Hand:
Bei STUN wird direkt kommuniziert, die Daten sind also vermeintlich sicher (sofern verschlüsselt) und können mit vollem Speed was das Internet hergibt übertragen werden.
Da bei TURN sämtliche Kommunikation über den Vermittlungsserver erfolgt, wird die Geschwindigkeit teils deutlich gedrosselt. Auch wenn die Daten verschlüsselt sind, werden sie "in die Hände" von Dritten gegeben.
Dass es bei IPv6 in den meisten Szenarien kein NAT gibt, ist für unsere Betrachtung weniger von Bedeutung, da die Aufgabe identisch bleibt:
Der Vermittlungsserver muss dafür sorgen, dass die beiden Geräte direkt miteinander kommunizieren können. Auch wenn hier i.d.R. kein NAT im Spiel ist, so bleibt die Firewall als Hürde bestehen und muss überwunden werden.
(Dies stellt nur die bekanntesten Verfahren/Protokolle dar und dient vornehmlich der allgemeinen Veranschaulichung.)
[DER LINK-DIENST VON QNAP]
Was genau wird nun also bei QNAP verwendet? Kurz: Ich weiß es nicht.
Dem Vernehmen nach wird QNAP hier etwas Eigenes verwenden, es ist aber nicht sonderlich entscheidend, wie der genaue Ablauf für den Verbindungsaufbau ist, sondern wie die spätere Kommunikation abläuft. QNAP beschreibt es selbst wie folgt:
With myQNAPcloud Link, myQNAPcloud provides network address translation-traversal (NAT-T)-based remote connection service. In some network conditions that do not allow direct connection to your QNAP NAS, the data may traverse through our servers. Our servers only log the information connection for security purposes. The traffic data only passes through the servers without leaving any trace of the contents. You can disable myQNAPcloud Link on the user interface of your QNAP product anytime.
Nehmen wir also an, es würde sich um die oben beschriebenen Protokolle handeln, so wird hier je nach Möglichkeit STUN oder TURN verwendet.
In meinem ersten Versuch habe ich den „qlink“ von einem Rechner aufgerufen, der direkten LAN-Zugriff auf das NAS hatte. Im Ergebnis wurde ich entsprechend auf die interne IPv4 Adresse des NAS umgeleitet. Nach mehreren erneuten Aufrufen war es dann mal die IPv4 und mal die IPv6 (GUA). Direkter kann die Verbindung also nicht sein, wenn man im selben Netzwerk ist.
Im nächsten Test habe ich den Link von meinem Smartphone über das 5G Mobilfunknetz aufgerufen. Erwartungsgemäß erhielt ich eine Meldung, dass eine direkte Verbindung nicht möglich sei und die Daten daher über die QNAP Server übertragen werden.
Dies hatte ich fast erwartet, denn zum einen hat das NAS eine Internetverbindung über CGNAT und auch das Mobilfunknetz wird hier vom Provider stark eingeschränkt.
Während CGNAT dank IPv6 Konnektivität kein Problem darstellen sollte, könnte es also am Mobilfunknetz liegen, dass hier keine direkte Verbindung zustande kommen kann.
(Meldung dass Daten über die QNAP Server übertragen werden; Screenshot vom PC)
Im nächsten Test habe ich mich mit dem Mobiltelefon also in das Gäste WLAN gehangen, sodass mir etwaige Einschränkungen im Mobilfunknetz nicht dazwischen kommen. Wider Erwarten bekam ich hier erneut die Meldung, dass eine direkte Verbindung nicht möglich sei und die Daten über die QNAP Server übertragen werden. Damit hatte ich nicht gerechnet, da allenfalls CGNAT einen Strich durch die Rechnung machen konnte, allerdings nur, wenn ausschließlich IPv4 verwendet wird.
Für den nächsten Test an einem weiteren Rechner habe ich das Netzwerk kurzerhand so umgestrickt, dass NAS und Rechner nicht den CGNAT Anschluss der Deutschen Glasfaser verwenden, sondern den DSL Anschluss der Telekom, sodass auch hier keinerlei Einschränkungen zu erwarten sind. Die direkte LAN-Kommunikation habe ich unterbunden, damit die Verbindung in jedem Fall über das Internet hergestellt wird. Außerdem habe ich ein Packet Capture laufen lassen, um zu sehen ob IPv6 überhaupt verwendet wird.
Auch hier erfolgt der Datenaustausch analog zu den vorherigen Tests über die QNAP Server, zu meiner positiven Überraschung wird aber tatsächlich auch IPv6 verwendet, wodurch es wenigstens außerhalb vom Mobilfunknetz keine Einschränkungen mehr geben sollte.
[MEINE RÜCKSCHLÜSSE]
Da der letzte Test eigentlich schon das günstigste Szenario darstellt und die Daten dennoch über die QNAP Server übertragen werden - das konnte ich auch anhand des Packet Captures ausmachen - gehe ich davon aus, dass das immer so erfolgt, sofern sich nicht beide Geräte im selben Netzwerk befinden.
Der Algorithmus von QNAP’s proprietärer Lösung wird daher vermutlich nur genau das prüfen und andernfalls alles über die QNAP Server leiten, statt wie übliche NAT-T Lösungen zu versuchen die Verbindung direkt über das Internet herzustellen. Aber natürlich kann ich hier auch irgendwas übersehen haben, sodass es doch Szenarien gibt, in denen das möglich ist und genau so erfolgt.
Denkbar ist das jedenfalls, denn sonst wäre die obige Beschreibung von QNAP „In some network conditions…“ zu sehr irreführend; außerdem hat der Verbindungsaufbau stets einige Zeit in Anspruch genommen und es wurde mit mehreren externen Servern kommuniziert... für mich zumindest ein Indiz dafür, dass nicht nur geprüft wird ob das NAS über das lokale Netzwerk erreichbar ist.
[FAZIT]
Dass meine Daten, wenn auch verschlüsselt, über die QNAP Server übertragen werden, kommt für mich nicht in die Tüte. Je nach Anwendung kann das auch aus Sicht des Datenschutzes kritisch sein. Ob das nach jemandem Gusto ist, muss aber natürlich jeder selbst entscheiden. Fakt ist jedoch: Bandbreite ist teuer und daher sicherlich streng limitiert. Beim Herunterladen einer 1,8GB großen Datei bin ich hier auf 350 bis max. 800kB/s gekommen, das ist von den gut 17MB/s die ich über VPN erreiche sehr weit entfernt.
Selbst wenn die Daten nicht über die QNAP Server übertragen werden, stellt eine derartige Lösung für mich immer ein besonderes Risiko dar: Wer Kontrolle über den Vermittlungsserver hat, hat auch schnell Kontrolle über alle dort registrierten NAS. Einem Hacker dürfte es dann ein Leichtes sein, seine Malware auf diese NAS zu verteilen. Sicherlich ein lukrativeres Ziel als mein VPN.
Für diejenigen denen der Datenverlauf nichts ausmacht, nicht auf Geschwindigkeit angewiesen sind und keine Möglichkeit zur Nutzung eines VPN haben oder dies nicht erwünscht ist, ist dieser kostenlose Service aber dennoch eine gute Alternative, die zumindest sicherer ist als Portfreigaben… woanders wird übrigens gerne Geld für die Nutzung von Vermittlungsservern verlangt!
Übrigens:
Den "Link-Dienst" von myQNAPcloud bitte nicht mit dem myQNAPcloud Link (z.B. meinNAS@myqnapcloud.com) verwechseln... Letzterer ist nur ein dynamischer DNS der unter Umständen auf einen offenen Port des NAS zeigt.
Deshalb schreibe ich den Dienst im Forum immer in Großbuchstaben (myQNAPcloud LINK). Der Link vom Link-Dienst sieht so aus: qlink.to/meinNAS .
[EPILOG]
Auch wenn ich für den Fernzugriff beim VPN bleibe, würden mich natürlich trotzdem weitere Erfahrungen interessieren:
Gibt es Fälle, und wenn ja in welchem Konstrukt, wo die Daten tatsächlich direkt zwischen den Geräten über das Internet ausgetauscht werden?
Weil das hier gerade alles so schnell ging, diesmal einfach mal so: Cheers!