ESX / ESXi - Hilfethread

Hi

Da erstellst Du einfach 3 vSwitches, einer für WAN, einer für LAN sowie einer für die DMZ. Für WAN und LAN hängst Du am ESXi je eine NIC ein. Ich nehm mal an, VPN und WAN sind die selbe Leitung? Sonst bräuchtest Du 3 NIC's,... Das geht relativ problemlos.

Am meisten Mühe machte mir die Einrichtung der FW, aber das scheinst Du ja im Griff zu haben.

Edit: da war einer schneller,... So wie ich das verstanden habe, möchte er die DMZ nur virtuell haben. Da wär ja dann am Switch nur das LAN.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
OK, dann passt das. Ein physisches Gerät testweise in die DMZ hängen zu können wäre mir persönlich zwar immer lieber, aber wenns rein virtuell bleiben soll, geht das so.
 
@ AliManali: Genau, das Device "tun" der VPN-Verbindung kommt über den DSL-Router, d.h. die WAN-Verbindung.
Wenn ich nun je einen vSwitch "LAN", "WAN" und "DMZ" einrichte, dann bekommt die Firewall-VM "eth0", "eth1" und "eth2" sowie "tun". Richtig?
DMZ soll 192.168.0.0/24 haben,
LAN soll 192.168.2.0/24 haben,
tun hat eine einzelne x.x.x.238/32
und der Router hat 192.168.2.1
LAN soll mit DMZ reden können (muss die Firewall regeln)
Müsste dann so klappen. Klingt machbar. :)
 
Also wenn einer den Router übernimmt, ist er gleich im LAN? Wozu dann die DMZ?
 
TCM schrieb:
Also wenn einer den Router übernimmt, ist er gleich im LAN? Wozu dann die DMZ?
Zum Vergrößern anklicken....

Die Anfragen von außen kommen über die VPN-Verbindung rein und werden über die FW je nach Port entweder auf VM1 oder VM2 ... weitergeleitet und von da beantwortet. Die DMZ ist dafür gedacht, dass wenn einer eine der VM aus der DMZ übernimmt (was wahrscheinlicher ist, als das Router-Übernahme-Szenario), dann kommt er nicht ins LAN.
 
Machs doch gleich richtig:

Code: 
router --- firewall --- lan
               |
              dmz
 
Hi

Da siehst Du wohl was falsch: Einerseits hast Du LAN sowie den Router im selben Subnet. Der Router ist aber sozusagen Dein WAN. Das LAN würde ich nun nicht unbedingt ins selbe Subnet nehmen. Also fürs LAN z.B. 192.168.5.1/24 nehmen. Und Dein Tunnel soll in eine eigene Zone? Also ein zweites LAN, sozusagen? Dann brauchst Du eine Firewall, die mehrere "LAN"-Zonen kann. Normalerweise zeigt der VPN Tunnel ins LAN Segment und bezieht seine Adresse von dort.
 
ok, nächster Anlauf:

Firewall-VM:
  • eth0: 192.168.0.1 (DMZ vswitch)
  • eth1: 192.168.2.251 (WAN vswitch)
  • eth2: 192.168.5.251 (LAN vswitch)
  • tun1: x.x.x.238/32
V-Switches:
  • DMZ: 192.168.0.0/24, kein HW-nic
  • LAN: 192.168.5.0/24, HW-nic0, Mgt hängt hier dran
  • WAN: 192.168.2.0/24, HW-nic1, verbunden zu router
Router: 192.168.2.1

Verdrahtung:
phys: router---WANvswitch---firewall
phys: pswitch---LANvswitch
virt: firewall---DMZvswitch---DMZhosts
virt: firewall---LANvswitch---LANHosts

FW mach masquing für 192.168.0.0/21 in Richtung WAN für outbound traffic
 
Mir ist dabei immer noch nicht ganz klar, wo Dein Tunnel hin zeigt. Wenn der in eine eigene Zone soll, brauchst Du für den auch nen vSwitch.
 
Zuletzt bearbeitet:
Die Firewall-VM macht den Tunnel auf (über das WAN-Interface) und dort in der Firewall-VM sind auch die ganzen Regeln hinterlegt "welcher Port geht zu welcher VM".
 
Ich würd das einfach mal aufsetzen und ausprobieren. Ich glaube, grundlegend hast Du das jetzt verstanden.

