ESXi / Hetzner / Mehrere öffentliche IP´s und Subnetz



  • Hallo liebes Forum,

    ich bin neu hier. Habe über Google hierher gefunden und hoffe auf Hilfe.
    Ich habe seit 3 Jahren einen EX4-Root-Server von Hetzner. Ich habe das Ding ewig mit XenServer betrieben, der jedoch böse gehacked wurde. Deshalb habe ich die Möglichkeit gleich genutzt und bin auf VmWare umgestiegen (gottseidank).

    Natürlich möchte ich meine VMs besser schützen und das Netz hinter dem Host besser aufbauen.

    Ich bin in Sachen pfsense+Hetzner+router-vm und dieser Verbindung ziemlich ahnungslos.
    Selbstverständlich habe ich jetzt einige Tage damit herumprobiert und versucht selbst die notwendige Lösung zu erarbeiten - leider schaff ich es nicht.

    Folgende Ausgangssituation:

    • 1x EX4S Hetzner Server, mit 1 Netzwerkkarte
    • ESXi 5.5 ist installiert und läuft
    • router-vm mit pfsense 2.1.5, installed
    • in der alten Konfig hatte ich 5 eigene, öffentliche IP´s (pro Server eine)
    • es existiert ein zusätzliches (bisher ungenutztes) Subnetz

    Mein Wunsch:

    • es sollen mehrere VM´s betrieben werden
      – 1x WebServer der bestmöglich geschützt ist und von außen erreichbar sein soll, bestmöglich über eine eigene öffentliche IP
      -- 1x MYSQL Server, bestmöglich NICHT von außen erreichbar, soll aber mit dem Webserver kommunizieren können klarerweise
      -- 1x Testserver, darf/soll von außen per eigener öffentlicher IP erreichbar sein, sollte aber bestmöglich geschützt sein - diese Maschine braucht nur Internet, keine zwingende Verbindung zu den anderen Servern
      -- sonstige Server die allesamt nur Internet haben sollen und untereinander sichtbar/erreichbar sein sollen, aber nicht zu Web/SQL Zugang haben sollen

    Wobei zeitgemäß Web/SQL das wichtigste ist....den Rest könnt ich mir selbst noch in Ruhe ansehen.

    Bisher habe ich also folgende Konstellation gebaut:

    • Root mit ESXi aufgesetzt
    • router-vm mit pfsense 2.1.5 aufgesetzt und dieser 3 virtuelle Netzwerkkarten versehen (WAN, LAN, DMZ) und Interfaces zugewiesen
    • WAN hat als Interface eine der öffentlichen IP´s (176.x.x.x)
    • LAN hat den Range 192.168.1.2 - 10 und das Interface hat 192.168.1.1
    • DMZ hat den Range 172.16.1.2 - 10 und das Interface hat 172.16.1.1
    • Webserver mit 1 virtuellen Netzwerkkarte versehen (DMZ)
    • MYSQL-Server mit 1 virtuellen Netzwerkkarte versehen (LAN)

    Mein Problem ist nun die Konfiguration am ESX, router-vm und auf den VM-Hosts.
    Gehört auf dem ESX irgendetwas spezielles konfiguriert?

    Ich komme schon nicht mit einer XP-Testmaschine die im Lan hängt und 192.168.1.2 erhalten hat nicht ins Internet.

    Update 14:29:

    • Gateway richtig gestellt
    • Bitmaske bei der WAN-IP richtig gestellt
    • richtigen Gateway beim WAN-Interface gewählt

    jetzt funktioniert das Internet im LAN mal... yeah

    danke

    mike


  • LAYER 8 Moderator

    Preisfrage: Kommt die pfSense selbst überhaupt über dein jetziges Setup ins Internet?

    Bei Hetzner gibt es in Sachen ESXi Hosting mehrere Stolperstricke, weswegen ich

    Deshalb habe ich die Möglichkeit gleich genutzt und bin auf VmWare umgestiegen (gottseidank).

    eher mit "Ich bin gerade bei Hetzner von ESXi auf XEN umgestiegen (gottseidank)" kontern muss ;)

    Das aber beiseite gibt es allein beim Betrieb von ESXi (bei Hetzner) 3-4 wichtige Punkte, bei denen man überhaupt mal anfangen sollte:

    1. der VMKernel sollte nicht extern erreichbar sein. Ist er aber per default (der ESX Host hat ja das physikalische Interface und ist darüber auch "fernwartbar" - aber eben für das ganze Internet). Sobald also die Routing VM steht und das Netz funktioniert sollte der VMKernel auf der public IP abgeschaltet werden und auf einer internen IP aufgelegt werden. Die dann nur per VPN erreichbar machen (oder nur von fester IP) und gut. Ansonsten schreibst du in ein paar Wochen wahrscheinlich deinen Text nochmal - mit ESX statt XEN und "gehackt" (eher gecrackt als wirklich gehackt…)

    2. Hetzner hat ein blödes Netzwerksetup. Punkt. Einzelne IP Adressen werden immer physikalischen MACs zugewiesen, somit ist es verflixt schwierig, das ohne Router VM und zusätzliches /29 (oder größer) IP Netz zu nutzen, weil dämlich zu konfigurieren.

    3. Der ESXi funktioniert bei den Hetzner Kisten nicht mit allen Netzwerkkarten. Das zumindest scheint wohl auf dich nicht zuzutreffen, aber normalerweise war das Vorgehen bei Hetzner schon beim Bestellen die Ansage "Bau mir Intel NIC ein oder ich gehe wieder" :)

    4. Dann brauchst du zusätzlich zum ESX noch eine weitere IP (hast du offensichtlich schon). Der Kniff ist aber nun: nimm dein vorhandenes zusätzliches IP Netz und mach ein Ticket auf. Darin sagst du an, dass dieses IP Netz auf die zusätzliche IP <sowieso>geroutet werden soll. Pronto. Die IP <sowieso>bekommt dann die pfSense als externe IP. Gib zusätzlich im Ticket an, welche MAC Adresse deine pfSense Installation auf dem WAN hat, weil ansonsten der Hetzner IP/MAC Protect dir in die Eingeweide grätscht.

    Wenn 2) 3) und 4) gegeben sind, sollte deine pfSense selbst mit der IP mal raus ins Netz können. Da du dann die Adressen aus dem /29er Netz auf diese IP geroutet bekommst, kannst du diese beliebig weiter verwursten. Entweder du bindest die direkt auf eine zusätzliche DMZ und routest (dann verlierst du eine IP die du für das pfSense Interface brauchst) oder du gehst jetzt hin und nutzt die Adressen aus dem zusätzlichen Subnetz im 1:1 NAT um bspw. deinen Testserver oder deinen Webserver zu bespaßen.

    Wenn du das "supersicher" machen willst, kannst du zusätzlich das interne VM Netz in versch. VLANs splitten (10/20/30...) und Web- DB Und Testkiste in eigene VLANs packen. Damit hast du die als einzelne Netze in der pfSense und kannst entsprechend Regeln erstellen, wer mit wem sprechen darf. Etwas aufwändiger aber dann weißt du wer mit wem spricht.
    Wie die Netze heißen ist relativ egal, da das weder eine klassische DMZ noch ein klassisches LAN ist. Ich würde da sprechendere Bezeichnungen verwenden (Frontend für Web, Backend für DB und Testing o.ä.)

    Zusätzlich würde ich noch ein Mgmt Netz machen wo eine Mini Kiste reinkommt mit SSH only o.ä. die man mittels (Open)VPN anspringen kann um die anderen Kisten mal zu managen, dann muss auch keine einzelne ins Internet mehr öffnen als bspw. Web Ports und selbst wenn jemand dein VPN anzapft, kannst du durch SSH PubKey Auth auf dem Mgmt Jumphost noch etwas verhindern. Außerdem kann man dort prima Configs zwischenlagern und dann ggf. auf die Kisten zentral verteilen.

    Und BTW: Nimm um Gottes Willen den Dreck von XP aus dem Netz. Raus damit. Egal wofür. Das Ding hat ausgedient und ist eine wandelnde Bazillenschleuder. Nicht mal in nem isolierten Netz würde ich den Mist laufen lassen. Wenns schon Windows sein muss dann 7 oder 8 aber XP hat keine Daseinsberechtigung mehr im Internet.

    Grüße
    Jens</sowieso></sowieso>



  • Vorweg…. danke danke danke danke für deine Hilfe!!!
    Es ist mir eine wahnsinnige Hilfe... schön langsam macht sich Verzweiflung breit.

    Nun zu deinen Beitrag.

    @JeGr:

    Preisfrage: Kommt die pfSense selbst überhaupt über dein jetziges Setup ins Internet?

    Ja…ich erreiche aus der Shell der Router-VM alles. Funktioniert soweit inzwischen alles wunderprächtig. Nur die Server dahinter sind zurzeit nicht erreichbar.

    Bei Hetzner gibt es in Sachen ESXi Hosting mehrere Stolperstricke, weswegen ich

    Deshalb habe ich die Möglichkeit gleich genutzt und bin auf VmWare umgestiegen (gottseidank).
    eher mit "Ich bin gerade bei Hetzner von ESXi auf XEN umgestiegen (gottseidank)" kontern muss ;)

    Nun…ich arbeite beruflich mehr mit VMWare und privat eben mit Hetzner+Xen bisher. Ich bin die letzten 2 Wochen eben auf VMware umgestiegen und habe alleine bei der Installation schon etliche Vorteile entdeckt. Aber gut, vielleicht auch Geschmack.

    1. der VMKernel sollte nicht extern erreichbar sein. Ist er aber per default (der ESX Host hat ja das physikalische Interface und ist darüber auch "fernwartbar" - aber eben für das ganze Internet). Sobald also die Routing VM steht und das Netz funktioniert sollte der VMKernel auf der public IP abgeschaltet werden und auf einer internen IP aufgelegt werden. Die dann nur per VPN erreichbar machen (oder nur von fester IP) und gut. Ansonsten schreibst du in ein paar Wochen wahrscheinlich deinen Text nochmal - mit ESX statt XEN und "gehackt" (eher gecrackt als wirklich gehackt…)

    Danke für diesen Gold-Tipp!!! Grundsätzlich könnte ich das ja sofort abdrehen. Nur komm ich dann noch mit dem vsphere Client auf die Maschine um die VM´s zu warten?
    Oder meintest du eben genau das…?

    1. Hetzner hat ein blödes Netzwerksetup. Punkt. Einzelne IP Adressen werden immer physikalischen MACs zugewiesen, somit ist es verflixt schwierig, das ohne Router VM und zusätzliches /29 (oder größer) IP Netz zu nutzen, weil dämlich zu konfigurieren.

    Nun ja…. ich habe natürlich in meiner Hilflosigkeit halb Google leer gelesen und es gibt da schon einige Ansätze und einige Leute die das gut gelöst haben.

    In meinem Fall ist es so dass ich 5x öffentliche IP besitze und 1 Subnetz.
    1. öffentliche IP = ESX Host
    1. öffentliche IP = router-VM
    Bis hierher funktioniert auch alles..... ich komme von außen zum ESX, die router-vm arbeitet wie sie soll. In einem LAN dahinter komm ich mit der router-vm-ip ins Internet.
    Was ich bisher noch nicht zusammengebracht habe ist diese VirtualIP/IP Alias für die 3te öffentliche IP.

    Was du mit "es werden immer pyskalische MACS zugewiesen" meinst, versteh ich nicht. Ich kann mir das frei aussuchen. Ich kann alles mit 1 MAC betreiben (wie bisher unter XEN) oder für jede IP eine eigene MAC erzeugen. Da hab ich freie Wahl.

    1. Der ESXi funktioniert bei den Hetzner Kisten nicht mit allen Netzwerkkarten. Das zumindest scheint wohl auf dich nicht zuzutreffen, aber normalerweise war das Vorgehen bei Hetzner schon beim Bestellen die Ansage "Bau mir Intel NIC ein oder ich gehe wieder" :)

    Oja….das war zu Beginn eines meiner ersten Probleme. Ich musste aber lediglich in das ESX-ISO-Image die NIC Treiber einbinden, dann ging das sofort und klaglos.

    1. Dann brauchst du zusätzlich zum ESX noch eine weitere IP (hast du offensichtlich schon). Der Kniff ist aber nun: nimm dein vorhandenes zusätzliches IP Netz und mach ein Ticket auf. Darin sagst du an, dass dieses IP Netz auf die zusätzliche IP <sowieso>geroutet werden soll. Pronto. Die IP <sowieso>bekommt dann die pfSense als externe IP. Gib zusätzlich im Ticket an, welche MAC Adresse deine pfSense Installation auf dem WAN hat, weil ansonsten der Hetzner IP/MAC Protect dir in die Eingeweide grätscht.</sowieso></sowieso>

    Den Absatz versteh ich leider gar nicht…. Subnetz hätte ich ja schon.... und die router-vm hat bereits eine öffentliche IP (funktioniert auch bereits).

    Wenn 2) 3) und 4) gegeben sind, sollte deine pfSense selbst mit der IP mal raus ins Netz können. Da du dann die Adressen aus dem /29er Netz auf diese IP geroutet bekommst, kannst du diese beliebig weiter verwursten. Entweder du bindest die direkt auf eine zusätzliche DMZ und routest (dann verlierst du eine IP die du für das pfSense Interface brauchst) oder du gehst jetzt hin und nutzt die Adressen aus dem zusätzlichen Subnetz im 1:1 NAT um bspw. deinen Testserver oder deinen Webserver zu bespaßen.

    Ja, pfsense kommt bereits ins Internet wie eingangs erwähnt. Das mit dem Subnetz wollt ich mir ersparen weil mir an sich diese EINE öffentliche IP reichen würde für meine Anforderungen.

    Wenn du das "supersicher" machen willst, kannst du zusätzlich das interne VM Netz in versch. VLANs splitten (10/20/30…) und Web- DB Und Testkiste in eigene VLANs packen. Damit hast du die als einzelne Netze in der pfSense und kannst entsprechend Regeln erstellen, wer mit wem sprechen darf. Etwas aufwändiger aber dann weißt du wer mit wem spricht.
    Wie die Netze heißen ist relativ egal, da das weder eine klassische DMZ noch ein klassisches LAN ist. Ich würde da sprechendere Bezeichnungen verwenden (Frontend für Web, Backend für DB und Testing o.ä.)

    Zusätzlich würde ich noch ein Mgmt Netz machen wo eine Mini Kiste reinkommt mit SSH only o.ä. die man mittels (Open)VPN anspringen kann um die anderen Kisten mal zu managen, dann muss auch keine einzelne ins Internet mehr öffnen als bspw. Web Ports und selbst wenn jemand dein VPN anzapft, kannst du durch SSH PubKey Auth auf dem Mgmt Jumphost noch etwas verhindern. Außerdem kann man dort prima Configs zwischenlagern und dann ggf. auf die Kisten zentral verteilen.

    Und BTW: Nimm um Gottes Willen den Dreck von XP aus dem Netz. Raus damit. Egal wofür. Das Ding hat ausgedient und ist eine wandelnde Bazillenschleuder. Nicht mal in nem isolierten Netz würde ich den Mist laufen lassen. Wenns schon Windows sein muss dann 7 oder 8 aber XP hat keine Daseinsberechtigung mehr im Internet.

    Du hast Recht…..werd ich einstampfen.


  • LAYER 8 Moderator

    Nun…ich arbeite beruflich mehr mit VMWare und privat eben mit Hetzner+Xen bisher. Ich bin die letzten 2 Wochen eben auf VMware umgestiegen und habe alleine bei der Installation schon etliche Vorteile entdeckt. Aber gut, vielleicht auch Geschmack

    Mache ich / muss ich auch. Manche Tage muss, manche darf. Es gibt sehr viele gute Dinge, die vmWare richtig macht, andere sind einfach nur gruselig. Insgesamt hält es sich die Waage aber der Kostenfaktor würde mich da eher in eine andere Richtung treiben wenn ich keine Firma wäre.

    Danke für diesen Gold-Tipp!!! Grundsätzlich könnte ich das ja sofort abdrehen. Nur komm ich dann noch mit dem vsphere Client auf die Maschine um die VM´s zu warten?
    Oder meintest du eben genau das…?

    Jein. Ja du kommst noch drauf, wenn du den VMKernel nach drinnen verlegst, aber nur wenn dus durch die pfSense durch lässt oder eben ein OpenVPN einrichtest und im eingeloggten Zustand das Transfernetz für den VMKernel freigibst.

    In meinem Fall ist es so dass ich 5x öffentliche IP besitze und 1 Subnetz.
    1. öffentliche IP = ESX Host
    1. öffentliche IP = router-VM
    Bis hierher funktioniert auch alles….. ich komme von außen zum ESX, die router-vm arbeitet wie sie soll. In einem LAN dahinter komm ich mit der router-vm-ip ins Internet.
    Was ich bisher noch nicht zusammengebracht habe ist diese VirtualIP/IP Alias für die 3te öffentliche IP.

    Was du mit "es werden immer pyskalische MACS zugewiesen" meinst, versteh ich nicht. Ich kann mir das frei aussuchen. Ich kann alles mit 1 MAC betreiben (wie bisher unter XEN) oder für jede IP eine eigene MAC erzeugen. Da hab ich freie Wahl.

    Die 5 öffentlichen IPs helfen dir leider nicht weiter, da Hetzner diese wie gesagt auf die MAC Adresse festgipst. Deshalb genügen für das ESXi Setup 2. Eine für den Host, die du später ausknipst (mit der Lara Console bspw.) und über einen zweiten VMKernel intern den ESXi wieder erreichbar machst, aber nur für dich. Die zweite bekommt die pfSense (richtig).

    Genau weil die MAC Blockade dir da reingrätscht, brauchst du ein Subnetz (/29 oder mehr) und keine einzelnen IP Adressen. Die anderen 3 IPs kannst du kündigen. Dafür sagst du denen, sie sollen das Subnetz auf deine pfSense IP routen und dann liegts an dir. Ich würde dann 1:1 NAT auf interne Adressen machen, damit bleiben dir alle Adressen des Subnetzes plus mit etwas Tricks kannst du sogar die Boundary Adressen nutzen (Subnetz & Broadcast IP), allerdings nur für abgehende Services oder solche, die auf der pfSense laufen. (bspw. ausgehende NAT von VMs, die du nicht via 1:1 Nat erreichbar machen möchtest wie die DB).

    Den Absatz versteh ich leider gar nicht…. Subnetz hätte ich ja schon.... und die router-vm hat bereits eine öffentliche IP (funktioniert auch bereits).

    Siehe oben. Ist bereits fast so wie ich es beschrieben habe, du musst nur das Subnetz auf die Router-VM IP routen lassen, dann hast dus. Die anderen 3 einzelnen IPs wirst du ohne fette Kopfschmerzen nicht zum Laufen bekommen, wegen MAC/IP Block auf den Switches.

    Bzgl des "supersicheren" Setups das ich beschrieb: Ich hatte das so bei Hetzner bereits laufen. Nach Setup der RouterVM externe IP #1 mit Hypervisor abgeklemmt (via Lara Console damit notfalls wieder startbar) und dann ein zweites VMkernel Interface auf dem internen vSwitch hinter der pfSense angelegt und diese in ein eigenes VLAN gepackt (911). Dort auch eine JumpVM mit MiniLinux reingepackt. Dann ein VLAN (111, 311, 511) pro VM angelegt. IP Netze passend reingepackt (10.1.11.x; 10.3.11.x; 10.5.11.x; 10.9.11.x - you get the clou) und die VLANs dann in der pfSense angelegt -> damit eigene Subinterfaces mit eigenen Regeln. FE (Frontend); BE (Backend); DEV (Testing); MGMT (Konfig).
    Dann 1:1 NAT von IPs aus /29er Subnetz auf interne VMs im 111er FE Netz erstellt. Regeln konfiguriert (Web Ports, SMTP bspw.), und anschließend Regeln von Verbindung von 111 auf 311 (FE->BE) wie bspw. MySQL o.ä.. Sobald das steht, sollte alles laufen. Zusätzlich kann man dann Testing auch von außen via 1:1 NAT aufmachen, aber wenn einer die Büchse stiehlt, kommt er trotzdem nicht auf FE oder BE. Somit eigentlich ein recht solides Konstrukt (bis auf den Fall dass der ESX stirbt, das ist dann eben ein HA Problem).

    Grüße



  • Jein. Ja du kommst noch drauf, wenn du den VMKernel nach drinnen verlegst, aber nur wenn dus durch die pfSense durch lässt oder eben ein OpenVPN einrichtest und im eingeloggten Zustand das Transfernetz für den VMKernel freigibst.

    OpenVPN habe ich in der Zwischenzeit konfiguriert, getestet und arbeite damit….funktioniert.
    Kann also den VMKernel auf mein "VPN-Netz?" freigeben..... in meinem Fall bekomm ich am VPN-Client eine IP aus dem Range 192.168.10.x

    Seh ich die Vorgangsweise so richtig:

    • Login auf der lokalen ESXShell
    • esxcfg-route -a 192.168.10.0/24
    • Default-Route löschen: esxcfg-route -d default y.y.y.y

    Was mich gedanklich ein wenig irritiert ist der Kernel dich auch für die Interfaces zu den VM-Hosts da ist oder? Wenn ich da die routen ändere können die Vm-hosts doch nicht mehr ins Internet oder?

    Genau weil die MAC Blockade dir da reingrätscht, brauchst du ein Subnetz (/29 oder mehr) und keine einzelnen IP Adressen. Die anderen 3 IPs kannst du kündigen. Dafür sagst du denen, sie sollen das Subnetz auf deine pfSense IP routen und dann liegts an dir. Ich würde dann 1:1 NAT auf interne Adressen machen, damit bleiben dir alle Adressen des Subnetzes plus mit etwas Tricks kannst du sogar die Boundary Adressen nutzen (Subnetz & Broadcast IP), allerdings nur für abgehende Services oder solche, die auf der pfSense laufen. (bspw. ausgehende NAT von VMs, die du nicht via 1:1 Nat erreichbar machen möchtest wie die DB).

    Siehe oben. Ist bereits fast so wie ich es beschrieben habe, du musst nur das Subnetz auf die Router-VM IP routen lassen, dann hast dus. Die anderen 3 einzelnen IPs wirst du ohne fette Kopfschmerzen nicht zum Laufen bekommen, wegen MAC/IP Block auf den Switches.

    Achso….dH einfach ein Ticket an Hetzner dass die mein Subnetz auf die öffentliche IP der Router-VM routen sollen??
    Echt? So einfach? cool.... dann muss ich also nurmehr das Subnet einbinden und für alle Rechner in meiner sobenannten "DMZ" kriegen dann Subnetz-IP´s.

    Bzgl des "supersicheren" Setups das ich beschrieb: Ich hatte das so bei Hetzner bereits laufen. Nach Setup der RouterVM externe IP #1 mit Hypervisor abgeklemmt (via Lara Console damit notfalls wieder startbar) und dann ein zweites VMkernel Interface auf dem internen vSwitch hinter der pfSense angelegt und diese in ein eigenes VLAN gepackt (911). Dort auch eine JumpVM mit MiniLinux reingepackt. Dann ein VLAN (111, 311, 511) pro VM angelegt. IP Netze passend reingepackt (10.1.11.x; 10.3.11.x; 10.5.11.x; 10.9.11.x - you get the clou) und die VLANs dann in der pfSense angelegt -> damit eigene Subinterfaces mit eigenen Regeln. FE (Frontend); BE (Backend); DEV (Testing); MGMT (Konfig).
    Dann 1:1 NAT von IPs aus /29er Subnetz auf interne VMs im 111er FE Netz erstellt. Regeln konfiguriert (Web Ports, SMTP bspw.), und anschließend Regeln von Verbindung von 111 auf 311 (FE->BE) wie bspw. MySQL o.ä.. Sobald das steht, sollte alles laufen. Zusätzlich kann man dann Testing auch von außen via 1:1 NAT aufmachen, aber wenn einer die Büchse stiehlt, kommt er trotzdem nicht auf FE oder BE. Somit eigentlich ein recht solides Konstrukt (bis auf den Fall dass der ESX stirbt, das ist dann eben ein HA Problem).

    Sau cool! Klingt gut!
    Ich werds mal mit dem Subnetz und dem NAT probieren. Denn diese 2te öffentliche IP arbeitet gar nicht…..obwohl alles richtig konfiguriert scheint. Vermutlich ist das genau dass Problem das du beschrieben hast.

    Ich möchte dir bis hier her schon mal danken.....so Menschen wie du braucht man öfters mal bei dringender Hilfe!
    Danke dir sehr herzlichst!

    lg


  • LAYER 8 Moderator

    Seh ich die Vorgangsweise so richtig:

    Nö :) Erstelle einen neuen VMKernel und hänge den einfach an einem internen VSwitch von einem VLAN an. Danach die entsprechenden Firewallregeln um vom VPN Transfernetz zu diesem VLAN zu können und gut. Auf der ESXi console habe ich lediglich das Management Network abgeschaltet, danach gibt der ESX auf die IP auch keine Antwort mehr, kann aber über die Console wieder reaktiviert werden ohne große Rumkonfiguriererei. Der VMKernel hat an der Stelle nichts mit der Erreichbarkeit der Systeme zu tun.

    Achso….dH einfach ein Ticket an Hetzner dass die mein Subnetz auf die öffentliche IP der Router-VM routen sollen??

    Jup. Siehe http://wiki.hetzner.de/index.php/VMware_ESXi

    Zitat: "Für die Nutzung eines Subnetzes (sowohl für IPv4 als auch IPv6) unter ESXi benötigt man mindestens eine zusätzliche IP für eine Router-VM, da ESXi selbst nicht routen kann. Bei der Bestellung des Subnetz sollte angeben werden, daß ESXi verwendet wird und darum bitten dieses auf die zusätzlichen IP-Adresse zu routen."

    Das "angeben bei Bestellung" kannst du mit einem Support Ticket damit nachholen.

    Ich werds mal mit dem Subnetz und dem NAT probieren. Denn diese 2te öffentliche IP arbeitet gar nicht…..obwohl alles richtig konfiguriert scheint. Vermutlich ist das genau dass Problem das du beschrieben hast.

    Das ist das Problem wie unter obigem Link beschrieben:

    "Standardmäßig sind die IP Adressen an die MAC Adresse des Hosts gebunden. Man kann sich jedoch für die einzelnen zusätzlichen IP-Adressen mittels Robot MAC-Adressen zuweisen lassen. Diese muß man für die virtuellen Server dann fest konfigurieren und verwenden. Die Anfrage erfolgt über "Robot -> Server -> Tab IP". Rechts neben der Zusatz-IP ist ein entsprechender Button."

    Ich möchte dir bis hier her schon mal danken…..so Menschen wie du braucht man öfters mal bei dringender Hilfe!

    Normalerweise verlange ich dafür auch nen Consulting Stundensatz als Freiberufler ;D

    Aber nachdem mich schon der ein oder andere hier im Forum dafür dankend angeschrieben hat, bin ich am Überlegen, ob ich meinen Amazon-Reflink in meine Signatur poste, dann darf mir gerne jemand einen Gefallen tun und vor sein Shopping (so er Amazon nutzt) auf den Link klicken, dann bekomme ich dafür wenigstens ein paar Cent als Einkaufsgutschein :)

    Viele Grüße und schöne Feiertage
    Jens



  • @JeGr:

    Nö :) Erstelle einen neuen VMKernel und hänge den einfach an einem internen VSwitch von einem VLAN an. Danach die entsprechenden Firewallregeln um vom VPN Transfernetz zu diesem VLAN zu können und gut. Auf der ESXi console habe ich lediglich das Management Network abgeschaltet, danach gibt der ESX auf die IP auch keine Antwort mehr, kann aber über die Console wieder reaktiviert werden ohne große Rumkonfiguriererei. Der VMKernel hat an der Stelle nichts mit der Erreichbarkeit der Systeme zu tun.

    Da steig ich leider aus :(

    Achso….dH einfach ein Ticket an Hetzner dass die mein Subnetz auf die öffentliche IP der Router-VM routen sollen??
    Jup. Siehe http://wiki.hetzner.de/index.php/VMware_ESXi
    Zitat: "Für die Nutzung eines Subnetzes (sowohl für IPv4 als auch IPv6) unter ESXi benötigt man mindestens eine zusätzliche IP für eine Router-VM, da ESXi selbst nicht routen kann. Bei der Bestellung des Subnetz sollte angeben werden, daß ESXi verwendet wird und darum bitten dieses auf die zusätzlichen IP-Adresse zu routen."
    Das "angeben bei Bestellung" kannst du mit einem Support Ticket damit nachholen.

    Subnetz wurde geroutet.

    Ich möchte dir bis hier her schon mal danken…..so Menschen wie du braucht man öfters mal bei dringender Hilfe!
    Normalerweise verlange ich dafür auch nen Consulting Stundensatz als Freiberufler ;D

    Aber nachdem mich schon der ein oder andere hier im Forum dafür dankend angeschrieben hat, bin ich am Überlegen, ob ich meinen Amazon-Reflink in meine Signatur poste, dann darf mir gerne jemand einen Gefallen tun und vor sein Shopping (so er Amazon nutzt) auf den Link klicken, dann bekomme ich dafür wenigstens ein paar Cent als Einkaufsgutschein :)
    Viele Grüße und schöne Feiertage
    Jens

    Gerne!! Kaufe öfters bei Amazon…wenn ich dir damit was gutes tun kann! Einfach her damit.

    Dir auch schöne Feiertage und einen guten Rutsch.

    lg


  • LAYER 8 Moderator

    Da steig ich leider aus :(

    Einfach im Vcenter Client einen neuen VMKernel für Mgmt erstellen (wird dann vmk1). Diesen auf eine interne IP setzen und diese via VPN erreichbar machen.

    Subnetz wurde geroutet.

    Und klappt es?

    Gerne!! Kaufe öfters bei Amazon…wenn ich dir damit was gutes tun kann! Einfach her damit.

    Bspw.: http://amzn.to/1A0dnl8
    Ich habe den Link auch als meine "Webseite" im Profil eingebaut (die kleine Weltkugel unter meinem Profil links), wer also mal jemand zu Weihnachten o.ä. mir etwas gutes tun möchte um sich zu bedanken, kann gerne über den Link zu Amazon gehen und was einkaufen, es muss auch nichts aus der ComputerEcke sein. Und nein, damit wird man nicht reich ;) Man bekommt zwischen 2-6% vom Netto-EK (nicht dem VK den der Benutzer zahlt), insofern ist es nicht die Welt und für euch ists kein Nachteil (ihr bezahlt ja nicht mehr dadurch). Insofern gönnt ihr einfach nur jemand anderem ein paar Euro mit eurem Einkauf.

    Grüße



  • @JeGr:

    Da steig ich leider aus :(
    Einfach im Vcenter Client einen neuen VMKernel für Mgmt erstellen (wird dann vmk1). Diesen auf eine interne IP setzen und diese via VPN erreichbar machen.

    Ja das hätt ich sogar probiert…Ergebnis war das ich mich selbst ausgesperrt habe für 2h weil der Default-gw verändert wurde auf eine 192er IP ^^
    Hab das dann alles per Shell wieder gelöscht und es bleiben lassen.

    Ich schaff auch den Zugang zu den Servern nicht wenn ich im VPN drin bin. Braucht der Webserver im Subnetz eine 2te NIC ins LAN ??

    Subnetz wurde geroutet.
    Und klappt es?

    Ja!!! VM aus dem Subnet ist im Internet erreichbar. Ports habe ich im pfsense freigegeben :) yeah !!

    Gerne!! Kaufe öfters bei Amazon…wenn ich dir damit was gutes tun kann! Einfach her damit.

    Bspw.: http://amzn.to/1A0dnl8
    Ich habe den Link auch als meine "Webseite" im Profil eingebaut (die kleine Weltkugel unter meinem Profil links), wer also mal jemand zu Weihnachten o.ä. mir etwas gutes tun möchte um sich zu bedanken, kann gerne über den Link zu Amazon gehen und was einkaufen, es muss auch nichts aus der ComputerEcke sein. Und nein, damit wird man nicht reich ;) Man bekommt zwischen 2-6% vom Netto-EK (nicht dem VK den der Benutzer zahlt), insofern ist es nicht die Welt und für euch ists kein Nachteil (ihr bezahlt ja nicht mehr dadurch). Insofern gönnt ihr einfach nur jemand anderem ein paar Euro mit eurem Einkauf.

    Hab vor 2 Wochen ein Bügeleisen um 200€ gekauft….schade. Aber eine SSD und paar Bastelteile sind noch offen :)
    Das geht dann über dich!


  • LAYER 8 Moderator

    Ich schaff auch den Zugang zu den Servern nicht wenn ich im VPN drin bin. Braucht der Webserver im Subnetz eine 2te NIC ins LAN ??

    Wenn das Routing stimmt, eigentlich nicht.

    Ja!!! VM aus dem Subnet ist im Internet erreichbar. Ports habe ich im pfsense freigegeben :) yeah !!

    Prima, Glückwunsch :D

    Aber eine SSD und paar Bastelteile sind noch offen :)
    Das geht dann über dich!

    Dankefein! :) Für SSDs in "normalen" Desktop-Rechnern (OS etc.) oder bei viel Platz/Gigabyte (pfSense mit SSD + Squid/IDS/etc.) empfehle ich gerne die Crucials: http://amzn.to/173wFwk
    Die MX100er sind was Preis/Leistung angeht topp, wenn es auf noch mehr Performance (IOPS) ankommt, kann man auch gern zur Schwesterserie M550 nehmen: http://amzn.to/1EFmi0V
    Oder wenn man Crucial aus irgendwelchen Gründen gar nicht mag, darfs auch gern Samsung sein (850 Evo oder Pro): http://amzn.to/1JZXoZV
    Allerdings ist Samsung (meiner Sicht nach) unnötig teurer da man die Leistung selten auf dem Maximum ausreizt um den Unterschied wirklich zu spüren.

    Und für den Fall dass jemand einfach nur bei Amazon einkaufen und mir dabei was Gutes tun möchte, ein Kurzlink mit meinem Ref-Tag: http://j.mp/amzn-DE



  • @JeGr:

    Ich schaff auch den Zugang zu den Servern nicht wenn ich im VPN drin bin. Braucht der Webserver im Subnetz eine 2te NIC ins LAN ??

    Wenn das Routing stimmt, eigentlich nicht.

    Ja!!! VM aus dem Subnet ist im Internet erreichbar. Ports habe ich im pfsense freigegeben :) yeah !!

    Prima, Glückwunsch :D

    Aber eine SSD und paar Bastelteile sind noch offen :)
    Das geht dann über dich!

    Dankefein! :) Für SSDs in "normalen" Desktop-Rechnern (OS etc.) oder bei viel Platz/Gigabyte (pfSense mit SSD + Squid/IDS/etc.) empfehle ich gerne die Crucials: http://amzn.to/173wFwk
    Die MX100er sind was Preis/Leistung angeht topp, wenn es auf noch mehr Performance (IOPS) ankommt, kann man auch gern zur Schwesterserie M550 nehmen: http://amzn.to/1EFmi0V
    Oder wenn man Crucial aus irgendwelchen Gründen gar nicht mag, darfs auch gern Samsung sein (850 Evo oder Pro): http://amzn.to/1JZXoZV
    Allerdings ist Samsung (meiner Sicht nach) unnötig teurer da man die Leistung selten auf dem Maximum ausreizt um den Unterschied wirklich zu spüren.

    Und für den Fall dass jemand einfach nur bei Amazon einkaufen und mir dabei was Gutes tun möchte, ein Kurzlink mit meinem Ref-Tag: http://j.mp/amzn-DE

    Ok jetzt funktioniert alles…bis auf diese VMKernel-Sache...das krieg ich nicht hin, egal wie ich es drehe.
    Die 192er IP die ich dem neuen VMKernel gebe ist nicht erreichbar aus dem VPN.


  • LAYER 8 Moderator

    Die 192er IP die ich dem neuen VMKernel gebe ist nicht erreichbar aus dem VPN.
    Passen denn Routing, VLAN, Firewall Einstellungen/Regeln etc. alle?

    Ansonsten mal (ggf. auszensiert) ein paar Bilder posten von den vSwitchen und Einstellungen des VMKernels sowie den Netzen. Bei VMware kann man schnell mal an einer Stelle ein VLAN, MTU oder sonstwas vergessen und dann sucht man sich zu Tode.



  • @JeGr:

    Die 192er IP die ich dem neuen VMKernel gebe ist nicht erreichbar aus dem VPN.
    Passen denn Routing, VLAN, Firewall Einstellungen/Regeln etc. alle?

    Ansonsten mal (ggf. auszensiert) ein paar Bilder posten von den vSwitchen und Einstellungen des VMKernels sowie den Netzen. Bei VMware kann man schnell mal an einer Stelle ein VLAN, MTU oder sonstwas vergessen und dann sucht man sich zu Tode.

    Ja, aus dem VPN komm ich überall hin (zu jeder Maschine im 192er, nur zum VMKernel nicht).

    IP-Range bei mir zuhause: 192.168.0.x/24
    IP-Range vom DHCP für VPN: 192.168.2.x/24

    siehe Screenshot_ipconfig.png

    Ping kommt von 192.168.1.100 keiner zurück und auf die VM über die IP komm ich auch nicht.
    Änder ich den Standardgateway des VMKernels von der öffentlichen IP auf die Pfsense-IP sperr ich mich komplett aus und muss per Lara-Konsole/Shell alles wieder zurückkonfigurieren.

    VM Config sieht aus wie bei Screenshot1.png , wobei das VMNetwork an sich keinen Zweck hat (noch nicht gelöscht)

    PFSense Routing siehst du bei Screenshot2.png

    Reicht das?







  • LAYER 8 Moderator

    Hast du beim VMKernel auch das Netz richtig konfiguriert? Die IP .1.100 sehe ich, aber hast du auch DNS und Routing/Gateway konfiguriert? Da muss natürlich das Gateway gesetzt sein (also die pfSense mit dem Interface im .1.x Netz.

    Kannst du von dem WebWin2k8 denn hinpingen? Oder vom Xen? Die stehen ja im gleichen Netz, da muss nicht geroutet werden. Damit kannst du das erstmal gegenprüfen.



  • @JeGr:

    Hast du beim VMKernel auch das Netz richtig konfiguriert? Die IP .1.100 sehe ich, aber hast du auch DNS und Routing/Gateway konfiguriert? Da muss natürlich das Gateway gesetzt sein (also die pfSense mit dem Interface im .1.x Netz.

    Kannst du von dem WebWin2k8 denn hinpingen? Oder vom Xen? Die stehen ja im gleichen Netz, da muss nicht geroutet werden. Damit kannst du das erstmal gegenprüfen.

    Also Ping vom WebWin2k8 funktioniert zum VMKernel 1.100….

    DNS Routing/Gateway habe ich am VMKernel probiert zu konfigurieren - sobald ich zb als GW 192.168.1.1 einstelle (zur Router-VM) geht gar nix mehr.

    Wie müsste ich das denn korrekt konfigurieren und wo überall?


  • LAYER 8 Moderator

    Wie müsste ich das denn korrekt konfigurieren und wo überall?

    Eigentlich genau da wo du es sagst. Am Kernel selbst, der muss natürlich geroutet werden, damit er via VPN erreichbar ist. Was geht denn dann nicht mehr wenn du die einträgst?



  • @JeGr:

    Wie müsste ich das denn korrekt konfigurieren und wo überall?

    Eigentlich genau da wo du es sagst. Am Kernel selbst, der muss natürlich geroutet werden, damit er via VPN erreichbar ist. Was geht denn dann nicht mehr wenn du die einträgst?

    Wenn ich 192.168.1.100 eintrage und als Gateway 192.168.1.1 - geht gar nix mehr. Es ist keinerlei Verbindung mehr möglich. Ich muss dann per Lara-Konsole auf die Shell und das Routing bzw. die Default-Route wieder auf das Gateway von Hetzner zurückstellen damit ich von außen hin komme.

    Ich hab keine Ahnung wie es korrekt eingetragen gehört. An sich sind die Felder standardmässig auch bei dem 2ten VMKernel ausgegraut. Man kann sie aber "überschreiben" mit einem Click auf den nebenstehenden Button.



  • noch da :) ?


  • LAYER 8 Moderator

    Ja, aber da ich das Setup selbst nicht mehr betreibe kann ich leider nicht mehr reinschauen, wie das aufgesetzt war. Ich kann leider nur noch rekonstruieren, dass es so wie beschrieben funktioniert hat, aber da ich auch nicht "davor" sitze, kann ich da leider auch gerade nichts mehr dazu sagen, da mir der Vergleich fehlt, wo vllt. die kleine fiese Schraube falsch gedreht ist, die dich gerade behindert. :/

    Sorry, wäre gerne hilfreicher.


Log in to reply