Ich habe lokal ein vCenter Server und bei Hetzner einen Rootserver gemietet auf dem ich ESXI installiert habe. Dieser muss eine Public IP haben, da es ja dort im Datacenter kein „Lokales Netzwerk“ gibt. Das ist zwar nicht so optimal, aber immerhin kann man mit der hetzner Software Firewall den Traffic zu diesen IPs einschränken.
Innerhalb der VM Umgebung gibt es eine pfSense Router VM mit der ich ein IPsec VPN zum Heimnetzwerk mache.
Nun stellte ich fest, dass sich der ESX Server bei Hetzner alle paar Sekunde vom vCenter trennt. Ich musste dann vor jeder Aktion die Verbindung wiederherstellen, oder mich direkt mit dem ESX Host Client verbinden. Also ging ich diesem Problem nach um es zu lösen.
Hinweis: Die Beschreibung bezieht isch auf vSphere 8 (vCenter und ESX). Bei älteren- und zukünftigen Versionen könnte das Verfahren anders sein.
Inhalt
Die Ursache
Wenn man einen ESX Server zum vCenter hinzufügt, übermittelt das vCenter diesem seine eigene (Private) IP Adresse.
Diese IP sieht man mit dem folgenden Kommando auf dem ESX:
configstorecli config current get -c esx -g services -k vpxa_solution_user_config |grep -i server_ip
Der ESX Server sendet dann alle 30 Sekunden heartbeats zu dieser Adresse auf den UDP Port 902. Falls der vCenter Server nun diese hearbeats nicht empfängt, trennt er die Verbindung zum ESX Server.
Und das geht natürlich nicht, weil der ESX erstmal gar nicht auf diese IP kommt.
Man könnte nun die server_ip auf dem ESX auf die Public IP vom entfernten Router (da wo das vCenter ist) setzen und dann den ganzen Traffic von der ESX Public IP auf die interne IP des VCenters NAT-en und mit dem Attribut preserveServerIp verhindern, dass das vCenter diese wieder zurück ändert.
Aber NAT Konfigurationen werden von VMware generell nicht unterstützt und man würde sich da auf ziemlich abenteuerliche Pfade begeben…
Die Lösung
Wenn man nun auf dem ESXi eine Netzwerkverbindung zu den VMs, die auf diesem laufen machen könnte, dann könnte man den Traffic zur privaten IP einfach über den router und das IPsec VPN schicken.
Und dies geht und zwar mit einem VMkernel-Adapter.
Alles was man nun machen muss ist beim ESX unter Configure / Networking / Virtual switches
und Add Networking
einen neuen VMkernel Network Adapter zu erstellen.
Diesen hängt man dann an den existierenden Standard vSwitch und wählt als Service „Management“ aus. Falls man die Hetzner vSwitchs benutzt muss dort auch die VLAN ID des vSwitches eingetragen werden wo sich die Router VM befindet.
Danach gibt man dem ESX Server eine IP im internen Netz, so wie die Subnetzmaske und trägt als Default Gateway die Adresse des (VPN) routers ein.
Damit wird auf dem ESX eine Art „Virtuelles Netzwerk Interface“ erstellt und Traffic auf das interne Netz wird dann zu dem VM Netzwerk geleitet.
In meinem Fall war das noch nicht genug, weil der vCenter Server sich ja nicht in dem Netz, sondern in einem entfernten Netz befindet. Daher musste ich noch eine statische route in dieses (fremde) Netz konfigurieren:
esxcli network ip route ipv4 add --gateway xx.xx.xx.xx --network ##.##.##.##/##
Und siehe da: Der ESX Server wird nicht mehr vom vCenter getrennt! 😁
Ich kann das auch überprüfen in dem ich auf dem ESX Host tcpdump lasse um die ausgehnden heartbeat Pakete zu sehen:
tcpdump-uw dst host <vcenter_ip_address> and udp port 902
Und auf dem vCenter Server ebenfalls mit tcpdump sehen, dass die Pakete ankommen:
tcpdump src host <esxi_host_ip_address> and udp port 902
Firewall Regeln
Je nachdem muss man dann noch Firewall Regeln für den vSphere Traffic erstellen.
Für diese ist die VMware Seite VMware Ports and Protocols ganz praktisch!
Weitere Informationen
- ESXi host disconnects intermittently from vCenter Server
- ESXi host disconnects from vCenter Server after adding or connecting it to the inventory
- Using NAT between the vCenter Server system and ESXi hosts
- Create a VMkernel Adapter on a vSphere Standard Switch
- Configuring static routes for vmkernel ports on an ESXi host
- vCenter Server behind NAT
- Equivalent of serverIp and preserveServerIp in configstore cli
- VMware Ports and Protocols