Quickconnect klappt, aber Weiterleitung auf Surveillance Station klappt nicht

[rubaez]

über https://xxxx.quickconnect.to komme ich über ein Fremdnetz auf meine DS. Klicke ich jedoch auf den Button Sureillance Station werde ich auf die Seite https://195.122.139.108/ umgeleitet, deren Zertifikat abgelaufen sein soll - laut Firefox. Selbst wenn ich mutig auf "ignorieren" drücke, erscheint eine leere Webseite mit dem kurzen Text "Test".
https://195.122.139.108/ ist laut Whois - heise für Synology GmbH Deutschland eingerichtet. Offensichtlich ist die Weiterleitung gestört. Gleiches passiert wenn ich von zu Hause auf eine DS im Fremdnetz über quickconnect einloggen möchte. Stutzig macht die selbe IP https://195.122.139.108/.
Kann es sein, dass die Weiterleitung https://xxxx.quickconnect.to korumpiert ist?

 

[HansX]

Hallo ... auch ich habe genau das gleiche Phänomen. Irgendwas stimmt mit der Weiterleitung und der IP nicht

 

[blurrrr]

Kann es sein, dass die Weiterleitung https://xxxx.quickconnect.to korumpiert ist?

Man soll auch nicht xxx.quickconnect.to eingeben, sondern quickconnect.to/xxxx

Je nachdem wird von Synology ggf. noch ein ".de" eingefügt (z.B. xxx.de.quickconnect.to), probiert es bitte nochmal via: "quickconnect.to/<Quickconnect-ID>"

Ich habe übrigens keinerlei Probleme beim Zugriff auf diverse externe Synos

 

[rubaez]

Es scheint völlig gleich zu sein, was in der Adresse einzugeben ist, ob "xxxx.quickconnect.to" oder "quickconnect.to/xxxx". Die Rückmeldung des Servers kommt als https://xxxx.de.quickconnect.to. Das ist aber auch nicht das Problem, denn eine Verbindung zur DS entsteht. Auf der Startseite sind APPS mit verschiedenen Wirkungen. Einerseits wird die APP innerhalb der Webseite geöffnet, wie z.B. "Paketzentrum" oder "Systemsteuerung". Weitere APPS starten in einem neuen Fenster /Reiter. Das erkennt man, wenn man die rechte Maustaste nutzt "In neuen Fenster öffnen". Bei mehreren dieser APPS wird auf die IP "https://195.122.139.108" umgeleitet, konkret bei Surveillance Station auf "https://195.122.139.108/webman/3rdparty/SurveillanceStation/login.cgi" - bei der eine Seite aufgeht mit den Buchstaben "Test". Eine Weiterleitung auf die eigene Surveillance Station erfolgt nicht. Ähnliches erfolgt auch bei Video Station, Audio Station oder Download Station. Noch vor einigen Tagen sind die internen Seiten der APP aufgegangen. Ich gehe von einem Fehler des Synology-Servers aus, da auch die geöffnete IP zu diesem Server gehört.

 

[blurrrr]

Fallen mir erstmal spontan 2 Sachen zu ein:

- Quickconnect / Erweitert / Quickconnect-Relay-Dienst <- Haken bei "aktivieren" drin?
- Extener Zugriff / Erweitert / Hostname oder statische IP <- ist hier ggf. was eingetragen?

 

[rubaez]

Bei Quickconnect sind die Haken gesetzt, wohl weil ich über Quickconnect zurzeit auf die DS zurückgreife (meine Vermutung), scheint alles "ausgegraut" und lässt sich von hier nicht ändern.
Von meiner Arbeitsstelle kann ich wegen der gesperrten Ports auch nur über quickconnect zu greifen, da hier alle anderen Ports gesperrt sind. Deswegen komme ich auch nicht über eine vorhandenen dynamische IP zur DS. Ich weiß nicht, ob DSM 6.0.2-8451 Update 6 etwas geändert hat, denn dieses wurde am Freitag eingespielt.
Die hiesige DS ist aber so alt, dass die von Synology nicht mehr gepflegt wird. Da hat sich nichts geändert und bei einem Zugriff von zu Hause hierher über Quickconnect kommt auch nur diese eigenartige IP https://195.122.139.108, die ich wegen der 108 sofort erkannt hat. Also liegt es nicht an mir sondern an Synology!

 

[heavy]

