# VMWare Server auf Strato Rootserver

## COiN3D

Hallo zusammen,

ich wuerde gerne VMWare Server auf einem Rootserver von Strato betreiben, aber unter der Bedingung dass die VMWare mit der echten, zweiten IP Adresse des Servers zu erreichen ist - hat das jemand schon hingebracht, bzw. ist das ueberhaupt moeglich? Im Internet findet man leider auch nicht gerade viel zu diesem Thema. In einem Forum wurde mal behauptet, dass meistens die MAC Adressen beim Provider geblockt werden - und in diesem Falle koennte man auch per VMWare leider wenig machen, da ja nur ganz bestimmte Ranges fuer VMWare zur Verfuegung stehen.

Danke & Gruss,

----------

## COiN3D

Okay, vllt. liegt es gar nicht an Strato. Das lustige ist, Strato hat irgendwann angekündigt, ne zweite IP herzugeben...diese zweite IP habe ich auch "erhalten" und soweit konfiguriert gehabt. Hab also zwei eth-Devices auf dem Server (eth0 und eth1). 

Ich habe heute mal einfach plump versucht, ein "LAN" mit Bridged Networking aufzubauen. Ich habe also ein Netzwerkdevice eth0:1 erstellt und vmnet2 auf das virtuelle eth0:1 gebridged und die IP 192.168.0.1/24 gegeben. Der Knoppix-VM habe ich dann die IP 192.168.0.5/24 verpasst. Kein Ping möglich, die Auflösung scheiterte bereits bei der Auflösung der MAC-Adresse. Nach weiterem rumprobieren habe ich der Knoppix-VM einfach mal die Standard-Bridge auf eth0 zugewiesen. Und tada, plötzlich konnte ich eth0:1 alias 192.168.0.1 pingen. Scheinbar kann ich keine VMWare-Bridge auf eine "virtuelle" Netzwerkkarte wie eth0:1 legen. 

Hat jemand das gleiche Problem?

----------

## sschlueter

Du musst überhaupt nicht mit Aliasen arbeiten.

----------

## COiN3D

 *sschlueter wrote:*   

> Du musst überhaupt nicht mit Aliasen arbeiten.

 

Du meinst, weil ich eth0 und eth1 habe? Das ist richtig. Allerdings konnte ich mit eth1 nicht mal ein "LAN" aufbauen, wie ich es wenigstens mit eth0 geschafft habe. Selbes Problem, Mac-Adressen Auflösung scheitert laut tcpdump. Und irgendwie ist eth1 auch virtuell. Möchte gerne wissen, wie Strato das eigentlich hinbekommen hat, sobald die zweite IP verfügbar war, hatte ich nämlich zwei Netzwerkkarten in meinem Server:

```
lspci -v:

01:0d.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5705 Gigabit Ethernet (rev 03)

        Subsystem: Broadcom Corporation NetXtreme BCM5705 Gigabit Ethernet

        Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 19

        Memory at feab0000 (64-bit, non-prefetchable) [size=64K]

        Capabilities: [48] Power Management version 2

        Capabilities: [50] Vital Product Data

        Capabilities: [58] Message Signalled Interrupts: 64bit+ Queue=0/3 Enable-

01:0e.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5705 Gigabit Ethernet (rev 03)

        Subsystem: Broadcom Corporation NetXtreme BCM5705 Gigabit Ethernet

        Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 16

        Memory at feae0000 (64-bit, non-prefetchable) [size=64K]

        Capabilities: [48] Power Management version 2

        Capabilities: [50] Vital Product Data

        Capabilities: [58] Message Signalled Interrupts: 64bit+ Queue=0
```

----------

## sschlueter

Vielleicht habe ich ja Tomaten auf den Augen, aber auf den ersten Blick sieht das wie zwei echte Netzwerkkarten aus.

Und zu der Sache mit den virtuellen Switches von VMware: Lies dir mal den Artikel bei Heise Netze durch.

Ich glaube, bin mir aber nicht sicher, dass dein Denkfehler ist, dass du denkst, dass die IP-Adressen der virtuellen Maschinen auf dem Hostsystem per ifconfig angezeigt werden müssen. Das ist aber nicht der Fall.

----------

## Daimos

Das sieht schwer nach 2 physikalischen Netzwerkkarten aus. Ich habe bei Strato ebenfalls 2 IP Adressen, lspci zeigt mir nur eine Netzwerkkarte an. Darüberhinaus confe ich die "zweite" IP als eth0:1.

----------

## COiN3D

 *Daimos wrote:*   

> Das sieht schwer nach 2 physikalischen Netzwerkkarten aus. Ich habe bei Strato ebenfalls 2 IP Adressen, lspci zeigt mir nur eine Netzwerkkarte an. Darüberhinaus confe ich die "zweite" IP als eth0:1.

 

Das ist ja sehr interessant. Denn laut dieser Strato-FAQ ist das mit eth0:1 ja auch korrekt. Scheinbar bin ich irgendwie der einzige mit zwei Netzwerkkarten...wobei was mir noch merkwürdig vorkommt ist die MAC-Adresse dieser zweiten Netzwerkkarte:

eth0      Link encap:Ethernet  HWaddr 00:E0:81:59:47:EE  

eth1      Link encap:Ethernet  HWaddr 00:E0:81:59:47:EF  

