HTTPS Seiten ohne Porteingabe öffnen
Hallo,
ich experimentiere zurzeit ein wenig mit IIS rum bzw. soll das mein Haupt Webserver werden.
Zu meiner Situation: Ich habe einen WS2012RS, auf dem IIS10 läuft. Nebenbei läuft auch noch Paessler PRTG auf diesem Server. Paessler belegt für https den Port 443 für das Web UI.
Im IIS sind zurzeit drei Sites angelegt. Domain1, hinter der eine einfache Website läuft ( also nur eine HTML Seite mit iFrames von YT Videos). Domain 2 und 3 sind geparkt und verweißen auf einen Pfad in dem nichts ist. die drei Domains sind von Strato und bei allen dreien ist DynDNS aktiviert und wird immer geupdatet.
Das heißt wenn ich von außen https://domain1.de eingebe lande ich auf dem Paessler WebUI und mit http://domain1.de auf der einfachen HTML Seite. Soweit so gut das funktioniert auch alles einwandfrei. Jetzt will ich mir eine Cloud machen mit Owncloud. Diese soll natürlich auch auf dem IIS laufen. Dafür hab ich eine Subdomain mit cloud.domain1.de bei Strato angelegt und der auch DynDNS aktiviert mit der Hoffnung, wenn ich in IIS die Site den virtuellen Hostnamen cloud.domain1.de gebe, das die Subdomain automatischen ohne Portangabe und nur https davor auf die Site verzweigt. Die Site hat den Port 444 und er ist überall freigegeben. Der Link geht aber leider auf das WebUI von Paessler.
Habt ihr eine Idee wie ich das lösen könnte, dass ich mit zwei Subdomains, also webmon.domain1.de und cloud.domain1.de auf die jeweils richtigen Webseiten weiterleite? Ich habe es schon mal mit SRV-Records auf die jeweiligen Ports versucht nur hat das noch nie funktioniert...
Ich hoffe ihr könnt mir helfen. Ich habe vollen Zugriff auf die Domains von Strato und könnte alle DNS Records etc. benutzten.
Mfg
ich experimentiere zurzeit ein wenig mit IIS rum bzw. soll das mein Haupt Webserver werden.
Zu meiner Situation: Ich habe einen WS2012RS, auf dem IIS10 läuft. Nebenbei läuft auch noch Paessler PRTG auf diesem Server. Paessler belegt für https den Port 443 für das Web UI.
Im IIS sind zurzeit drei Sites angelegt. Domain1, hinter der eine einfache Website läuft ( also nur eine HTML Seite mit iFrames von YT Videos). Domain 2 und 3 sind geparkt und verweißen auf einen Pfad in dem nichts ist. die drei Domains sind von Strato und bei allen dreien ist DynDNS aktiviert und wird immer geupdatet.
Das heißt wenn ich von außen https://domain1.de eingebe lande ich auf dem Paessler WebUI und mit http://domain1.de auf der einfachen HTML Seite. Soweit so gut das funktioniert auch alles einwandfrei. Jetzt will ich mir eine Cloud machen mit Owncloud. Diese soll natürlich auch auf dem IIS laufen. Dafür hab ich eine Subdomain mit cloud.domain1.de bei Strato angelegt und der auch DynDNS aktiviert mit der Hoffnung, wenn ich in IIS die Site den virtuellen Hostnamen cloud.domain1.de gebe, das die Subdomain automatischen ohne Portangabe und nur https davor auf die Site verzweigt. Die Site hat den Port 444 und er ist überall freigegeben. Der Link geht aber leider auf das WebUI von Paessler.
Habt ihr eine Idee wie ich das lösen könnte, dass ich mit zwei Subdomains, also webmon.domain1.de und cloud.domain1.de auf die jeweils richtigen Webseiten weiterleite? Ich habe es schon mal mit SRV-Records auf die jeweiligen Ports versucht nur hat das noch nie funktioniert...
Ich hoffe ihr könnt mir helfen. Ich habe vollen Zugriff auf die Domains von Strato und könnte alle DNS Records etc. benutzten.
Mfg
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 313156
Url: https://administrator.de/forum/https-seiten-ohne-porteingabe-oeffnen-313156.html
Ausgedruckt am: 07.04.2025 um 11:04 Uhr
4 Kommentare
Neuester Kommentar
Hallo,
zuerst: es ist nicht möglich mit DNS auf einen Webserver mit einem nicht-Standard-Port zuzugfreifen.
Es wird immer http(s)://domain:port sein
https=443 und http=80
Aber natürlich gibt es dafür Lösungen.
Stichwort Reverse-Proxy. Das ist ein Web-Server der neben eigenen Inhalt noch Inhalte von anderen Servern holt.
https://de.wikipedia.org/wiki/Reverse_Proxy
Vermutlich wird der PRTG nicht als Reverse-Proxy laufen wollen.
Also bekommt der PRTG z.B. den Port 444 oder 8443.
Auf Port 80 und 443 läuft ein Webserver der als Reverse-Proxy laufen kann.
Ich würde nginx empfehlen, aber es geht auch apache oder iis.
Dort hinterlegst Du
1) lokale Inhalte zu Domänen und Subdomänen
2) für die Domäne https://domain1.de hinterlegst Du eine Weiterleitung auf https://domain1.de:8443
So im kurzen.
Viele Grüße
Stefan
zuerst: es ist nicht möglich mit DNS auf einen Webserver mit einem nicht-Standard-Port zuzugfreifen.
Es wird immer http(s)://domain:port sein
https=443 und http=80
Aber natürlich gibt es dafür Lösungen.
Stichwort Reverse-Proxy. Das ist ein Web-Server der neben eigenen Inhalt noch Inhalte von anderen Servern holt.
https://de.wikipedia.org/wiki/Reverse_Proxy
Vermutlich wird der PRTG nicht als Reverse-Proxy laufen wollen.
Also bekommt der PRTG z.B. den Port 444 oder 8443.
Auf Port 80 und 443 läuft ein Webserver der als Reverse-Proxy laufen kann.
Ich würde nginx empfehlen, aber es geht auch apache oder iis.
Dort hinterlegst Du
1) lokale Inhalte zu Domänen und Subdomänen
2) für die Domäne https://domain1.de hinterlegst Du eine Weiterleitung auf https://domain1.de:8443
So im kurzen.
Viele Grüße
Stefan
Moin,
auch wenn deine Grundidee durchaus richtig ist, stimmt eine deiner Aussagen nicht:
Dank der SRV Records geht das durchaus. Allerdings sind die Implementierungen hinsichtlich HTTP eher selten bis gar nicht vorhanden. Von daher ist die Aussage auch nicht komplett falsch.
Ansonsten stimme ich die komplett zu: Reverseproxy ist das Mittel der Wahl.
https://blogs.iis.net/owscott/creating-a-reverse-proxy-with-url-rewrite- ...
Gruß
Chris
auch wenn deine Grundidee durchaus richtig ist, stimmt eine deiner Aussagen nicht:
zuerst: es ist nicht möglich mit DNS auf einen Webserver mit einem nicht-Standard-Port zuzugfreifen.
Es wird immer http(s)://domain:port sein
https=443 und http=80
Es wird immer http(s)://domain:port sein
https=443 und http=80
Dank der SRV Records geht das durchaus. Allerdings sind die Implementierungen hinsichtlich HTTP eher selten bis gar nicht vorhanden. Von daher ist die Aussage auch nicht komplett falsch.
Ansonsten stimme ich die komplett zu: Reverseproxy ist das Mittel der Wahl.
https://blogs.iis.net/owscott/creating-a-reverse-proxy-with-url-rewrite- ...
Gruß
Chris