Also abgesehen davon dass Quickconnect gestern einige Probleme hatte, kann man die Einstellungen nur aus dem LAN Netz ändern. (als schutz dass man sich nicht aussperrt) Aber auch hier wieder einmal der dringende Hinweis die Verwendung von Quickconnect wird als schwerwiegender Eingriff in die Computer Infrastruktur gewertet und kann die fristlose Entlassung incl Schadenersatz nach sich ziehen. Wenn du wirklich beruflich auf dein NAS zugreifen musst, dann klär das mit dem Chef/IT-Abteilung ansonsten lass es.

 

[blurrrr]

Ich denke nicht, dass der Quickconnect-Dienst generell ein Problem hat, vermutlich nur der ein oder andere Relay-Server (kommt übrigens auch häufiger mal vor). Hatte diverse Zugriffe ausprobiert (auch von anderen Standorten aus) und hatte nirgendwo ein Problem. Wenn Du "immer" dran kommen möchtest, DDNS + VPN verwenden (sicher), DDNS + statische Portweiterleitungen verwenden (eher unsicher).

"Von meiner Arbeitsstelle kann ich wegen der gesperrten Ports auch nur über quickconnect zu greifen, da hier alle anderen Ports gesperrt sind." Das wäre doch nur ein Zugriff auf Inhalte im Internet und das ist doch scheinbar erlaubt. Ausser natürlich es wurden div. Dinge unterschrieben (private Nutzung untersagt, etc.), dann wäre das schon nicht so praktisch. Schlussendlich liegt es aber an den Administratoren diese Dinge in den Griff zu bekommen (Proxy-Sperre auf *.quickconnect.to; Einschränkungen via Webfilter auf Inhaltsebene usw.) von daher gehe ich eher nicht davon aus, dass es Ärger gibt, nur weil man von der Arbeit auf sein heimisches NAS zugreift. Allerdings haben sich Dinge wie "Internetradio hören" schon durchaus in den Büros etabliert. Wie heavy aber schon sehr richtig sagt: sprich auf jeden Fall mal den/einen Administrator bei euch im Haus darauf an und frag die erstmal, ob das in Ordnung geht. Als Tip: frag, ob Du sowas "dürftest", nicht, dass Du es schon längst machst!

 

[heavy]

Lieber Blurr hinter Quickconnect steht die Technik des Hole Punching (ein Grund warum manchmal QC eben geht und DDNS nicht). Und diese Art des Verbindungs Aufbaus, eben weil man so in eine Firewall Löcher bohren kann, wird als manupilation der Netzwerk infrastrukur gesehen. Das wäre das gleiche wenn du einen VPN Tunnel aufbauen würdest um die Webfilter in der Firma zu umgehen, oder du auf deiner DS einen Webbrowser installierst (auch schon hier beschrieben worden), oder, oder. Und da gilt das gleiche wie beim Kopierschutz, egal wie einfach es ist ihn zu umgehen oder ihn auszuhebeln, es ist nicht erlaubt. Wenn die Ports gesperrt sind dann hat das seinen Grund und wenn man diese Sperre durch die Verwendung eines solchen Hole Punching Dienstes, was eben Quickconnect ist, umgeht bekommt man Ärger.
Nur wenn man seine DS normal über einen DDNS Dienst erreicht greift dann der nächste Abschnitt.

Und nur nochmal zur Erinnerung der Chef muss die private Nutzung ausdrücklich erlauben oder sie bewusst dulden (also wenn der Chef es mitbekommt und nichts dagegen sagt) und nicht umgekehrt. Diese Erklärung die man manchmal unterschreiben muss zum Thema private Nutzung dient dafür um eben auch beim reinen surfen rechtliche sicherheit zu haben, da sonst eben bewiesen werden muss (und das findet dann immer bei einem teuren Verfahren statt) dass die private Nutzung nicht doch stillschweigend geduldet wurde. Und glaub mir mit solchen Schreiben habe ich Erfahrung, ich habe da schon Stundenlang mit der IT und Rechtsabteilung gestritten. Gibt es diese Erklärung nicht dann kann der Chef nur erstmal eine Abmahnung erteilen (außer es sind Strafrechtliche Dinge [Pornografie, Filesharing, etc.] dann ist ebenfalls eine sofortige Kündigung möglich). Gibt es die Erklärung kann er den Mitarbeiter sofort Kündigen und dazu reicht dann auch schon das aufrufen von web.de/gmx.de oder ähnliches. Und das dann auch während der Arbeitnehmer Pause hat.

