Hyper-V Port-forwarding - Firewall Problem
Guten Morgen miteinander.
Ich habe folgendes Szenario:
Host Server mit Windows Server 2019
Dort drauf ist Hyper-V mit einer Ubuntu VM die eine PostgreSQL Datenbank bereitstellt (Port 5432)
Einen NAT-Switch hab ich bereits erstellt und "Port-forwarding" zum Host auch. Folgendes Tut genutzt: Hyper-V Port Forwarding
Funktioniert soweit so gut, jetzt kommt aber das Problem:
Es laufen auf dieser VM noch ein Webserver auf Port 9091 der aber nur bis zum Reverse-Proxy auf dem Hostsystem (IIS) gehen soll, jedoch lässt sich der so erreichen, und jegliche Einstellungen an der Windows Firewall wird ignoriert (da es über den vSwitch läuft, gehe ich von aus). ich kann also domain.de:9091 aufrufen, aber das will ich nicht.
Wichtig zu wissen wäre, dass ich dazu nur eine Public IP hab (die der Host benutzt), deshalb über NAT
Vielleicht hat jemand ne Lösung
- Fabi
Ich habe folgendes Szenario:
Host Server mit Windows Server 2019
Dort drauf ist Hyper-V mit einer Ubuntu VM die eine PostgreSQL Datenbank bereitstellt (Port 5432)
Einen NAT-Switch hab ich bereits erstellt und "Port-forwarding" zum Host auch. Folgendes Tut genutzt: Hyper-V Port Forwarding
Funktioniert soweit so gut, jetzt kommt aber das Problem:
Es laufen auf dieser VM noch ein Webserver auf Port 9091 der aber nur bis zum Reverse-Proxy auf dem Hostsystem (IIS) gehen soll, jedoch lässt sich der so erreichen, und jegliche Einstellungen an der Windows Firewall wird ignoriert (da es über den vSwitch läuft, gehe ich von aus). ich kann also domain.de:9091 aufrufen, aber das will ich nicht.
Wichtig zu wissen wäre, dass ich dazu nur eine Public IP hab (die der Host benutzt), deshalb über NAT
Vielleicht hat jemand ne Lösung
- Fabi
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 91809077041
Url: https://administrator.de/contentid/91809077041
Ausgedruckt am: 22.11.2024 um 04:11 Uhr
22 Kommentare
Neuester Kommentar
Moin,
klar kann man sich ein NAT Konstrukt irgendwie so ala VirtualBox zusammen schustern. Ich glaub du wirst hier kaum wen finden, der dir sowas empfehlen wird. Vor allem nicht wenn du an eine öffentliche IP einsetzt.
Die beste Lösung ist schlicht und ergreifend eine Firewall VM auf dem HyperV Host. Dort lassen sich granulare Regeln definieren. Des weiteren hast du auch ein vernünftiges monitoring wer was wann und wohin macht.
Also setzt für das Konstrukt eine OPNsense oder PfSense auf. Da ist dein NAT schon von Hause aus fertig konfiguriert.
Wenn du dein bestehendes Konstrukt mit dem "NAT-Switch" weiter verwenden willst, dann solltest du für die Server die Bindung der Services korrekt einschränken. Das ist halt keine Firewall.
Gruß
Spirit
klar kann man sich ein NAT Konstrukt irgendwie so ala VirtualBox zusammen schustern. Ich glaub du wirst hier kaum wen finden, der dir sowas empfehlen wird. Vor allem nicht wenn du an eine öffentliche IP einsetzt.
Die beste Lösung ist schlicht und ergreifend eine Firewall VM auf dem HyperV Host. Dort lassen sich granulare Regeln definieren. Des weiteren hast du auch ein vernünftiges monitoring wer was wann und wohin macht.
Also setzt für das Konstrukt eine OPNsense oder PfSense auf. Da ist dein NAT schon von Hause aus fertig konfiguriert.
Wenn du dein bestehendes Konstrukt mit dem "NAT-Switch" weiter verwenden willst, dann solltest du für die Server die Bindung der Services korrekt einschränken. Das ist halt keine Firewall.
Gruß
Spirit
Vielleicht hilft dir ein VmWare und Proxmox Beispiel wie man es damit löst wenn nur ein NIC Port vorhanden ist?!
Proxmox
VmWare ESXi
Proxmox
VmWare ESXi
Moin,
dieser Link wird dir auch helfen, wenn du mit verschiedenen VLANs arbeiten möchtest:
https://www.kaiherzig.eu/hyperv-switch-vlan-trunking/
dieser Link wird dir auch helfen, wenn du mit verschiedenen VLANs arbeiten möchtest:
https://www.kaiherzig.eu/hyperv-switch-vlan-trunking/
Ist eigentlich ganz einfach:
Du erstellst einen VSWITCH EXTERN und einen VSWITCH INTERN bzw. noch weitere falls gewünscht.
Du Verbindest deine VM´s mit dem vSwitrch INTERN und der FW am LAN Port ( Intern )
Die Firewall an den Switch EXTERN mit dem WAN port Verbinden.
Dann buchst du eine Konsolensitzung - Di Brauchst du damit du die Firewall und die Hyper V Settings
anpassen kannst.
Du meldest über die KVM am Server an und packst das Interface wo die Pub. IP gebunden ist zum Switch EXTERN
und machst den Harken "Gemeinsame Verwaltung bla bla bla raus"
Dann stellst du die MAC im Portal um.
Jetzt musst du über den Host die Firewall konfigurieren.
ACHTUNG - nicht selber aussperren. Also erstmal RDP auf der WAN IP erlauben.
Dann konfigurierst du deine weiteren FW Regeln
zum Schluss das ganze noch so einrichten das die FW den Traffic entsprechend deiner Vorgaben filteret / Weiterleitet.
Dann noch ein VPN für die Verwaltung einrichten sodass der Host per RDP nur ereichbar ist wenn das VPN steht.
So geht das ganze mit einer IP.
Wichtig ist das der WAN Port deines Servers direkt an die Firewall durchgereicht wird bzw. direkt mit dem VSWITCH WAN verbunden ist und der Server selber nicht mit der Verwaltung dran häöngt.
Du erstellst einen VSWITCH EXTERN und einen VSWITCH INTERN bzw. noch weitere falls gewünscht.
Du Verbindest deine VM´s mit dem vSwitrch INTERN und der FW am LAN Port ( Intern )
Die Firewall an den Switch EXTERN mit dem WAN port Verbinden.
Dann buchst du eine Konsolensitzung - Di Brauchst du damit du die Firewall und die Hyper V Settings
anpassen kannst.
Du meldest über die KVM am Server an und packst das Interface wo die Pub. IP gebunden ist zum Switch EXTERN
und machst den Harken "Gemeinsame Verwaltung bla bla bla raus"
Dann stellst du die MAC im Portal um.
Jetzt musst du über den Host die Firewall konfigurieren.
ACHTUNG - nicht selber aussperren. Also erstmal RDP auf der WAN IP erlauben.
Dann konfigurierst du deine weiteren FW Regeln
zum Schluss das ganze noch so einrichten das die FW den Traffic entsprechend deiner Vorgaben filteret / Weiterleitet.
Dann noch ein VPN für die Verwaltung einrichten sodass der Host per RDP nur ereichbar ist wenn das VPN steht.
So geht das ganze mit einer IP.
Wichtig ist das der WAN Port deines Servers direkt an die Firewall durchgereicht wird bzw. direkt mit dem VSWITCH WAN verbunden ist und der Server selber nicht mit der Verwaltung dran häöngt.
Wenn du eine Firewall-VM nutzen möchtest, dann benötigt diese eine öffentliche IP. Eine öffentliche IP kann nur einer MAC-Adresse zugewiesen werden, deshalb benötigst du eine extra IP, damit du diese der Firewall-VM zuordnen kannst.
https://docs.hetzner.com/de/robot/dedicated-server/virtualization/window ...
https://docs.hetzner.com/de/robot/dedicated-server/virtualization/window ...
Zitat von @BlueSkillz:
Wenn du eine Firewall-VM nutzen möchtest, dann benötigt diese eine öffentliche IP. Eine öffentliche IP kann nur einer MAC-Adresse zugewiesen werden, deshalb benötigst du eine extra IP, damit du diese der Firewall-VM zuordnen kannst.
https://docs.hetzner.com/de/robot/dedicated-server/virtualization/window ...
Wenn du eine Firewall-VM nutzen möchtest, dann benötigt diese eine öffentliche IP. Eine öffentliche IP kann nur einer MAC-Adresse zugewiesen werden, deshalb benötigst du eine extra IP, damit du diese der Firewall-VM zuordnen kannst.
https://docs.hetzner.com/de/robot/dedicated-server/virtualization/window ...
Es geht auch ohne zweite IP.
Die Öffentliche IP bekommt die Firewall direkt zugewiesen am WAN Port und die Firewall kümmert sich dann wie Reverse Proxy / S-DNAT usw... / Portforwarding um den Zugriff
Hetzner hat auch eine Anleitung dafür.
Zitat von @fabichan:
Habe vergessen zu erwähnen, dass auf dem Windows Server selbst auch Dienste laufen, also auf dem selben Server wo Hyper-V läuft, diese müssen auch erreichbar bleiben. Auf den VMs läuft Linux weil u.a. Dienste dort laufen, für die Windows ungeeignet ist. Glaube habe möglicherweise eine eigenartige Konstellation
Habe vergessen zu erwähnen, dass auf dem Windows Server selbst auch Dienste laufen, also auf dem selben Server wo Hyper-V läuft, diese müssen auch erreichbar bleiben. Auf den VMs läuft Linux weil u.a. Dienste dort laufen, für die Windows ungeeignet ist. Glaube habe möglicherweise eine eigenartige Konstellation
Eigenartig ist die Konstellation schon, weil auf HyperV nichts an eigenen Diensten jemals laufen sollte, das aus dem Web erreichbar ist, zumindest wenn du Daten hast, die nicht jeden Hacker etwas angehen. Dafür solltest du dir eine extra VM machen, wo die Dienste laufen. Deine Firewall kriegt die öffentliche IP zugewiesen, an der Firewall schleifst du dann per NAT deine Ports an die jeweilige VM mit dem gehosteten Dienst durch. Die VMs sollten bestenfalls auch keinen Zugriff auf den Host haben, sondern nur du über dein Admin Interface.
Das geht alles schon mit einer IP.
Dafür musst du allerdings in der Zeit wo du KVM Konsole von Hetzner hast die FW aufsetzen und dir einen Tunnel in das LAN dahinter bauen um an deinen Host zu kommen.
Ohne das schon mal gemacht zu haben ist das sportlich.
Was für eine Windows Lizenz hast du denn? Bei Standard kannst du ja ohne Probleme noch eine weitere Windows VM betreiben. Der HyperV Host darf nichts anderes am laufen haben.
Dafür musst du allerdings in der Zeit wo du KVM Konsole von Hetzner hast die FW aufsetzen und dir einen Tunnel in das LAN dahinter bauen um an deinen Host zu kommen.
Ohne das schon mal gemacht zu haben ist das sportlich.
Was für eine Windows Lizenz hast du denn? Bei Standard kannst du ja ohne Probleme noch eine weitere Windows VM betreiben. Der HyperV Host darf nichts anderes am laufen haben.
Zitat von @fabichan:
Eine Idee habe ich jedoch, folgendes Szenario:
Ich lass das mit den HyperV Nat static routes so, schalte aber eine Firewall dazwischen, und konfiguriere entsprechend Port Forwarding
Sollte doch klappen, und Ports die intern bleiben sollen, obwohl... die Ports müssen ja bis zum Host da dort ja der Reverse-Proxy sitzt....
Eine Idee habe ich jedoch, folgendes Szenario:
Ich lass das mit den HyperV Nat static routes so, schalte aber eine Firewall dazwischen, und konfiguriere entsprechend Port Forwarding
Sollte doch klappen, und Ports die intern bleiben sollen, obwohl... die Ports müssen ja bis zum Host da dort ja der Reverse-Proxy sitzt....
Das ist was wir dir versuchen zu erklären
Zitat von @fabichan:
Auf dem Host selbst läuft auch nur der IIS als Webserver / Reverse-Proxy
Das Ding ist, dass der Server so schon seit 2 Jahren läuft, ich habe nur eine Linux VM hinzugefügt um PostgreSQL laufen zu lassen, dies möchte ich wie oben gemeint so haben, dass es die selbe IP nutzen, deshalb meine aktuelle NAT Konstellation
Auf dem Host selbst läuft auch nur der IIS als Webserver / Reverse-Proxy
Das Ding ist, dass der Server so schon seit 2 Jahren läuft, ich habe nur eine Linux VM hinzugefügt um PostgreSQL laufen zu lassen, dies möchte ich wie oben gemeint so haben, dass es die selbe IP nutzen, deshalb meine aktuelle NAT Konstellation
Das es läuft, heißt noch lange nicht, das es gut ist. Man stellt halt keinen HyperV Host ungeschützt ins Netz.
Ein HyperV ist ein HyperV, sonst nix. So sagt es die Best Practice von Microsoft.