"Virtual IP"
- Thread starter jangut
- Start date
Ich mache das auch so. Der Trick hier heißt Gateway-VM bzw. Reverse Proxy.
Wenn du 3 Subdomains über eine IP auf 3 VMs weiterleiten willst, dann musst du 4 VMs machen. Auf VM1, VM2, VM3 usw. einfach einen Webserver deiner Wahl installieren (bzw plex, emby oder was sonst du per Webinterface erreichen willst) und den für HTTP einrichten. Dann erstellst du eine vierte VM die dir als Gateway dient. Alles was auf Port 80 und 443 an deinen Router gerichtet ist leitest du dann per Port-Forwarding an die Gateway-VM weiter. Die nimmt alle HTTP und HTTPS Anfragen entgegen und entscheidet dann, was mit denen getan werden muss.
Im Endeffekt richtest du auf der Gateway-VM dann auch apache2 oder nginx als Webserver ein, erstellst auf dieser 3 vhosts für jede Subdomain und trägst dann bei der jeweiligen vhost-Konfig ein, dass z.B. alles was von vm1.beispiel.de kommt an VM1 über HTTP weitergereicht werden soll.
Wichtig hierbei ist dann aber, dass du da nicht komplett alles die VMs weiterleitest. Wenn du SSL von Letsencrypt nutzen willst, dann muss die Gateway-VM alle SSL Zertifikate für die Subdomains erzeugen. Das macht der certbot indem er eine Datei im Ordner "/.well-known/" erstellt auf die per HTTP von LEtsencrypt zugegriffen wird, um zu prüfen, ob du wirklich der Eigentümer des Server bist. Alle Anfragen die sich an den "/.well-known/" Ordner jeder Subdomain richten müssen dann lokal auf der Gateway-VM verarbeitet werden und dürfen nicht an die anderen VMs weitergereicht werden. Dann brauchen die anderen VMs auch kein HTTPS mehr können, da die Gateway-VM als Mittelsmann dient und HTTPS Anfragen an die Subdomains entgegennimmt aber intern in deinem Subnetz diese dann den VMs nur als HTTP zustellt. Die VMs schicken dann die Antworten wieder per HTTP zurück zum Gateway und der die weiter per HTTPS ins Internet.
Wenn du 3 Subdomains über eine IP auf 3 VMs weiterleiten willst, dann musst du 4 VMs machen. Auf VM1, VM2, VM3 usw. einfach einen Webserver deiner Wahl installieren (bzw plex, emby oder was sonst du per Webinterface erreichen willst) und den für HTTP einrichten. Dann erstellst du eine vierte VM die dir als Gateway dient. Alles was auf Port 80 und 443 an deinen Router gerichtet ist leitest du dann per Port-Forwarding an die Gateway-VM weiter. Die nimmt alle HTTP und HTTPS Anfragen entgegen und entscheidet dann, was mit denen getan werden muss.
Im Endeffekt richtest du auf der Gateway-VM dann auch apache2 oder nginx als Webserver ein, erstellst auf dieser 3 vhosts für jede Subdomain und trägst dann bei der jeweiligen vhost-Konfig ein, dass z.B. alles was von vm1.beispiel.de kommt an VM1 über HTTP weitergereicht werden soll.
Wichtig hierbei ist dann aber, dass du da nicht komplett alles die VMs weiterleitest. Wenn du SSL von Letsencrypt nutzen willst, dann muss die Gateway-VM alle SSL Zertifikate für die Subdomains erzeugen. Das macht der certbot indem er eine Datei im Ordner "/.well-known/" erstellt auf die per HTTP von LEtsencrypt zugegriffen wird, um zu prüfen, ob du wirklich der Eigentümer des Server bist. Alle Anfragen die sich an den "/.well-known/" Ordner jeder Subdomain richten müssen dann lokal auf der Gateway-VM verarbeitet werden und dürfen nicht an die anderen VMs weitergereicht werden. Dann brauchen die anderen VMs auch kein HTTPS mehr können, da die Gateway-VM als Mittelsmann dient und HTTPS Anfragen an die Subdomains entgegennimmt aber intern in deinem Subnetz diese dann den VMs nur als HTTP zustellt. Die VMs schicken dann die Antworten wieder per HTTP zurück zum Gateway und der die weiter per HTTPS ins Internet.
Last edited:
Du brauchst halt immer einen Proxy als Mittelsmann und der muss mit Subdomains klarkommen. Wenn ein Webserver dein Proxy ist, dann geht da halt nur HTTP und HTTPS mit TCP. kA ob es da auch andere Proxies gibt die sowas für SSH usw. können. Wenn du unbedingt alle 3 VMs mit SSH aus dem Internet erreichen willst, dann weise doch beim Port-Forwardung einfach verschiedene Ports zu.
Einkommendes auf Port 1001 nach VM1 port 22 weiterleiten,
Einkommendes auf Port 1002 nach VM2 port 22 weiterleiten, usw.
Das kannst du dann auch einfach alles vom Router machen lassen und brauchst keinen extra Proxy.
Im Endeffekt weisen ja eh alle Subdomains auf deine öffentliche IP. Dann kannst du eine beliebige der Subdomains auswählen und halt über den Port bestimmen, zu welcher VM du dich per SSH oder sonst was verbinden willst.
vm1.beispiel.de:1001 führt dich dann zu VM1 Port 22,
vm1.beispiel.de:1002 führt dich zu VM2 Port 22 usw.
Ist bei SSH und Co ja auch nicht wirklich wichtig, ob man als Client immer Port 22 nutzt oder halt irgendwas anderes, solange das halt bei der VM ankommt. Gerade bei SSH wäre es eh keine doofe Idee, wenn man gezielt nicht den Standard-Port 22 für Zugriffe aus dem Internet wählt, da man so nicht so leicht gehackt wird. Ich persönlich will z.B. garnicht, dass da meine VMs per SSH aus dem Internet erreichbar sind. Da verbinde ich mich lieber kurz per VPN zu meiner VPN-Server-VM und bin dann von überall auf der Welt im Heimnetz unterwegs und dann geht ja auch SSH und Co wieder bzw. ich kann dann auch alle VMs direkt über ihre lokalen IPs ansprechen. Das macht die Sache jedenfalls deutlich sicherer.
Einkommendes auf Port 1001 nach VM1 port 22 weiterleiten,
Einkommendes auf Port 1002 nach VM2 port 22 weiterleiten, usw.
Das kannst du dann auch einfach alles vom Router machen lassen und brauchst keinen extra Proxy.
Im Endeffekt weisen ja eh alle Subdomains auf deine öffentliche IP. Dann kannst du eine beliebige der Subdomains auswählen und halt über den Port bestimmen, zu welcher VM du dich per SSH oder sonst was verbinden willst.
vm1.beispiel.de:1001 führt dich dann zu VM1 Port 22,
vm1.beispiel.de:1002 führt dich zu VM2 Port 22 usw.
Ist bei SSH und Co ja auch nicht wirklich wichtig, ob man als Client immer Port 22 nutzt oder halt irgendwas anderes, solange das halt bei der VM ankommt. Gerade bei SSH wäre es eh keine doofe Idee, wenn man gezielt nicht den Standard-Port 22 für Zugriffe aus dem Internet wählt, da man so nicht so leicht gehackt wird. Ich persönlich will z.B. garnicht, dass da meine VMs per SSH aus dem Internet erreichbar sind. Da verbinde ich mich lieber kurz per VPN zu meiner VPN-Server-VM und bin dann von überall auf der Welt im Heimnetz unterwegs und dann geht ja auch SSH und Co wieder bzw. ich kann dann auch alle VMs direkt über ihre lokalen IPs ansprechen. Das macht die Sache jedenfalls deutlich sicherer.
Last edited:
Auch eine gute Idee, mit subdomain's ist aber irgendwie ein Stückchen eleganter 
https://www.howtoforge.com/reverse-proxy-for-https-ssh-and-mysql-mariadb-using-nginx/
Habe das hier gefunden und werde es später mal testen! Danke für deinen Lösungsansatz!
EDIT:
Im Grunde ist das mit den Ports simpler, jedoch würde ich eh nicht Port 22 nutzen, sondern irgendein anderen.
EDIT2:
Stimmt, eine VPN könnte ich auch nutzen! Trotzdem werde ich es versuchen, so das man es im Zukunft nutzen kann, wenn benötigt
LG
https://www.howtoforge.com/reverse-proxy-for-https-ssh-and-mysql-mariadb-using-nginx/
Habe das hier gefunden und werde es später mal testen! Danke für deinen Lösungsansatz!
EDIT:
Im Grunde ist das mit den Ports simpler, jedoch würde ich eh nicht Port 22 nutzen, sondern irgendein anderen.
EDIT2:
Stimmt, eine VPN könnte ich auch nutzen! Trotzdem werde ich es versuchen, so das man es im Zukunft nutzen kann, wenn benötigt
LG
Last edited:
Ja, genau sowas meine ich. Die behandeln auch letsencrypt, sollte also passen. Weil mit SSL hatte ich erst ziemlich zu kämpfen, dass das alles auch über HTTPS läuft.
Wenn der Zugang eh nur für dich zum Administrieren ist, dann würde ich immer VPN wegen der Sicherheit bevorzugen. Das einzige was bei mir durch die Firewall am Router kommt ist der Port für den VPN Zugang und halt alles an öffentlichen Diensten die auch andere fremde Personen erreichen können sollen. Weboberflächen zum Administrieren, SSH und alles sonstige was niemand außer mir nutzen können muss bleibt dann schon abgeschottet.
Das hängt von deinen Proxy-Einstellungen ab. Mit den richtigen Header-Einstellungen sieht der Browser nur die Domain und schreibt die Adresse nicht auf die IP vom Ziel-Server um. Oder was meinst du genau?
Bei mir war der Zweck relativ einfach. Ich hoste Cloud, Media-Server, verschiedene Webserver etc für mich und ein paar Freunde bei mir daheim und habe daher nur eine öffentliche IP. Andere Leute wissen z.B. garnicht, was das mit den ":1234" hinter der Domain sein soll und lassen das dann z.B. daher weg und tippen nur die Domain ein und wundern sich, warum die Webseite nicht geht. Das einzige frustfreie ist da wenn alles auf den Standard-Ports läuft. Und das geht dann halt nur über den Reverse Proxy, jedenfalls wenn man alle Dienste trennen und in eine eigene VM mit einer IP packen möchte.@jangut Wohnzimmer Hoster mit einem DSL anschluss
@Dunuin
Mit "gemieteter" rProxy meine ich einen Server in der Cloud, so das ich meine Heimaddresse verstecken kann.
Mein Plan sieht so aus:
Mehrere Domains sollen durch einen rProxy in der Cloud an meinen lokalen Plesk Server geleitet werden...
Nur habe ich noch nicht richtig Plan wie ich dies machen sollte
Leider bin ich bei Vodafone...
Mit "gemieteter" rProxy meine ich einen Server in der Cloud, so das ich meine Heimaddresse verstecken kann.
Mein Plan sieht so aus:
Mehrere Domains sollen durch einen rProxy in der Cloud an meinen lokalen Plesk Server geleitet werden...
Nur habe ich noch nicht richtig Plan wie ich dies machen sollte
Leider bin ich bei Vodafone...
Vielleicht einen Reverse Proxy auf dem Cloud-Server laufen lassen, dann den Cloud Server per VPN mit einer VPN-Server-VM in deinem Heimnetz verbinden, und dann kann der entfernte Reverse Proxy Server ja einfach alles an deine entsprechenden lokalen IPs der VMs in deinem Heimnetz weiterleiten.