Subdomain Forwarding für verschiedene https Dineste auf externe Server

  • Hallo!


    Ein Laie benötigt vermutlich nur den Schubs in die richtige Richtung... Danke schon mal vorab!


    Ich habe bei Netcup meine eigentliche Homepage. Die wird klein und übersichtlich und soll den Großteil des Traffics schon mal abfangen.


    Für einen kleinen Kreis Leute möchte ich nun verschiedene Dienste als Subdomain verfügbar machen, die auf einem Server hinter meinem privaten Router verfügbar sind, also nur über Ports unterschieden werden können. Der Server selbst hat einen eigenen Dynamic-DNS Eintrag.


    Der Vorteil für mich und alle anderen wäre ja, dass ich mit einem synchronisierten Zertifikat den kompletten "Strang" per https verschlüsseln kann.


    Danke schon mal für die richtigen Stichworte oder Suchbegriffe!

  • Hi Hecke29!


    Danke, so schlimm ist es dann doch nicht ;) Ich habe mir mal meine Optionen im Customer Control Panel angesehen und hatte gehofft, dass die Option Subdomain und Weiterleitung das ganze einfach erledigen. Scheinbar tut es das aber nicht. Also muss ich da eine Webseite kreieren, die den Job erledigt?


    Hallo Twisterado

    Als Router läuft noch eine FritzBox. Im direkten Zugriff funktioniert aus alles, nur möchte ich jetzt eben statt https://dnymische.com:7890 lieber https://nextcloud.meinedomain.de/ nutzen.

  • Wenn gängige Browser endlich SRV-Records unterstützen würden, gäb es kein Problem :/

    ChestSort: Automatische Kistensortierung in Minecraft - www.chestsort.de


    www.raucher-werden.de - www.serioese-alternative.de - www.jeff-media.de

  • Als Router läuft noch eine FritzBox. Im direkten Zugriff funktioniert aus alles, nur möchte ich jetzt eben statt https://dnymische.com:7890 lieber https://nextcloud.meinedomain.de/ nutzen.

    Prinzipiell könntest du einen CNAME Eintrag in deinem DNS einstellen um deine DynIP zu "verschleiern". Dann würde ein Aufruf deiner Subdomain direkt an deinen Router gehen. Dafür müsstest du auf deinem Router Port 443 auf 7890 weiterleiten.


    Das löst aber das hier nicht:

    Der Vorteil für mich und alle anderen wäre ja, dass ich mit einem synchronisierten Zertifikat den kompletten "Strang" per https verschlüsseln kann.

    Dafür brauchst du wie schon gesagt einen ReverseProxy. Das bedeutet, ein Besucher ruft deine Subdomain auf und fragt dafür den Netcup Server an. Der Netcup-Server frag deinen Router an (geht dann auch auf Port 7890), ruft die Seite ab und liefert sie an den Besucher aus. Dein Besucher kommuniziert per HTTPS (Port 443) mit dem Netcup server und dessen Zertifikat. Die Kommunikation zwischen Netcup und deinem Router hängt dann von deiner Konfiguration ab.



    Edit:

    Beim nochmal lesen habe ich verstanden, dass du Zuhause auch einen Webserver hast und ihm das Netcup-SSL-Zertifikat geben willst? Dann kannst du Lösung 1 nehmen und einen DNS CNAME Eintrag von nextcloud.meinedomain.de auf dynamische.com machen. Nur der Port ist dann noch unschön. Entweder musst du Port 443 am Router angeben, oder das mit Lösung2 per ReverseProxy umbiegen


    Edit2: Ich würde aber eher dazu raten dem Server Zuhause ein eigenes Zertifikat zu geben

  • Danke Euch allen für die ausführliche Erklärung!


    Ja, ich habe einen kleinen Netcup Account, der nur die Homepage hosten soll, die jeder aufrufen darf / kann / soll. Für einige wenige gibt es dann noch sub-domains, die auf meinen lokalen Server tunneln. Der läuft auch schon, aber die verschiedenen Dienste werden eben über Ports abgehandelt und das verursacht leider Probleme.


    Ich für meinen privaten Server schon ein Zertifikat und das wird auch schon automatisch aktualisiert. Ich hatte nur befürchtet, dass das Probleme macht, wenn ich per Reverse-Proxy plötzlich das Zertifikat wechsle. Aber wenn ich eine andere Sub-Domain aufrufe, ist das ja eine andere Seite und damit sollte dann auch ein neues Zertifikat gültig sein dürfen.


    Jetzt muss ich dann nur noch lernen, wie ich eine netcup sub-domain Seite erstelle, die ein Reverse Proxy ist... Ich strapaziere mal die SuFu :)

  • Ja, ich habe einen kleinen Netcup Account, der nur die Homepage hosten soll, die jeder aufrufen darf / kann / soll. Für einige wenige gibt es dann noch sub-domains, die auf meinen lokalen Server tunneln. Der läuft auch schon, aber die verschiedenen Dienste werden eben über Ports abgehandelt und das verursacht leider Probleme.

    Nur kurz zum Verständnis: Du hast hier bei Netcup einen eigenen Server oder ein Webhosting Paket?

  • Ein Webhosting Paket. Ich gehe also davon aus, dass das nicht funktioniert, weil ich den Redirector nur schreiben kann, wenn ich meinen eigenen Server habe, oder?

    Genau. Aus diesem Grund habe ich auch nachgefragt. Einen Reverse Proxy kannst du im Grunde nur konfigurieren, wenn du selbst den Server betreibst. Aber wäre das nicht auch eine Option? Wenn du selbst sowieso eigene Server administriert, wäre es doch durchaus eine Option, einfach einen kleinen VPS zu mieten und diesen als RP zu nutzen. Das macht auch das SSL Zertifikats Management einfacher

  • Ich für meinen privaten Server schon ein Zertifikat und das wird auch schon automatisch aktualisiert. Ich hatte nur befürchtet, dass das Probleme macht, wenn ich per Reverse-Proxy plötzlich das Zertifikat wechsle. Aber wenn ich eine andere Sub-Domain aufrufe, ist das ja eine andere Seite und damit sollte dann auch ein neues Zertifikat gültig sein dürfen.

    Bei der Benutzung eines Reverse-Proxies sieht nur der Proxy das Zertifikat des Backend-Servers, der Client niemals – es werden im Optimalfall ja alle Referenzen umgeschrieben (ansonsten wäre der Reverse-Proxy unvollständig/durchlässig, was man in der Regel nicht will).

    Wenn die "verschiedenen Dienste", die oben erwähnt wurden, allesamt HTTP(S)-basiert sind, empfehle ich einen Blick auf https://github.com/michaelfranzl/no.php (Transparent reverse proxy written in PHP).

    Das vorgenannte Script ist dann in den Zeilen 26, 28 und 30 anzupassen und sollte als "index.php" o.ä. beim Aufruf einer Subdomäne direkt zur Ausführung kommen; eine Angabe eines abweichenden Ports analog zu $backend_url = "http://vserver06.local:2812"; ist problemlos möglich. (Am Besten erst einmal auf dem eigenen Server damit testen, um sich mit der Funktionsweise vertraut zu machen.)

  • Nachtrag: Das obengenannte PHP-Script no.php sollte auch problemlos mit einem Webhosting-Paket zu nutzen sein, sofern die zugehörigen Regeln in .htaccess ausgeführt/umgesetzt werden können – diese sind anzupassen, wenn das Script umbenannt wird! – und das curl-PHP-Modul installiert ist (vgl. Auflistung hier, nach welcher dieses vorhanden sein sollte).

  • Vielen Dank!


    Hintergrund für ein kleines Hosting-Paket war natürlich der Gedanke erst mal zu üben. Wenn das no.php funktioniert, ist das eine tolle Lösung! Natürlich muss man mal sehen, wie mein Server genutzt wird. Sollte es komplexer werden, wäre eine gemietete professionelle Plattform sicher sinnvoller als ein zusammen gebastelter PC aus übrig gebliebenen Alt-Teilen. Letztendlich geht es um ein Hobby, es geht also niemand unter, wenn es nicht, oder nicht auf Anhieb funktioniert.,


    Ich werde mir no.php mal ansehen.