VMware und IP / Netzwerk

G

gm-strasser

New Member
Hallo an alle,

wenn ich auf einem dedizierten Server bei einem Hoster mehrere IP-Adressen in unterschiedlichen Netzen habe und diese auf verschiedene virtuelle Server verteilt werden so benötigt dieser virtuelle Server in seinen IP-Einstellungen auch ein Gateway aus seinem Netz heraus. Oder sehe ich das falsch?

D.h. wenn der Provider mir zwar die IP-Adressen aus mehreren Netzen auf meinen Netzwerkport routet kann ich unter verschiedenen IP-Adressen in verschiedenen Netzen angesprochen werden, jedoch nur von der IP-Adresse die im "Hauptnetz" mit vorhandenem Gateway steht antworten. Somit würde der "Anrufer" die Antwort von einer anderen Adresse beantwortet bekommen.

Falls dies jetzt zu abstrakt war siehe folgendes:
----
Sehr geehrte Damen und Herren,

in den Produktdaten steht:
IP-Adressen: ? IP: 85.25.124.4
Gateway:: 85.25.124.1
Netmask: 255.255.255.192
Broadcast: 85.25.124.63

? IP: 85.25.126.118
Netmask: 255.255.255.128
Broadcast: 85.25.126.127

? IP: 85.25.126.117
Netmask: 255.255.255.128
Broadcast: 85.25.126.127

Gibt es zum 85.25.126.0/25 er Netz auch ein Gateway?

-
Antwort
-

für die ZusatzIPs stehen keine eignen Gateways zur Verfügung, da keine benötigt werden.

----

Die Diskussion ist eröffnet - helft mir auf die Sprünge und regt mein Denken an!

Danke

Günther
 
Hallo!
Du hast doch nur eine physikalische Schnittstelle, oder? Also gibt es auch nur einen Weg aus den lokalen IP Bereichen heraus - das default gateway.

mfG
Thorsten
 
Servus, das ist eigentlich kein Problem.
Wenn du deine VM hast und diese zB über IP Tables im Host routest, dann steuerst du mit Postrouting und Prerouting das Antwort bzw Annahmeverhalten.
Fertig ;) Schon wird nicht immer mit der Hauptip des Servers geantwortet. Alernativ kannst du auch wenns um Prozesse im Host geht mit Bind arbeiten

Gruß Sven
 
Thorsten said:
... - das default gateway. ...
Thorsten
Click to expand...

Wenn ich nun VMware Server laufen habe mit einem Netzwerk vom Typ bridged so wird die Netzwerkkarte in den promiscuous mode geschalten wobei sie praktisch alles was ankommt mithört - daraufhin werden Pakete die an den virtuellen Server im virtuellen Netz weitergeroutet werden anhand der IP-Adresse ausgefiltert (frag mich jetzt bitte nicht auf welcher Ebene von OSI 7) und "nur" vom virtuellen Server verarbeitet. Wenn der jetzt was nach aussen schickt geht dies an der IP-Ebene des Host betriebssystems vorbei direkt auf die Karte - dann haben wir den Salat da er ja aus dem x.x.126.x er Netz kein Gateway woanders hin hat - d.h. er bleibt in seinem Netzwerksegment gefangen.
 
Hi,

in dem Fall, den Du da planst, würdest Du für jede VM eine eigene MAC-Adressen erzeugen und würdest somit vom Switch-Port nicht durchgelassen werden.
Dir bleibt nur die bereits von F4RR3LL genannte Lösung, mit iptables den Traffic auf dem Server entsprechend zu routen.


-W
 
F4RR3LL said:
Wenn du deine VM hast und diese zB über IP Tables im Host routest, dann steuerst du mit Postrouting und Prerouting das Antwort bzw Annahmeverhalten.
Click to expand...