Und was du glaubst liegt bei dir ich kann dir aber aus Erfahrung sagen dass eben solches Verhalten schon zu Kündigung und Schadenersatz geführt hat, da dann nämlich über diesen Weg Viren ins Netzwerk kamen. (Und nur als kleine Anekdote manche Admins sehen schon einen Manipulations Versuch darin wenn man den vorgebenen DNS server ändert [sofern man es überhaupt kann], deshalb wird bei einem Großkonzern [bei dem ich mal als externer Mitarbeiter tätig war] alle 30 Minuten sämtliche Einstellungen des Users per Richtlinie überschrieben.)

 

[blurrrr]

Lieber heavy... Nix für Ungut, aber für die "Client"-Seite ist und bleibt es nach wie vor eine normale https-Verbindung? Rein logisch gesehen:

1) DS meldet sich beim Relaydienst (!) (LAN -> QC) (andersherum geht es ja auch nicht, aber: dauerhafte Verbindung zum Relayserver! So kann der Relay-Dienst dem NAS später Bescheid geben (vg. "3"=)
2) Der User meldet sich beim Relaydienst (!) (direkt zur DS geht es ja auch nicht)
3) Relaydienst sagt DS Bescheid, dass der User sich verbinden möchte (initiale Verbindung)
4) User verbindet sich direkt zur Syno (via https, Zugriff via z.B. CIFS/SMB geht ja nach wie vor nicht (wie z.B. bei einem VPN))

Es wird HolePunching genannt, weil auf der NAS(!)-Seite das "Loch" in die Firewall "geschlagen" wird (also im privaten LAN) und nicht auf der Client-Seite. Schliesslich kommt der Client "ohne" explizite Portfreigabe/-weiterleitung auf das NAS.
Firewall sagt: raus ja, rein nein. Es muss also vom NAS (initiiert durch den Relay-Dienst, bei welchem der Client seinen Verbindungswunsch mitteilt) "ausgehend" eine Verbindung erstellt werden, damit der Client sich darüber direkt zum NAS verbinden kann.

EDIT: Hier gibt's das Datenblatt zur Funtionsweise von QuickConnect (sicher auch für andere interessant): http://global.download.synology.com/download/Document/WhitePaper/Synology_QuickConnect_White_Paper.pdf

EDIT2: Die "IT-Abteilung" sagt sowieso immer nein (weil alles andere immer "mehr" Aufwand und weniger Kontrolle bedeutet und das ist der "Job") Was den DNS-Server angeht: in einem ordentlich Netzwerk kannst Du als "User" keine Dinge wie den DNS-Server ändern. Ich sag es mal so: ich bin in diesem Bereich beruflich tätig (also die Seite mit denen Du Dich streitest) und in meinen Netzwerk läuft es wie in anderen: Erstmal ist "garnichts" erlaubt und nur was erlaubt ist wird (ggf. mit Einschränkungen) den Usern bereitgestellt. Ganz einfach, aus die Maus, nichts rein, nichts raus. Wenn auch nur über einen Proxy auch weitere Einschränkungen gemacht werden (z.B. erlaubte Websites: nur konerzintern + Wikipedia (o.ä.), usw.), zudem kann man dort direkt den Caching-Mechanismus nutzen. Die Firewall sorgt dann dafür, dass auch nur der Proxy in Richtung Internet darf und so weiter.... An dieser Stelle "muss" ich es nochmal sagen: Zeichenbrettfunktion.... ganz dolle Sache!

 

[heavy]

<Wikipedia (Tunnnel)>

Erlaubt die Firewall verschlüsselte Verbindungen, wie z. B. zu HTTPS-Servern, lassen sich die Daten an der Firewall nicht mehr mitlesen. Somit ist eine Inhaltsprüfung nicht möglich. Diese Verbindungen eignen sich besonders gut für Tunnel. Hier eignet sich die Software OpenVPN mit dem Protokoll TCP sehr gut, da der Aufbau der Verbindung nahezu identisch mit dem einer Webseite (HTTPS) ist[SUP][3][/SUP].
Hole Punching ist eine Tunneling-Technik, die man anwenden kann, wenn beide Seiten einer Verbindung jeweils durch Firewalls vom Internet abgeschirmt sind.
Arbeitgeber untersagen mitunter die Nutzung anderer Dienste als HTTP und stellen dies durch eine Nutzungsbestimmung und eine Firewall sicher.