Meint ihr der Zufall hat es so gewollt dass die Mac-Adresse von eth1 EF , also um einen Wert höher liegt als eth0?  :Very Happy: 

----------

## dertobi123

 *COiN3D wrote:*   

> eth0      Link encap:Ethernet  HWaddr 00:E0:81:59:47:EE  
> 
> eth1      Link encap:Ethernet  HWaddr 00:E0:81:59:47:EF  
> 
> Meint ihr der Zufall hat es so gewollt dass die Mac-Adresse von eth1 EF , also um einen Wert höher liegt als eth0? 

 

Nein, speziell das spricht für zwei pyhsikalische Karten/Chips.

----------

## sschlueter

COiN3D will aber eine virtuelle Maschine betreiben, die die zweite öffentliche IP-Adresse verwenden soll.

Angenommen, es gibt zwei physikalische Netzwerkkarten im Hostsystem. Dann würde man nur einer der beiden Karten eine IP-Adresse zuweisen, und zwar die erste öffentliche IP. Der virtuellen Netzwerkkarte der virtuellen Maschine würde man die zweite öffentliche IP zuweisen, und diese virtuelle Netzwerkkarte würde man mit einer der beiden physikalischen Netzwerkkarten bridgen, es spielt dabei keine Rolle, mit welcher.

Angenommen, es gibt nur eine funktionierende physikalische Netzwerkkarte und die andere ist fake oder nicht-angeschlossen oder wasauchimmer. Dann würde man der funktionierenden physikalischen Netzwerkkarte die erste öffentliche IP zuweisen und der virtuellen Netzwerkkarte der virtuellen Maschine die zweite öffentliche IP-Adresse, und diese virtuelle Netzwerkkarte würde man mit der funktionierenden physikalischen Netzwerkkarte bridgen.

In beiden Fällen benötigt man kein Alias.

Und wenn ein MAC-Filter vom Provider eingesetzt wird, dann geht es ohnehin nicht mit einfachem Bridging.

edit: Fallunterscheidung eingebaut

----------

## COiN3D

 *sschlueter wrote:*   

> COiN3D will aber eine virtuelle Maschine betreiben, die die zweite öffentliche IP-Adresse verwenden soll.
> 
> Angenommen, es gibt zwei physikalische Netzwerkkarten im Hostsystem. Dann würde man nur einer der beiden Karten eine IP-Adresse zuweisen, und zwar die erste öffentliche IP. Der virtuellen Netzwerkkarte der virtuellen Maschine würde man die zweite öffentliche IP zuweisen, und diese virtuelle Netzwerkkarte würde man mit einer der beiden physikalischen Netzwerkkarten bridgen, es spielt dabei keine Rolle, mit welcher.
> 
> Angenommen, es gibt nur eine funktionierende physikalische Netzwerkkarte und die andere ist fake oder nicht-angeschlossen oder wasauchimmer. Dann würde man der funktionierenden physikalischen Netzwerkkarte die erste öffentliche IP zuweisen und der virtuellen Netzwerkkarte der virtuellen Maschine die zweite öffentliche IP-Adresse, und diese virtuelle Netzwerkkarte würde man mit der funktionierenden physikalischen Netzwerkkarte bridgen.
> ...

 

Genau so meine ich es. Wobei wenn ein MAC-Filter eingesetzt wird, wäre es dann nicht möglich die MAC-Adresse der zweiten physikalischen Netzwerkkarte der virtuellen Netzwerkkarte zuzuweisen? Quasi per ifconfig in der virtuellen Maschine. Oder muss man die MAC-Adresse zwingend über VMWare selbst ändern, was ja dann aufgrund des MAC-Adresspools von VMWare gar nicht zugelassen werden würde..?

----------

## sschlueter

Zu der Sache mit dem begrenzten MAC-Adresspool von VMWare kann ich so aus dem Stehgreif nichts sagen.

Angenommen, es gibt einen MAC-Filtler und das Ändern der MAC-Adresse beim virtuellen System funktioniert nicht.

Dann würde man jeder der beiden physikalischen Interfaces je eine öffentliche IP zuweisen. Oder, wenn es sich nur um ein physikalisches Interface handelt, dann würde man diesem Interface beide öffentlichen IPs zuweisen. (Das wäre dann der einzige Fall, bei dem überhaupt ein Alias verwendet wird.) Der virtuellen Maschine würde man eine private IP-Adresse geben und durch den VMware-NAT-Modus anstelle des VMware-Bridge-Modus mit der Aussenwelt verbinden. Und die Dienste der virtuellen Maschine würde man per VMware-Portforwarding zur Verfügung stellen. Dieses Verfahren hat natürlich die bekannten Nachteile eines Portforwardings hinsichtlich kompatibler Protokolle.

Und bevor jemand fragt: Ich kann aus dem Stehgreif auch nicht sagen, ob man da irgendwie per IPTABLES ansetzen kann (was mehr Möglichkeiten bedeuten würde). Der VMware Server verwendet halt ein proprietäres Kernel-Modul und sowohl der Bridge als auch der NAT-Modus können völlig untransparent zum Netfilter-Framework implementiert worden sein.

Natürlich kann man auf dem Hostsystem beliebige Proxies für das virtuelle System laufen lassen, aber es ist fraglich, ob das Sinn der Sache ist, weil das natürlich die Isolierung der Systeme verschlechtern könnte.

----------

