vpn über Port 443 geht in der Regel nicht, weil zumindestens ein Proxy dazwischen hängt. Der Proxy erwartet nunmal http(s).
Möglich wären dann https- Tunnel (schwierig/ nicht unbedingt erfolgreich) oder SSL-VPN.
Ich hatte mal ein SSL-VPN namens SSLexplorer im Einsatz, war spitze, doch das ging dann leider den komerziellen Weg mit Hardwarebundelung.
Ich experimentiere grade mit BarracudaDrive. In dem Umfeld könnte was gehen. Ich werde bei Erfolg berichten.
Denket aber bitte auch an eines: Die Firmenpolicies wurden nicht ohne Grund gemacht! Ich sitze in der IT und könnte so etwas feststellen.
da ich noch ziemlicher NAS-Anfänger bin, habe ich ein paar Probleme mit der Anleitung. So bin ich vorgegangen:
Subdomain nas.DOMAIN.COM für mein NAS als CNAME eingerichtet . Nach Eingabe der Subdomain lande ich auf der korrekten Zieldomain. Also kein Problem.
Was bedeutet „jedem Dienst eine eindeutige Portnummer zuweisen“? Ich habe auf meinem Speedport W921V eine UDP-Umleitung für den Port 8080 eingerichtet und auf das NAS gerichtet. Ist das korrekt?
Der NAS hat eine feste IP-Adresse, da ich aber über VPN auf das NAS zugreife, habe ich die feste VPN-Adresse unter /etc/hosts eingetragen und mit nas.DOMAIN.com verbunden.
Wenn ich jetzt nach Aufgabe einer VPN-Verbindung im internen Netz nas.DOMAIN.com eingebe, lande ich auf dem NAS. Allerdings funktioniert jetzt der Zugriff aus dem externen Netz nicht mehr, wenn ich mich am selben Rechner befinde (Laptop). Wähle ich mich über einen USB-Stick ein, scheitert jeder Verbindungsversuch.
Ich denke mal, das liegt daran, dass ich den letzten Schritt „Dann muss man natürlich noch die entsprechenden Portfreigaben anlegen und den entsprechenden Netzwerkgeräten zuführen“ nicht durchgeführt habe. Was bedeutet das?
Für einen Tipp und ggf. notwendige Korrekturen wäre ich Euch sehr dankbar.
schöner Post, aber ich kann das wegen der Ports nicht nutzen (bei mir auf der Arbeit ist alles außer 80 und 443 gesperrt). Die Benutzung von unterschiedlichen Ports finde ich persönlich aber auch nicht so elegant. Ich habe das zum Anlass genommen, das bei mir zu überdenken und löse das jetzt mit DNS Wildcards und Reverse Proxy.
Eine DNS Wildcard löst beliebige Subdomains auf eine IP auf, also sowohl a.meine.domain.de als auch b.meine.domain.de. Das bieten die wenigsten Dynamic-DNS Anbieter, hier einer der wenigen: http://www.ddnss.de/. Der Update geht sogar über ein eindeutigen Schlüssel („KEY“) in der URL, also ohne Username und Passwort in der URL. Die meisten anderen Dienste schicken genau diese Infos unverschlüsselt übers Netz…
Auf dem Router selbst wird wie üblich eine Weiterleitung eingerichtet - bei mir nur für 443 (https) auf ein Linux System. Windows ging auch, aber ich vertraue Linux einfach mehr.
Auf dem Linux System horcht dann nginx, ein Reverse Proxy auf die eingehenden Anfragen und leitet diese je nach DNS-Name an die internen Systeme: https://ips.meine.domain.de an IPS, https://cam1.meine.domain.de an eine Kamera usw. Nginx ist in der Konfiguration ziemlich biestig und nichts für Anfänger, aber wenn es ein mal läuft merkt man das nicht mehr.
Als Sicherheitsaspekt lasse ich Anfragen ohne Subdomain - hier bspw. https://meine.domain.de - einfach ins leere laufen. Wer meine Ports scannt, sieht also den Reverse Proxy, kommuniziert aber niemals mit internen Systemen. Ist zugegeben Security by Obsucirty, reicht mir i.V.m. https und Passwort aber allemal.
Auf dem Linux-System lasse ich nebenbei noch ein internen DNS laufen, der die internen Systeme genau wie die externen auflöst. In IPS muss übrigens nicht mal ein weiterer Konfigurator für https eingerichtet werden.
Das ist zugegeben deutlich komplizierter, meines Erachtens aber sicherer und ein mal eingerichtet auch einfacher in der Benutzung.
Wer seine Fritzbox gegen eine Sophos UTM eingetauscht hat, so wie ich, kann sich glücklicherweise die biestige Konfig von nginx sparen und hat die selbe Funktionalität bereits in der Firewall.
Seid dem bin ich vom Port-Mapping auch weg.
Gerade bei kastrierten Arbeitssystemen ist sowas sehr hilfreich…
Mache ich schon länger so. TeamViewer läuft auf dem Server und damit habe ich Zugriff auf alle Geräte im Netz. Außer, dass der TeamViewer auf dem Tablet einmal gestreikt hat weil er auf einen Server zugreifen sollte und meinte es wäre eine kommerzielle Nutzung funzt das ansonsten sehr reibungslos.