Wird eine Firewall in Firmennetzwerken unter solchen Bedingungen umgangen, so ist zu beachten, dass dies als ein vorsätzlicher Verstoß gegen die Nutzungsbestimmung gewertet werden kann, wodurch man als Arbeitnehmer eine fristlose Kündigung riskiert.

<Wikipedia (SPI)>
Manche Programme – z. B. Skype – benutzen dies in einem als Hole Punching bezeichneten Verfahren, um durch Firewalls Point-Point-Verbindungen aufzubauen. Beide Teilnehmer erfahren vom Skype-Server, auf welcher IP-Adresse und welchem Port Skype bei der Gegenseite arbeitet. Dann schicken beide ein UDP-Paket an die Gegenseite. Dort werden diese Pakete beim Eintreffen zwar verworfen, weil keine Input-Regel existiert, erzeugen aber auf der Firewall des ausgehenden Rechners eine Regel, die ab dann 'Antworten' erlaubt. Danach können beide Seiten miteinander kommunizieren. Mit TCP würde das nicht funktionieren, da die Firewall aufgrund von Sequenznummern echte Antwortpakete erkennen kann.

Und nein ich bin kein Wikipedia Autor, sind also nicht meine Eigenen Artikel.

Auf Seite 4 des White Papers steht dass auch die Client Seite ein Loch schlägt da ja die weitere kommunikation auch über QC über den Port 5000 läuft. Nur sollte das nicht gelingen (weil die Firewall doch zu gut ist) dann wird es über den Relay Server umgebogen. Nur ob dann alle Dienste gehen ist nicht sicher.


Edit: An dieser Stelle möchte ich den Thread beenden (ich klinke mich auf jedenfall erstmal wieder aus) denn der Thread Ersteller hat alle Infos die er braucht.

1. QC hatte Probleme denn diese Seite mit Test wurde hier in mehreren Threads von Usern gemeldet und auch auf anderen Platformen kamen Meldungen darüber.
2. Ob bei HansX sich was geändert hat ist offen und muss abgewartet werden
3. Egal wie QC jetzt wirklich funktioniert, so schreibt der TE ja dass er seine DS nicht über die Dyndns Adresse erreichen kann also ist der Port 5000/5001 bei ihm gesperrt und wird durch QC entweder umgangen (deine Meinung) oder aufgebrochen (meine Meinung) und was das für Folgen haben KANN wurde auch beschrieben.

 

[rubaez]

Schönen Dank für die technischen und arbeitsrechtlichen Hinweise. Arbeitsrechtlich bin ich, so glaube ich gut gebildet als Jurist. Die Probleme mit der privaten Internetnutzung sind bei uns geregelt. Als 60-jähriger hatte ich mir vorgenommen, nicht mehr gegen gesetzliche Bestimmungen zu verstoßen ( das jedenfalls zu meiden). Ich darf Surveillance benutzen, wenn ich die Trafic nicht zu doll minimiere.
Das war aber auch nicht das Problem.
Mein Test zu Hause ergab, dass quickconnect offensichtlich prüft, ob ich intern oder extern zugreife. Bin ich im eigenen Netz, schaltet Quickconnect sofort auf die interne IP zu. Dann ist alles gut. Stellt Quickconnect fest, dass ich extern zugreife, scheint Quickconnect eine eigene Server-IP mit Port 80 anzubieten, auf deren Seite die DS gespiegelt wird, um Port-Probleme zu umgehen. Dabei scheint ein Fehler vorgelegen zu haben, der diese IP auch darstellte, ohne Inhalt zu haben. Mein Privat-Netz macht die benötigten Ports schon auf, wenn ich das will. Und einige Hacker hanben schon gemerkt, dass sie beim zweiten falschen Login über mehrere Monate ausgesperrt sind. Mit dieser Falle könnte man sogar Bot-Netze dokumentieren.
Heute Morgen funktionierte wieder alles. in der Adresszeile steht wieder https://xxxx.de.quickconnect.to/ .... je nach APP.
Da ich bei Servern wenig an Selbstheilungskräften glaube, hat Meckern wohl geholten, auf einen Fehler aufmerksam zu machen. So gehört sich das. Schönen Dank an die Mächte im Hintergrund.

 

[heavy]