Dann muß ich aber auf dem Host erstmals mit einigem Aufwand herumkonfigurieren was die Fehleranfälligkeit auch enorm steigert.
Und erst recht den Komfort mindern würden. :(

Am einfachsten wären wohl IP-Adressen die alle aus dem selben Netzwerksegment stammen - vielleicht können die das ja machen.
 
wstuermer said:
jede VM eine eigene MAC-Adressen erzeugen und würdest somit vom Switch-Port nicht durchgelassen werden.
Click to expand...

Das mit den MAC-Adressen stimmt - jede VM Netzwerkkarte hat ihre eigene MAC, am Switch würde ich aber nur ausgesperrt wenn der fix MAC Adresse zu Port konfiguriert - dies halte ich aber für zu übervorsichtig obwohl ich auch solche Installationen kenne. (5 Netzwerkdosen nebeneinander - jemand stopselt die Rechner ab (Putze oder was auch immer) und nichts geht mehr) Dies würde ich nur an öffentlich zugänglichen Orten machen - oder wenn ich auf meinen vermieteten Servern keine virtuellen Instanzen zulassen will.

Das blöde ist nur: Ich habe mir diesen Server genau deshalb gemietet weil ich dachte über die VM´s ein wenig Spielraum für Testzwecke zu haben.
 
Hallo!
Würdest du soetwas als Provider nicht tun, wäre doch MAC Spoofing Tür und Tor geöffnet.

mfG
Thorsten
 
Hi,

ich kenne unser Netzwerk und ja, port_security ist aktiviert und das wird auch nicht geändert werden. Alles andere wäre fahrlässig.
Hab bitte Verständnis, dass Du VM-Ware zwar einsetzen kannst, der Bridge-Modus jedoch nicht zu Deiner Verfügung steht.


-W
 
@wstuermer:

Da war ich wohl zu blauäugig und werde halt mein Lehrgeld zahlen. Bin ich halt nach 3 Tagen Mietserver draufgekommen das er nicht der richtige für mich ist da der Aufwand der Administration für mich dann im Vergleich zum Nutzen nicht dafür steht.

Muß ich wohl reinbeissen und einen Server (Hardware) kaufen und bei meinem lokalen Provider abstellen. Kostet mich für den Moment zwar mehr aber dann muß ich mich nicht in die Tiefen der Netzwerkproblematik einarbeiten um auf Betriebssystemebene + Serverservices zu arbeiten.

Jeder zahlt halt sein Lehrgeld. Zum Glück sinds ja momentan nur € 129,--.
 
gm-strasser said:
... und bei meinem lokalen Provider abstellen.
Click to expand...
Da solltest Du dann aber auch wirklich sicher sein, dass der seine Ports auch nach Deinen Vorstellungen konfiguriert, was aber --wie oben schon mehrfach erwähnt-- fahrlässig wäre.

Ich gebe zu, die IP-Tables-Dokumentation ist etwas schwierig zu lesen (weil man fast alles damit machen kann), aber davon würde ich mich jetzt nicht ins Boxhorn jagen lassen. Höchstwahrscheinlich gibt es sogar hier im Forum schon einen Thread dazu, in dem das Notwendige geliefert wird -- wenn nicht, mach halt einen auf!
 
Bzgl iptables.... ich schreibe derzeit eh an einem Copy Paste Howto für VMware 2 Server....
dort ist unter anderem der Part IPTABLES drin .
Sprich das Routen. Ich werde erklären wie man Host Only in der VM und NAT Routing unter einen Tisch bringt. Wer mag mit durchrouten ohne Portfilter.... und wer nicht mag mit ner art Portfilter im Host. Ist wenn mans mal gemacht hat alles gar nicht so schwer. Das erscheint meist am Anfang nur so weil iptables ja idr ned das einzige ist womit man anfangs nicht zurecht kommt.
Gruß Sven
 
gm-strasser said:
Die Diskussion ist eröffnet - helft mir auf die Sprünge und regt mein Denken an!
Click to expand...

Darf ich mal kurz zusammenfassen?

Iststand:
Code: 
(ifconfig)
eth0   inet Addr:85.25.124.4    Bcast:85.25.124.63   Mask:255.255.255.192
eth0:1 inet Addr:85.25.126.118  Bcast:85.25.126.127  Mask:255.255.255.128
eth0:2 inet Addr:85.25.126.117  Bcast:85.25.126.127  Mask:255.255.255.128

(route)
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
85.25.124.0     0.0.0.0         255.255.255.192 U     0      0        0 eth0
0.0.0.0         85.25.124.1     0.0.0.0         UG    0      0        0 eth0

Versuch' doch mal folgendes:

2 VMs anlegen mit den von Serverloft genannten Daten:
Code: 
1. VM: IP: 85.25.126.118 Netmask: 255.255.255.128
   Broadcast: 85.25.126.127 Gateway:85.25.126.1
2. VM: IP: 85.25.126.117 Netmask: 255.255.255.128
   Broadcast: 85.25.126.127 Gateway:85.25.126.1
VMware nicht auf Bridging setzten, sondern in der VM-Konfiguration ein Custom-Net (z.B. vmnet4) auswählen.

Keinen der VMware-Dienste vmware-bridge, vmware-dhcp oder vmware-nat starten, nur die VM's

Keines der Interfaces eth0:1 oder eth0:2 konfigurieren.

Stattdessen manuell folgendes:
Code: 
ifconfig vmnet4 85.25.126.1 netmask 255.255.255.128  broadcast 85.25.126.127
und ip_forward setzen.

Es sollte sich folgendes ergeben:
Code: 
(ifconfig)
eth0   inet Addr:85.25.124.4    Bcast:85.25.124.63   Mask:255.255.255.192
vmnet4 inet Addr:85.25.126.1    Bcast:85.25.126.127  Mask:255.255.255.128

(route)
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
85.25.124.0     0.0.0.0         255.255.255.192 U     0      0        0 eth0
85.25.126.0     0.0.0.0         255.255.255.128 U     0      0        0 vmnet4
0.0.0.0         85.25.124.1     0.0.0.0         UG    0      0        0 eth0

Dann hast du ein lokales virtuelles Netz (eben vmnet4), in dem sich Deine VMs mit den zugeteilten IPs befinden. Alles, was nach 85.25.126.0/25 geht, würde der Server dorthin routen. Das beträfe zwar deutlich mehr IPs (z.B. auch 85.25.126.119), aber Serverloft wird die für dort bestimmten Daten ohnehin nicht bis zu Deinem Server routen. Und irgendwas werden sie sich mit der Angabe der großzügigen Subnetzmaske ja gedacht haben.
Alles andere jedenfalls wird vom Server via eth0 geroutet - egal ob vom Server selbst oder einer der VMs aus gesendet. In der Gegenrichtung wird Serverloft Dir die Daten für 85.25.126.117/.118 auf eth0 senden - ab da kann der Server sie intern weiterleiten.
Hin- und Rückroute sind also gegeben - Deine VMs sollten weltweit erreichbar sein.

Viel Erfolg!
 
Interessante und viel versprechende Lösung.
Aber wo ist der Unterschied zum VMware-Networking per NAT?
Genau für diesen Fall gibt es das doch und sollte funktionieren.

huschi.
 
Generell mal ein großes DANKE!

Mittlerweilen haben sich hier einige Denkanregungen und Hinweise zu einem Lösungsweg ergeben.
Leider bin ich bis incl. Sonntag nicht im Lande - aber am Montag werde ich versuchen dies auf meinem Mietserver auszuprobieren.

mfg
Günther
 
Hier meine Loesung

ACHTUNG: Ich habe eben gerade eine Meldung von meinem Hoster bekommen, dass ich ein anderes System lahmgelegt habe. Das liegt an der arp_proxy Einstellung - die hat wohl zuviele IP-Adressen "an sich gezogen". Bitte daher die aktuell beschriebene Config nicht verwenden. Ich werde stattdessen einen manuellen arp-Eintrag fuer die IP auf der VM anlegen, damit das nicht mehr passieren kann.

Niklas

---------------NACHTRAG-------------------------

Das Problem ist nun auch behoben. Siehe Posting weiter unten.

-----------------DONT-USE-AT-THE-MOMENT-------------

Ich moechte folgende funktionierende Config mit euch teilen. Das ganze muesst ihr natuerlich auf eure verfuegbaren IP-Adressen anpassen.

Host-System:
Code: 
loft1897:~# cat /etc/vmware/networking
VERSION=1,0
answer VNET_4_HOSTONLY_NETMASK 255.255.255.128
answer VNET_4_HOSTONLY_SUBNET 85.25.78.70
answer VNET_4_VIRTUAL_ADAPTER yes
answer VNL_DEFAULT_BRIDGE_VNET -1
add_bridge_mapping eth0 -1
add_bridge_mapping eth1 -1

loft1897:~# cat /etc/network/if-up.d/arp_proxy
#!/bin/sh

if [ "$IFACE" = eth0 ] || [ "$IFACE" = vmnet4 ]; then
    echo 1 > "/proc/sys/net/ipv4/conf/$IFACE/proxy_arp"
fi

loft1897:~# cat /etc/sysctl.conf | grep net.ipv4.ip_forward
net.ipv4.ip_forward=1

Ergebnis ist der obigen Config ist dann u.a.
Code: 
loft1897:~# ifconfig vmnet4
vmnet4    Link encap:Ethernet  HWaddr 00:50:56:c0:00:04
          inet addr:85.25.78.71  Bcast:85.25.78.127  Mask:255.255.255.128
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:618 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

loft1897:~# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
85.25.73.128    0.0.0.0         255.255.255.192 U     0      0        0 eth0
85.25.78.0      0.0.0.0         255.255.255.128 U     0      0        0 vmnet4
0.0.0.0         85.25.73.129    0.0.0.0         UG    0      0        0 eth0
Gast-System:
Code: 
    IP:        85.25.78.72
    Gateway:    85.25.78.71
    Netmask:    255.255.255.128
DNS nicht vergessen.


Danach ist das Gast-System von aussen transparent erreichbar.

-----------------DONT-USE-AT-THE-MOMENT-------------

Niklas
 
Last edited by a moderator:
So, das Problem ist nun behoben. proxy_arp wird nun NICHT (!!) mehr aktiviert. Stattdessen habe ich nun folgende Arp-Eintraege von Hand vorgenommen:

1) arp -v -i vmnet4 -s 85.25.78.72 00:0C:29:5D:C0:DB pub
2) arp -v -i eth0 -s 85.25.78.72 00:40:d0:bf:e3:41 pub

Bei 1. handelt es sich um die MAC des Virtuellen Network Adapters in der Virtual Machine. Bei 2. handelt es sich um die MAC von eth0 des Host-Rechners.

Niklas
 
You must log in or register to reply here.
Back
Top