Das Forum wurde aktualisiert. Wurde höchste Zeit. Wenn etwas nicht funktioniert, bitte gerne hier jederzeit melden.
(Das "alte Design" kommt wieder, wird ne Weile brauchen!)

Virtuelles Window7 kann "bridged" nicht ins Intern

Hilfe bei Problemen mit der Installation und Benutzung des VMware Player.

Moderatoren: irix, stefan.becker, continuum, Dayworker, Tschoergez

Member
Beiträge: 2
Registriert: 30.03.2016, 22:32

Virtuelles Window7 kann "bridged" nicht ins Intern

Beitragvon Panther » 31.03.2016, 15:39

Hi zusammen,

vielleicht kann mir hier jemand weiterhelfen.

Ich habe schon einiges recherchiert, aber keine Lösung gefunden.

Szenario:
Host: Windows 7 Ultimate, 64-bit 6.1.7601, Service Pack 1
VMware Player 12.0.1 build-3160714
Gast: Microsoft Windows 7 Professional, Version 6.1.7601 Service Pack 1
im "Bridged"-Modus

Problem: Der Gast kann nicht ins Internet.
Bei der Analyse habe ich festgestellt, dass der Gast die ARP-Antwort des Gateways nicht bekommt, so wie der Gast auch scheinbar keine korrekte ARP-Antwort an das Gateway liefert.

Details:
Recherchiert mit tcpdump auf Gateway, Wireshark auf den zwei Windows-Systemen und zusätzlich auf einer 3. Maschiene (Work) im selben Subnetz.

Das Gateway hat zwei Netzwerkkarten,
-eine normal zum DSL-Router (SN1)
-eine mit Tagged VLAN zum hausinternen Netz

Nur zur Motivation des VLAN:
Das hausinterne Netz ist im wesentlichen zweigeteilt mit einem privaten Subnetz (SN2) für die familiären Rechner und einem eigenen Subnetz (SN3) für "Das Internet der Dinge" (TV, DVD, Sat.Receiver & Co)
Das Gateway bildet mit zwei VLAN-fähigen Switches das Rückrad des Netzwerkes

Die Netzstruktur aus Sicht von Host und Gast:
DSL-Router -----(SN1)----- Gateway -----(Tagged VLAN SN2)----- VLAN-Switch1 -----(Tagged VLAN SN2)---- VLAN-Switch 2 ----(SN2)----- Host -----(VM Bridge SN2)----- Gast

Der Gast hat eigentlich eine statische MAC, damit das Gateway die IP vergeben kann, das funktioniert nicht.
Deshalb hat der Gast in den Netzwerkverbindungen eine statische IPv4 eingestellt.

Zwei Varianten für Work getestet

In beiden Varianten:
Gast pingt Host: ARP ok, Host antwortet
Host pingt Gast: ARP ok, Gast antwortet
Gateway pingt Host: ARP ok, Host antwortet
Work pingt Host: ARP ok, Host antwortet
Gateway pingt Gast: ARP nicht ok, ARP-Cache zeigt "unvollständige IP"

Variante1: Work hängt an SN2-Port vom VLAN-Switch2
Work pingt Gast: kein ARP, keine Antwort

Variante2: Work und Host hängen an einfachem (unmanaged) Switch, der an SN2-Port vom VLAN-Switch2 hängt
Work pingt Gast: ARP nicht ok, ping-Ergebnis: HOST (nicht Gast oder Work) antwortet mit "...no route to..."

Sowohl die drei Switches als auch die VM-Bridge sollten doch für alle Pakete transparent sein und somit sollten alle ARP/ICMP/TCP-IP Pakete korrekt verarbeitet werden.

Wenn die VLAN-fähigen Switches Probleme mit ARP haben (davon habe ich bei meiner Recherche gelesen) und daraus entsprechende Probleme mit ICMP und TCP resultieren, ok, dass könnte ich mir noch mit einem Problem der VLAN-Switches erkären, aber warum das Problem mit Variante2 mit einem einfachen (kaskadierbaren) Switch?!?

Mit Hoffnung auf die rettende Idee
Gruß,
Panther

Benutzeravatar
King of the Hill
Beiträge: 12065
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 01.04.2016, 17:38

Boahh ist das kompliziert. Fang doch erstmal damit an, daß du im WS-Host im "Virtual Networ k Editor" aka "vmnetcfg.exe" deine beiden NICs manuell dem VMnet0 (Bridged) und einem ungenutzten VmnetX wie das VMnet2 zuweist. Dazu mußt du dieses ungeschickte Auto-Bridging/Detect rausnehmen, daß nur mit einer NIC problemlos funktioniert. Damit irgendetwas aufgrund einer MAC-Addy eine IP vergeben kann, klingt nach DHCP und das ist Murks, wenn man einem Fehler auf die Schliche kommen will.

Das WS-Manual ist je nach Version fehlerhaft im Bezug auf die VMware-Netzwerke. Da wird immer von Switch gesprochen, was aber nicht stimmt, da es stinknormale Hubs sind. Mit einer Intel-NIC werden beim Anlegen von VLANs meist einfach weitere Intel-NICs angelegt und du kannst nur hoffen, daß du diese per VMware-Bridging einem bestimmten VMnetX zuweisen kannst. Meines Wissens sieht VMware bei seinen Desktopprodukten keine VLAN-Nutzung vor, entweder kannst du das irgendwie im Host bewerkstelligen oder das wird vermutlich nichts.