Danke für die Rückmeldung.

Da Synology hier nicht mitliest (wenigstens offiziell) werden es entweder die Admins selber gemerkt haben oder es wurden entsprechend viele Meldungen direkt an Synology gesendet.

Wenn bei dir alles geregelt ist und du auch noch Jurist (hoffentlich Arbeitsrecht )bist ja dann gehe ich davon aus dass du keine Schwierigkeiten bekommen wirst. Nur lesen wir all zu oft dass eben dem nicht so ist und man dann von uns eben wissen will wie man die Sperren umgehen kann. Bzw erst wird gefragt wie man sie umgeht und auf nachfragen kommt dann eben raus dass man vom Arbeitsplatz versucht "nach hause zu telefonieren" (kleine IT Anspielung) z.b wollte eben ein User einen Internet Browser auf seiner DS installieren und erst nach langen hin und her hat er rausgerückt dass er so den Webfilter an seinem Arbeitsplatz umgehen will.

 

[HansX]

Hallo

wilde Diskussion, die auf so eine simple Frage entsteht. Aber egal ...
Ich für meinen Teil kann nur sagen, dass es auch heute morgen nicht funktioniert. Allerdings kommt nicht mehr die Umleitung auf 195.xxx. sondern folgende Seite: XXX.quickconnect.to/portal/error.html?error=21 mit folgenden Hinweisen:

Verbindung zu XXX kann nicht hergestellt werden.
Überprüfen Sie bitte die folgenden Einstellungen.
-Sie haben die richtige QuickConnect-ID eingegeben.
-XXX ist eingeschaltet und mit dem Internet verbunden.
-QuickConnect Relay-Dienst ist für XXX aktiviert (unter Systemsteuerung > QuickConnect > Erweitert > Optionen).

Meine ID ist korrekt, sonst hätte ich meine DS nicht über QC erreicht. Meine NAS ist demzufolge eingeschaltet und am Netz und auch der RElaydienst hat seine Haken gesetzt.

Warum das jetzt den Fehler 21 produziert bleibt rätselhaft. Audiostation wird direkt im Browser gestartet und streamt Musik. Photo- und Surveillancestation öffnen ein Browserfenster mit der Fehlermeldung.
Und ja, das ist in der Firma und ja es lief schon mehrfach von hier und nein, es ist bei uns nicht verboten weil ich das darf.

Gruß Hans J

 

[rubaez]

Darauf kann ich antworten.
Die genannte Mitteilung des Serverst kommt, wenn die Trafic des Servers von Synology nicht ausreicht. das hat bei vorheriger geglückter Verbindung nichts mit der übergebenen Adresse zu tun.Bei mir hat es geholfen, diese Anfrage häufiger zu stellen und manchmal erhielt ich bereits beim nächsten Mal eine Verbindung - manchmal aber auch nicht. Ohne die Einstellungen zu ändern, klappte es dann später mal. Manchmal habe ich über die Handy-APP "DS Finder" die DS neugestartet und gezwungen sich am Server neu anzumelden. Ist aber wie ein Lotteriespiel und übers Jahr sehr selten vorgekommen. Dann behelfe ich mir mit dem Handy, wo Ports nicht gesperrt sind und QC deshalb nicht notwendig ist.

 

[Frogman]

... Wenn Du "immer" dran kommen möchtest, DDNS + VPN verwenden (sicher),

Das gilt so nicht, denn je nach VPN-Protokoll werden die durchaus auch in Netzen geblockt.

... . DDNS + statische Portweiterleitungen verwenden (eher unsicher).

Das ist totaler Unsinn! Wegen solcher halbgarer Aussagen fühlen sich dann wieder unerfahrene User völlig verunsichert.

 

[blurrrr]

Bitte? Zum einen: das VPN kann man "sehr wohl" und "sehr oft" durch alles mögliche durchboxen (vermutlicht nicht in der "offiziellen Standardconfig", da hast Du dann wohl recht), trotzdem möglich.
Was DU redest ist totaler "Unsinn" (SPIEGEL!!! *lol* ) denn so sind die Dienste "immer" offen aus dem Internet verfügbar - würde man Synology nun noch 1000%ig vertrauen, wäre selbst Quickconnect die bessere Alternative... Man muss immerhin davon ausgehen, dass man das System nicht "selbst" up2date hält, sondern die Pakete entsprechend "geliefert" werden, wenn Synology die ausrollt, selber patchen? Eher unwahrscheinlich...

