15
vmware server 2.0 öffentliche IP?
rootserver linux mit 2IP´s
Hallo, ich habe einen rootserver mit linux und funktionierendem vmwareserver.
Mein root hat 2 öffentliche IP´s:
eine eth0 und eine eth0:1, ping auf beide adressen sind möglich
wie bekomme ich jetzt die IP vom eth0:1 direkt auf die installierte vm?
Jemand eine Idee?
DANKE
Hallo, ich habe einen rootserver mit linux und funktionierendem vmwareserver.
Mein root hat 2 öffentliche IP´s:
eine eth0 und eine eth0:1, ping auf beide adressen sind möglich
wie bekomme ich jetzt die IP vom eth0:1 direkt auf die installierte vm?
Jemand eine Idee?
DANKE
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 102956
Url: https://administrator.de/contentid/102956
Ausgedruckt am: 25.11.2024 um 14:11 Uhr
15 Kommentare
Neuester Kommentar
Hallihallo,
um die selbe öffentliche IP-Adresse in der VM nutzen zu können wie auf der physikalischen Maschine musst du in der Virtualisierungssoftware in den Hardwareeinstellungen der VM unter Netzwerkkarte den NAT-Modus verwenden.
Auswählbare Modis:
Bridged
Host-Only
NAT
Bridged bedeutet, dass die VM eine eigene IP-Adresse bekommt, die über die Virtualisierungssoftware, bzw physikalische Maschine hinaus identisch bleibt.
also VM = 192.168.0.100, so ist diese auch über 192.168.0.100 anpingbar von einem anderen Client.
NAT = die in der VM eingegebene IP-Adresse wird beim routen durch die physikalische Netzwerkkarte ersetzt durch die des physiklaischen Netzwerkkarten-IP.
Host-Only = Die IP-Adresse kann lediglich auf und vom Host aus angepingt/zugegriffen werden, Von Außerhalb ist kein Zugriff/Ping möglich.
Hoffe ich konnte dir helfen
Mit freundlichen Grüßen
Freaky
um die selbe öffentliche IP-Adresse in der VM nutzen zu können wie auf der physikalischen Maschine musst du in der Virtualisierungssoftware in den Hardwareeinstellungen der VM unter Netzwerkkarte den NAT-Modus verwenden.
Auswählbare Modis:
Bridged
Host-Only
NAT
Bridged bedeutet, dass die VM eine eigene IP-Adresse bekommt, die über die Virtualisierungssoftware, bzw physikalische Maschine hinaus identisch bleibt.
also VM = 192.168.0.100, so ist diese auch über 192.168.0.100 anpingbar von einem anderen Client.
NAT = die in der VM eingegebene IP-Adresse wird beim routen durch die physikalische Netzwerkkarte ersetzt durch die des physiklaischen Netzwerkkarten-IP.
Host-Only = Die IP-Adresse kann lediglich auf und vom Host aus angepingt/zugegriffen werden, Von Außerhalb ist kein Zugriff/Ping möglich.
Hoffe ich konnte dir helfen
Mit freundlichen Grüßen
Freaky
Hallo,
ich verstehe die Frage nicht ganz.
Im Normalfall ist es so, dass die Netzwerkkarte der VM scheinbar direkt am gleichen Anschluss hängt wie die physikalische.
Also einfach direkt die öffentliche IP eintragen und gut.
Stefan
ich verstehe die Frage nicht ganz.
Im Normalfall ist es so, dass die Netzwerkkarte der VM scheinbar direkt am gleichen Anschluss hängt wie die physikalische.
Also einfach direkt die öffentliche IP eintragen und gut.
Stefan
Beide öffentlichen IPs sind aber auf dem VM Host vergeben nämlich einmal als IP auf dem physischen Interface eth 0 und eine auf dem Subinterface eth 0.1 !!!
Man sollte den Thread schon richtig lesen...
Beide Antworten sind unsinnig und z. Teil auch schlicht falsch.
Im bridged Modus bridged der VM Host Adapter lediglich Ethernet Frames per OSI Layer 2 auf die internen VM Adressen folglich müssen die im gleichen IP Netz liegen, sind aber niemals gleich !
Bei NAT wird das interne VM Netz, was durchaus dann RFC 1918 IP Adressen haben kann, auf die IP des VM Hosts per NAT umgesetzt.
Das hat den Nachteil das die VM dann von aussen nur per Port Forwarding beim VM Host zu erreichen ist.
Das lässt sich aber im Netzwerk Setting des VM Hosts einstellen wenn man dann NAT macht.
Du hast 2 Möglichkeiten:
Nehme einfach die IP vom Interface eth 0.1 weg und gebe sie der VM sofern das technisch machbar ist im VM Host.
Dann musst du den Adapter im Bridged Modus betreiben, kannst aber nur eine einzige VM betreiben, die dann aber transparent von außen erreichbar ist.
Andere Möglichkeit: Du setzt den VM Host in den NAT Modus und gibts der VM eine RFC 1918 Adresse wie z.B. 172.16.1.100 /24
Um die VM dann von aussen zu erreichen musst du Port Forwarding konfigurieren entweder über eth 0 oder 0.1.
Das könntest du dann z.B. mit der IP von eth 0.1 machen, damit es nicht zu Port Konflikten mit dem eigentlichen Host auf eth 0 kommt !
Man sollte den Thread schon richtig lesen...
Beide Antworten sind unsinnig und z. Teil auch schlicht falsch.
Im bridged Modus bridged der VM Host Adapter lediglich Ethernet Frames per OSI Layer 2 auf die internen VM Adressen folglich müssen die im gleichen IP Netz liegen, sind aber niemals gleich !
Bei NAT wird das interne VM Netz, was durchaus dann RFC 1918 IP Adressen haben kann, auf die IP des VM Hosts per NAT umgesetzt.
Das hat den Nachteil das die VM dann von aussen nur per Port Forwarding beim VM Host zu erreichen ist.
Das lässt sich aber im Netzwerk Setting des VM Hosts einstellen wenn man dann NAT macht.
Du hast 2 Möglichkeiten:
Nehme einfach die IP vom Interface eth 0.1 weg und gebe sie der VM sofern das technisch machbar ist im VM Host.
Dann musst du den Adapter im Bridged Modus betreiben, kannst aber nur eine einzige VM betreiben, die dann aber transparent von außen erreichbar ist.
Andere Möglichkeit: Du setzt den VM Host in den NAT Modus und gibts der VM eine RFC 1918 Adresse wie z.B. 172.16.1.100 /24
Um die VM dann von aussen zu erreichen musst du Port Forwarding konfigurieren entweder über eth 0 oder 0.1.
Das könntest du dann z.B. mit der IP von eth 0.1 machen, damit es nicht zu Port Konflikten mit dem eigentlichen Host auf eth 0 kommt !
Also aqui hat recht, was die ersten beiden antworten angeht, aber trotzdem danke.
@aqui, die Idee ist schon mal die wie ich es mir auch vor stelle, aber ich weiß nicht wie das gehen soll.
Es handelt sich um einen srv2003 Standard, hast du mal versucht dem OS eine oeffentliche IP zu zuweisen? Bei mir geht es leider nicht. Welchen Ethernetadapter muss ich denn der vm zuweisen? Bridged oder Host?
Eine einzige vm wuerde mir in diesem Fall völlig ausreichen
VmNat scheidet definitiv aus, ich moechte den Server in der vm "pur" ueber die oeffentliche ip ansprechen, so wie auch das WirtOS (Exchange, citrix usw)
Danke fuer eure Bemühungen
@aqui, die Idee ist schon mal die wie ich es mir auch vor stelle, aber ich weiß nicht wie das gehen soll.
Es handelt sich um einen srv2003 Standard, hast du mal versucht dem OS eine oeffentliche IP zu zuweisen? Bei mir geht es leider nicht. Welchen Ethernetadapter muss ich denn der vm zuweisen? Bridged oder Host?
Eine einzige vm wuerde mir in diesem Fall völlig ausreichen
VmNat scheidet definitiv aus, ich moechte den Server in der vm "pur" ueber die oeffentliche ip ansprechen, so wie auch das WirtOS (Exchange, citrix usw)
Danke fuer eure Bemühungen
Danke. Dir auch einen schönen Morgen...
Wenn schon Fehler suchen dann bitte keine Neuen machen.
Aber nichts destotrotz hast Du die beiden richtigen Möglichkeiten schön beschrieben.
a) Eine der beiden öffentlichen IPs nur auf der VM verwenden
b) "Verstecken" der VM hinter ETH0.1 mit NAT
Stefan
Beide öffentlichen IPs sind aber auf dem VM Host vergeben
nämlich einmal als IP auf dem physischen Interface eth 0 und eine
auf dem Subinterface eth 0.1 !!!
Man sollte den Thread schon richtig lesen...
Das die doppelte Verwendung von IP-Adressen zu Problemen führt haben die meisten schon mitbekommen.nämlich einmal als IP auf dem physischen Interface eth 0 und eine
auf dem Subinterface eth 0.1 !!!
Man sollte den Thread schon richtig lesen...
Im bridged Modus bridged der VM Host Adapter lediglich Ethernet
Frames per OSI Layer 2 auf die internen VM Adressen folglich
müssen die im gleichen IP Netz liegen, sind aber niemals gleich !
Dir ist aber bekannt das IP erst im 3. Layer verarbeitet wird?Frames per OSI Layer 2 auf die internen VM Adressen folglich
müssen die im gleichen IP Netz liegen, sind aber niemals gleich !
Wenn schon Fehler suchen dann bitte keine Neuen machen.
Aber nichts destotrotz hast Du die beiden richtigen Möglichkeiten schön beschrieben.
a) Eine der beiden öffentlichen IPs nur auf der VM verwenden
b) "Verstecken" der VM hinter ETH0.1 mit NAT
Stefan
Hallo Stefan, Lösungsvorschlag a wäre mein Favorit, aber wie?
Ich häng mich mal mit dran.
Ich denke das Problem liegt bei der IP/Subnetzkombination - Ich habe es grade mal ausprobiert, Windows nimmt durchaus öffentliche IPs an, allerdings muss die Subnetzmaske passen.
Du solltest mal genauer erklären mit welcher Begründung Windows bei dir keine öffentliche IP annimmt.
Grüße
Max
Ich denke das Problem liegt bei der IP/Subnetzkombination - Ich habe es grade mal ausprobiert, Windows nimmt durchaus öffentliche IPs an, allerdings muss die Subnetzmaske passen.
Du solltest mal genauer erklären mit welcher Begründung Windows bei dir keine öffentliche IP annimmt.
Grüße
Max
Ja, die IP Adresse nimmt das System schon noch, aber wie du schon erwähnt hast stimmt die Subnetzmaske nicht. Wenn ich Subnetz 255.255.255.255 angebe gibt es einen Fehler, wobei ich mir auch nicht sicher bin, ob die Maske überhaupt stimmt.
So, ich habe jetzt mal die bridge auf eth0:1 gelegt und den server in der vm gestartet. Seltsamerweise lässt sich die Netzwerkkarte nicht starten, d.h. sie wird beim booten nicht aktiviert:
The network bridge on device vmnet0 is not running. The virtual machine will not be able to communicate with the host or with other machines on your network. Virtual device Ethernet0 will start disconnected.
langsam werde ich bekloppt...
nach einem ifconfig gibt es auch gar kein vmnet0???
The network bridge on device vmnet0 is not running. The virtual machine will not be able to communicate with the host or with other machines on your network. Virtual device Ethernet0 will start disconnected.
langsam werde ich bekloppt...
nach einem ifconfig gibt es auch gar kein vmnet0???
Eine Hostmaske mit 32 Bit zu verwenden ist ja auch kompletter Blödsinn, damit isolierst du das Interface ja vollkommen.
Den Unsinn kannst du also gleich wieder vergessen.
Du hast genau 2 Möglichkeiten:
a.) Mit NAT, dann NATest du deine VM die dann intern eine RFC 1918 IP hat auf eins der beiden öffentlichen Interface eth 0 oder eth 0.1.
b.) Du bridgest aber dann muss eine deiner zugeteilten IP Adressen entweder auf eth 0 oder besser eth0.1 auf deine VM übertragen werden:
Das sähe dann so aus:
Die .b) Variante birgt die Gefahr das du die Connectivity auf deinen Root Server verlierst mit einem Fehlgriff. Vorteil ist dann das die VM eine öffentliche IP hat. Ob das aber letztlich wirklich ein Vorteil ist ist höchst fragwürdig. Ein Windows OS so ungeschützt ins öffentliche Internet zu exponieren ist eigentlich dümmlicher Leichtsinn !
Die a.) Variante mit NAT ist da dann besser. Du kannst RFC 1918 IPs auf der VM konfigurieren wie z.B. 172.16.1.1 (255.255.255.0), hast also keinen IP Adressstress mehr.
Nachteil: Du musst jeden Zugriff per Port Forwarding (Weiterleitung) im VM Host konfigurieren auf die lokale IP der VM.
Der Nachteil kann aber auch zum Vorteil geraten, denn so kannst du dediziert bestimmen WAS auf deine Winblows VM zugreifen kann vom öffentlichen Internet.
Die NAT Variante ist also letztlich für dich am besten..
Den Unsinn kannst du also gleich wieder vergessen.
Du hast genau 2 Möglichkeiten:
a.) Mit NAT, dann NATest du deine VM die dann intern eine RFC 1918 IP hat auf eins der beiden öffentlichen Interface eth 0 oder eth 0.1.
b.) Du bridgest aber dann muss eine deiner zugeteilten IP Adressen entweder auf eth 0 oder besser eth0.1 auf deine VM übertragen werden:
Das sähe dann so aus:
Die .b) Variante birgt die Gefahr das du die Connectivity auf deinen Root Server verlierst mit einem Fehlgriff. Vorteil ist dann das die VM eine öffentliche IP hat. Ob das aber letztlich wirklich ein Vorteil ist ist höchst fragwürdig. Ein Windows OS so ungeschützt ins öffentliche Internet zu exponieren ist eigentlich dümmlicher Leichtsinn !
Die a.) Variante mit NAT ist da dann besser. Du kannst RFC 1918 IPs auf der VM konfigurieren wie z.B. 172.16.1.1 (255.255.255.0), hast also keinen IP Adressstress mehr.
Nachteil: Du musst jeden Zugriff per Port Forwarding (Weiterleitung) im VM Host konfigurieren auf die lokale IP der VM.
Der Nachteil kann aber auch zum Vorteil geraten, denn so kannst du dediziert bestimmen WAS auf deine Winblows VM zugreifen kann vom öffentlichen Internet.
Die NAT Variante ist also letztlich für dich am besten..
Ok, danke für deinen ausführlichen Beitrag. Aber ich bevorzuge nach wie vor deine Variante b. NAT kommt hier absolut nicht in Frage! Dümmlicher Leichtsinn? Danke...
Nur ist mir damit noch nicht geholfen, es ist immer noch nicht klar wie ich bei der Konfiguration vor gehen muss, Subnetzmaske ist nicht klar und Gateway fehlt mir auch?
Nur ist mir damit noch nicht geholfen, es ist immer noch nicht klar wie ich bei der Konfiguration vor gehen muss, Subnetzmaske ist nicht klar und Gateway fehlt mir auch?
Beispiel, da du es ja vorziehst deine Subnetzmaske zu verheimlichen..:
Deine öffentlichen IPs an den Interfaces sind:
1.) eth0 = 217.10.1.1
2.) eth0.1 =217.10.1.2
Jeweils mit einer Maske von 255.255.255.0
Das Gateway was dein Provder dir gegeben hat ist die 217.10.1.254.
Alle diese Daten wie Subnetzmaske und Gateway zu den öffentlichen IPs kannst du dir auf deinem VM Host ja mit ifconfig bzw. route ansehen. Da die VM gebridged ist muss das ja logischerweise identisch sein !!
So, dann machst du folgendens:
Nun hast du eine freie öffentliche IP Adresse die du auf deiner VM installierst inkl. der gleichen Netzmaske die sie sie vorher auf dem Host hatte !
Gateway was der Host hat und gut ist...
Das ist doch nun wirklich ein banales Szenario wenn man im bridged Modus arbeitet !!!
Deine öffentlichen IPs an den Interfaces sind:
1.) eth0 = 217.10.1.1
2.) eth0.1 =217.10.1.2
Jeweils mit einer Maske von 255.255.255.0
Das Gateway was dein Provder dir gegeben hat ist die 217.10.1.254.
Alle diese Daten wie Subnetzmaske und Gateway zu den öffentlichen IPs kannst du dir auf deinem VM Host ja mit ifconfig bzw. route ansehen. Da die VM gebridged ist muss das ja logischerweise identisch sein !!
So, dann machst du folgendens:
- Du nimmst die IP vom Interface eth 0.1 weg also deinstallierst das gesamte Interface o.ä.
Nun hast du eine freie öffentliche IP Adresse die du auf deiner VM installierst inkl. der gleichen Netzmaske die sie sie vorher auf dem Host hatte !
Gateway was der Host hat und gut ist...
Das ist doch nun wirklich ein banales Szenario wenn man im bridged Modus arbeitet !!!
lol, ich verheimliche meine subnetzmaske nicht, ich weiss sie nur nicht...
aber route gibt folgendes aus:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
85.214.128.1 hxxxxx.strato 255.255.255.255 UGH 0 0 0 eth0
172.16.0.0 * 255.255.255.252 U 0 0 0 tap0
172.16.245.0 * 255.255.255.0 U 0 0 0 vmnet8
192.168.32.0 * 255.255.255.0 U 0 0 0 vmnet1
link-local * 255.255.0.0 U 0 0 0 eth0
loopback * 255.0.0.0 U 0 0 0 lo
default 85.214.128.1 0.0.0.0 UG 0 0 0 eth0
aber route gibt folgendes aus:
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
85.214.128.1 hxxxxx.strato 255.255.255.255 UGH 0 0 0 eth0
172.16.0.0 * 255.255.255.252 U 0 0 0 tap0
172.16.245.0 * 255.255.255.0 U 0 0 0 vmnet8
192.168.32.0 * 255.255.255.0 U 0 0 0 vmnet1
link-local * 255.255.0.0 U 0 0 0 eth0
loopback * 255.0.0.0 U 0 0 0 lo
default 85.214.128.1 0.0.0.0 UG 0 0 0 eth0
Hallo, Problem besteht immernoch. Laut Strato Hotline soll es möglich sein, nur der gute Mann wusste selbst nicht wie man das einrichtet. Sein einzigster Tip war, die erste IP als Gateway zu nutzen??? Was ich nicht ganz verstehe...
Kann ich eth0 nicht noch eine locale IP zuweisen z.B. 192.168.0.1 also zusätzlich zu den 2 öffentlichen IP´s. Dann der vm z.B. 192.168.0.10 im bridged Modus und die 192.168.0.1 dann als Gateway und DNS?
Kann ich eth0 nicht noch eine locale IP zuweisen z.B. 192.168.0.1 also zusätzlich zu den 2 öffentlichen IP´s. Dann der vm z.B. 192.168.0.10 im bridged Modus und die 192.168.0.1 dann als Gateway und DNS?
Nein, das ist vollkommen unmöglich, denn 192.168er IP Adressen sind RFC 1918 Adressen und die dürfen niemals sichtbar sein an Interface mit öffentlichen IPs !
http://de.wikipedia.org/wiki/Private_IP-Adresse
Auch wenn würden sie vom Hoster oder Provider sofort in den Datenmülleimer verfrachtet, da es diese Netze im Internet nicht gibt !
Es ist auch unverständlich wo dein Problem ist... VmWare erzeugt dir doch beim Setup 2 VM Adressen die du ja auch siehst in der VM !
Mit einer machst du nun NAT zu einem der Interfaces an eth0 oder eth0.1 und gut ist.
Das kann doch nicht so schwer sein !
Wenn du von der VM irgendwo ins Internet pingen kannst dann klappt es doch... !?
http://de.wikipedia.org/wiki/Private_IP-Adresse
Auch wenn würden sie vom Hoster oder Provider sofort in den Datenmülleimer verfrachtet, da es diese Netze im Internet nicht gibt !
Es ist auch unverständlich wo dein Problem ist... VmWare erzeugt dir doch beim Setup 2 VM Adressen die du ja auch siehst in der VM !
Mit einer machst du nun NAT zu einem der Interfaces an eth0 oder eth0.1 und gut ist.
Das kann doch nicht so schwer sein !
Wenn du von der VM irgendwo ins Internet pingen kannst dann klappt es doch... !?