Member
Beiträge: 2
Registriert: 30.03.2016, 22:32

Beitragvon Panther » 01.04.2016, 23:08

Danke Dayworker für deine Antwort.

Das Gateway hat zwei NIC, und auf einem NIC VLAN, nicht der Host.

Es sind insgesamt drei physische Rechner beteiligt.
1. Firewall/Gateway
2. Host
3. Work

Es sind vier logische Systeme beteiligt:
1. Firewall/Gateway
2. Host mit VMWare Player (Windows 7 Ultimate)
3. Gast als VM mit "Bridged"-Netzwerk im VMWare-Player auf dem Host (Windows 7 Professional)
4. Work (Windows 7 Professional)

Gesamtziel: Gast soll ins Internet können, Gast soll TCP-IP-Service anbieten, Work soll diesen Service nutzen können.

Erster Schritt: Gast und Work sollen über ICMP/TCP-IP kommunizieren können, ohne "Managed"-Switche dazwischen. Nur im "Bridged"-Modus kann der Gast einen Service im lokalen Netz anbieten und deshalb soll er "Bridged" angebunden werden.

Der Host hat zwar auch mehrere NIC, aber der entscheidende ist ein
Intel(R) PRO/1000 GT-Desktopadapter, der korrekt per DHCP vom Gateway mit einer IP versorgt wird.
Das Gateway soll auch für den Gast die IP-Adresse liefern, deshalb hat der Gast eine feste MAC. Das funktioniert aber möglicherweise nicht wegen den "managed" Switches dazwischen. Deshalb hat der Gast im Windows auch die IP fest eingestellt.
Um das Problem zu isolieren habe ich Host und Work über einen unmanaged Switch verbunden:

Problem: auch wenn sie nur über einen unmanaged Switch verbunden sind, kann Work nicht korrekt mit dem Gast kommunizieren (ICMP/TCP-IP) da offensichtlich die ARP-Response vom Gast Work nicht erreicht...
Das seltsame: Warum liefert Host die Antwort (deutet m.E. auf Routing hin), und nicht Work.

Werde morgen nochmal die Teststruktur aufbauen und per "V Network Editor" prüfen, welche NICs erkannt werden (Mainboard-NIC Realtek ist ungenutzt), und wie sie den Netzwerken zugeordnet sind.

Experte
Beiträge: 1794
Registriert: 23.02.2012, 12:26

Beitragvon ~thc » 02.04.2016, 10:43

@Panther

Eine MAC ist die "Hardware"-Adresse einer Netzwerkkarte und per Definition statisch. Man kann zwar die MAC einer VM nachträglich ändern oder auch die MAC einer physischen Netzwerkkarte "überschreiben" - aber das ist nur in Sonderfällen notwendig. Ich verstehe nicht, warum du immer von einer "festen MAC" redest, als ob dies etwas Besonderes sein.

Versuch das Problem einzugrenzen, statt ausufernde Erklärungsmodelle zu erarbeiten.

Setze "Work" und "Host" mit festen IPs an einen isolierten, einfachen Switch und teste, ob die Kommunikation mit dem Gast funktioniert,

Benutzeravatar
King of the Hill
Beiträge: 12065
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Beitragvon Dayworker » 02.04.2016, 18:42

Da du ja auf der MAC so rumreitest, hast du ja hoffentlich den KB-Eintrag Changing the MAC address of a hosted virtual machine (507) beherzigt und der VM wirklich eine statische VMware-MAC vergeben.

VMware schaltet für seine VMware-Bridge die Host-Nic in den Promiscuous-Mode sprich Hub und flanscht daran alle seine VMnetX an. Problematisch sind einige Intel-NICs, da sich diese nicht richtig in den Promiscuous-Mode versetzen liessen. Da ich selber eine Intel PRO 1000GT im Einsatz hatte und damit bei Bridge keine Probleme hatte, würde ich Probleme von der Seite erstmal ausschliessen, allerdings habe ich mich mit VLAN damals nicht beschäftigt. Prinzipiell muß an irgendeiner Stelle in deinem Konstrukt irgendwer wissen, welche weiteren Netzwerkteilnehmer es gibt. Bei mir ist es der Router und bei dir wohl Firewall/Gateway.
VMware-Bridge funktioniert nur dann richtig, wenn Host, Gast und alle anderen Netzwerker im selben IP-Bereich unterwegs sind. Etwaige Sec-Suiten, Zusatzfirewalls etc können jedoch für einige schwer zu lokalisierende Probleme sorgen. Von daher würde ich die Host-NIC fest an das VMnet0 binden, Auto-Bridging vorher in "vmnetcfg.exe" aka "VMware Network Editor" nicht vergessen abzuschalten, Host und Gast mit festen IPs ausstatten und dann mit deinem Work den Zugriff testen. Wenn es nicht klappt, stellt dir dein Firewall/Gateway ein Bein.


Zurück zu „VMware Player“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 1 Gast