Also komm mir ma nich komisch... Freundchen... (ich habs auch extra mit vielen Smiley geschrieben, damit es nicht so bierernst rüber kommt )

EDIT: Wir können uns aber auch gern via PM über diese Thematik austauschen!

 

[Frogman]

4) User verbindet sich direkt zur Syno (via https, Zugriff via z.B. CIFS/SMB geht ja nach wie vor nicht (wie z.B. bei einem VPN))

Falsch, eben nicht direkt!

Es wird HolePunching genannt, weil auf der NAS(!)-Seite das "Loch" in die Firewall "geschlagen" wird (also im privaten LAN) und nicht auf der Client-Seite. Schliesslich kommt der Client "ohne" explizite Portfreigabe/-weiterleitung auf das NAS.

Wenn Du denn schon das allseits bekannte Whitepaper zitierst, dann solltest Du es auch gut lesen...

 

[Frogman]

Bitte? Zum einen: das VPN kann man "sehr wohl" und "sehr oft" durch alles mögliche durchboxen (vermutlicht nicht in der "offiziellen Standardconfig", da hast Du dann wohl recht), trotzdem möglich.

Dann informiere Dich mal, bevor Du solche Gerüchte in die Welt setzt. Und am besten erklärst Du jetzt mal an dieser Stelle Deine "geheime Konfig", mit der Du ein L2TP/IPSec-Tunnel aus einem Hotel-WLAN einrichtest, in dem nur Port 80 und 443 erlaubt sind.

denn so sind die Dienste "immer" offen aus dem Internet verfügbar -

Aha. Und wenn Du einen VPN-Port weiterleitest oder aber 443, auf dem u.a. ein OpenVPN läuft, dann sind die nicht immer offen? Totaler Unsinn, den Du hier schreibst.
Informiere Dich bitte mal, was man über 443 oder andere Ports alles einrichten kann und wie man mit entsprechender Konfiguration eine verschlüsselte Verbindung darüber absichert.

 

[blurrrr]

Meine Kurzfassung war auch "gekürzt", daher die Kurzfassung (leicht verständlich, für nicht-Techies...), ich habe nicht ohne Grund das Whitepapier mitverlinkt.

Auf der andere Seite wird mit jeder ausgehenden Anfrage ein Loch geöffnet, da die Firewall ein Antwortpaket erwartet... aber wem erklär ich das... Das weisst Du ja bestimmt sowieso

"The Portal Server would then decrypt and modify the specific HTTP headers so as to inform the destination NAS of the identity of the connecting client. Having done so, the Portal Server then sends the data to the destination Synology NAS via the network virtual tunnel. Once again, data transmission over the network virtual tunnel is secured with end-to-end encryption if SSL is enabled." < das ist es, warum es überhaupt erst funktionieren kann. Es werden schlichtweg Headerinformationen umgeschrieben...

Das "Problem" an dieser Stelle ist übrigens auch nicht der Client, welcher sowieso bei offenen Ports via http(/s) zugreifen könnte, sondern der SERVER / NAS, welcher sich HINTER dem NAT-Device befindet und wo eben KEINE Ports direkt weiterleiten. Diese werden dann "auf Anfrage" des Clients vom NAS von "innen" nach "aussen" geöffnet... aber da kann ich mir nu den Mund fusselig reden... das is n bissken wie mit den Windmühlen....

EDIT: Antwort zu Deinem letzten Post (da gibste ja richtig Gas...): Willste irgendwie Stress provozieren? Wenn Du mal Bescheid wüsstest, wüsstest Du "sehr wohl" (und vermutlich weisste es auch und willst nur Ärger machen...), dass man ein OpenVPN auf Port 443 betreiben kann (jo, IPSec wird da wohl etwas schwierig ). Zudem lässt sich das VPN auch abseits vom NAS betreiben (z.B. direkt auf dem Router), so oder so ist dann nur EIN Dienst von aussen erreichbar, das VPN.

EDIT2: Wie schon bereits erwähnt, können wir uns gern via PM darüber austauschen und es richtig krachen lassen. Da ich diesbezüglich aber von Dir noch nichts gehört habe,gehe ich eher davon aus, dass dies nicht in Deinem Interesse liegt und Du lieber ganz öffentlich Krawall erzeugen möchtest, was ich persönlich eher weniger gut finde...