Mir ist das mit dem Tunnel nicht ganz klar, aber bin auch nicht so der VPN Spezialist. Im Normalfall zeigt der Tunnel einfach ins LAN und der Client bezieht eine Adresse aus dessen Subnet. Nach dem Beispiel also 192.168.5.250 - 192.168.5.255.

Mir hat da die Lektüre vom c't Server recht weitergeholfen, für die Grundlagen.
 
Zuletzt bearbeitet:
AliManali schrieb:
Mir ist dabei immer noch nicht ganz klar, wo Dein Tunnel hin zeigt. Wenn der in eine eigene Zone soll, brauchst Du für den auch nen vSwitch.
Zum Vergrößern anklicken....

Achso, nen eigenen vswitch? okay, aber auf esxi-Ebene sehe ich das Device nicht, das tun1 ist ein optionales Device, was nur während der Zeit der Existenz des openvpn-Tunnels lebt. Es wird durch den openvpn-Client erstellt, ohne dass ich es außen definieren müsste. Oder liege ich da falsch?

- - - Updated - - -

AliManali schrieb:
Ich würd das einfach mal aufsetzen und ausprobieren. Ich glaube, grundlegend hast Du das jetzt verstanden.
Zum Vergrößern anklicken....

Genau, Versuch macht kluch :)
Merci für die Klärung!
 
Wenn du deinem Router statische Routen beibringen kannst, wäre es besser, wenn die Firewall nicht auch noch NAT macht.
 
Statische Routen kann der ned, aber danke für den Lacher (ich lache über die Telekom, nicht über Dich).
Hab das Ganze mal eben exemplarisch mit einigen Hosts aus jedem Subnetz umgesetzt und ZACK alle Martians sind nun weg! Und soweit ich alle Use cases durchgetestet habe, scheint das die Lösung zu sein. Sehr gut.
Nochmals Danke schön für Eure schnelle Hilfe!

screenshot-vsphere-netzwerk.png
 
Zuletzt bearbeitet:
kann dein Switch VLANs händeln?
Macht zumindest den Eindruck, da du für den MGMT Kernel Port eine VLAN ID mitgibst.

In dem Fall wäre es sogar möglich den vSwitch2 einzusparen und die DMZ und das LAN auf einem vSwitch zu händeln.
Nämlich indem du mit VLANs arbeitest. -> LAN VMs mit einer VID, DMZ mit einer anderen. Beides getagged über die NIC0 hinten raus zum physischen Switch.

Vorteil wäre, wie TCM schon anmerkte, das du auch mal ein physisches Device in die DMZ klinken könntest.
Es wäre auch möglich, ne zweite DMZ zu bauen. Eine tagged über die NIC auf den physischen Switch und eine rein virtuell. Ne virtuelle Firewall ist da ja idR fast endlos nach oben hin skalierbar. Auch wenn ich persönlich von virtuellen Firewalls nicht sooo viel halte.
 
fdsonne schrieb:
kann dein Switch VLANs händeln?
Zum Vergrößern anklicken....
ja

fdsonne schrieb:
In dem Fall wäre es sogar möglich den vSwitch2 einzusparen und die DMZ und das LAN auf einem vSwitch zu händeln.
Nämlich indem du mit VLANs arbeitest. -> LAN VMs mit einer VID, DMZ mit einer anderen. Beides getagged über die NIC0 hinten raus zum physischen Switch.

Vorteil wäre, wie TCM schon anmerkte, das du auch mal ein physisches Device in die DMZ klinken könntest.
Zum Vergrößern anklicken....
Hey, coole Idee - Danke für die Anregung! :cool: Ich arbeite allerdings erst mal so auf der Basis und schaue dann wie ich zu einem späteren Zeitpunkt zu so einem Szenario transformieren kann - ich habe nämlich IN DER TAT eine NAS-Box da rum stehen, die EINE kleine Funktionalität hat, die ich ab und an mal von außen nutze, jetzt wo Du's sagst :d
 
Eye-Q schrieb:
Der physikalische DC sollte sich die Zeit aus dem Internet holen, dann sollten sich alle anderen Server (ESXi sowie Windows) die Zeit vom physikalischen DC holen (Stichwort Autoritativer Zeitserver).
Zum Vergrößern anklicken....

Hi.
Also ich habe es so gemacht.
PDC Rolle dem physikalischen DC gegeben, dort dann "w32tm /config /manualpeerlist ..." eingetragen. Soweit passt alles. Alle Systeme haben nun dieselbe Zeit. Nur ein ESXi Hostserver will nicht so recht.
Es ist ein 5.5.0 Host. Habe dort unter "Konfiguration - Uhrzeitkonfiguration - NTP Client aktivieren" aktiviert. Unter den NTP-Einstellungen habe ich dann den physikalischen DC, also den NTP-Server (IP Adresse) eingetragen. Zusätzlich habe ich "Mit dem Host starten und beenden" aktiviert. Aber er holt sich irgendwie nicht die richtige Zeit. Es sind 2 Minuten Versatz.
Woran kann es nun liegen?!

VG
 
Zuletzt bearbeitet:
Kann ich auf meinem Server den CPU einfach ändern?
Wollte da einen besseren einsetzen weiß nicht wie esxi damit klar kommt benutze version 5.5

Die VM haben ja eine funktion hardware ändern oder nicht?
 
Normalerweise sollte das kein Problem sein, solange das Board die CPU unterstützt.

Den virtuellen Maschinen wird natürlich eine andere CPU vorgesetzt, das ist aber kein Problem. Das funktioniert ja auch per Live-Migration vom einen auf einen anderen Host mit einer anderen CPU, solange man entweder CPUs aus der selben Serie hat oder über das Cluster dementsprechende Kompatibilitätseinstellungen gesetzt hat.
Wenn Du eine CPU tauschst, sollte die neue CPU jedoch mindestens alle Instruktionen der alten CPU können, aber normalerweise baut man ja nur eine CPU mit mehr Instruktionen ein, um mehr Leistung zu erhalten. ;)

Die virtuelle Hardware brauchst Du nicht zu aktualisieren, die bleibt gleich, egal welche physikalische CPU eingesetzt ist.
 
schlechter wird es nicht und denke der kann sogar mehr xD

ich bau den einfach ein und starte ist ja eh nur ein homeserver vorrausgesetzt ich finde einen guten gebrauchten :)

danke für die Info
 
Erfahrung habe ich nicht, aber du willst sicher noch auf 100Mbit/s setzen?
 
Brauchst du wirklich 5 Ports oder reichen dir 4? Die Level One hat ja auch "nur" 100 Mbit?
 
Da dürfte man in den meisten Fällen mit ner einzelenen bis Dual 1000er wesentlich besser beraten sein.
Wenn dahinter noch ein Switch mit VLAN Support hängt lässt sich damit sogar noch wesentlich mehr machen.
 
Sogar eine single-port Gbit-NIC ist mit VLANs besser. 100Mbit sollte man nicht mehr verbauen, oder geht's um Passthrough-Geschichten?
 
Hallo,
ich brauch keine 5 Ports, aber alle anderen Multiportkarten waren deutlich teurer als 39€.

Ja Passtrough zu IPFire.

Gruss
 
LaMagra-X schrieb:
Hi.
Also ich habe es so gemacht.
PDC Rolle dem physikalischen DC gegeben, dort dann "w32tm /config /manualpeerlist ..." eingetragen. Soweit passt alles. Alle Systeme haben nun dieselbe Zeit. Nur ein ESXi Hostserver will nicht so recht.
Es ist ein 5.5.0 Host. Habe dort unter "Konfiguration - Uhrzeitkonfiguration - NTP Client aktivieren" aktiviert. Unter den NTP-Einstellungen habe ich dann den physikalischen DC, also den NTP-Server (IP Adresse) eingetragen. Zusätzlich habe ich "Mit dem Host starten und beenden" aktiviert. Aber er holt sich irgendwie nicht die richtige Zeit. Es sind 2 Minuten Versatz.
Woran kann es nun liegen?!

VG
Zum Vergrößern anklicken....

Hat dazu noch jemand eine Idee?!

Also bis auf die ESXi Hosts laufen nun alle Systeme hier zeitgleich. Nur die Hosts eben nicht.

VG
 
Aber wenn ich doch den internen Server angebe sollte er sich doch davon die Zeit holen, oder nicht!?

VG
 
Anmelden, um zu antworten.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh