Mal was nettes für Experten.

Folgende Situation:

Auf einigen XP-Clients ist VMWare installiert, dementsprechend haben sie ein virtuelles LAN-Interface mit einer zugewiesenen IP-Adresse aus einem privaten Netz für das Host-Only Netz. (Problem tritt auch bei allen andere virtuellen Interfaces auf, also ist VMWare unschuldig). Nennen wir das Virtuelle Interface "Lan B".

Lan A ist ein physikalisch vorhandenes Interface, welches an ein grosses Netzwerk inkl. Domäne angeschlossen ist. der IP-Bereich ist ein anderer als der des virtuellen Netzes. Jegliche Bridging Funktionalitäten (vmWare und Windows) sind deaktiviert

Aus ungeklärtem Grunde senden diese Clients jetzt NTP-Anfragen mit der IP-Adresse des virtuellen Interfaces und der MAC des physikalischen Interfaces in das physikalisch vorhandene Netz zum konfigurierten TimeServer. Dieser antwortet ordnungsgemäß an die IP-Adresse des virtuellen Netzes, welche natürlich nicht erreichbar ist, und daher im Router auftaucht. Da so ziemlich alle privaten IP-Netze bei uns auch eine ISDN-Route haben öffnet die Antwort diese ISDN-Route. Dies ist unerwünscht (teuer).

Ich vermute einen Fehler im w32time oder dem Microsoft TCP/IP Stack (unsaubere Trennung verschiedener Interfaces), daher poste ich das ganze hier.

Kennt jemand das Problem? Gibt es eine Lösung? Denkbar wäre IMO z.B. den W32time Dienst an ein Interface zu binden, oder die Antwort des Zeitservers (DC) an IP Adressen aus fremden Netzen zu unterbinden, Leider fand google zu keiner der beiden Möglichkeiten einen Vorschlag.

Jemand eine Idee die nicht einen der Sätze "Virtuelle Netzwerkinterfaces löschen" oder "w32time abschalten" beinhaltet?

Wäre es nicht das einfachste die NAT-Funktionalität von VMware zu aktivieren ??

Wie ich schon sagte: Das einzige aktive Netz ist das Host-Only. Jegliches Bridging ist deaktiviert (VMWare Bridge Protocol ist auf allen Interfaces deaktiviert), NAT ist ebenfalls deaktiviert, sowohl in der VMWare config als auch das Interface auf dem Host. Das Problem entsteht direkt auf dem Host, der ja zwei IP-Adressen hat, auch wenn keinerlei virtuelle Maschinen laufen.

Es lies sich auch mit anderen virtuellen Interfaces (z.B. VPN, Microsoft Loopback Adapter) nachvollziehen, dass solche Fehler auftauchen sobald der Rechner mehre Interfaces mit einer IP Adresse besitzt.

Kann jeder leicht mit einem Microsoft Loopbackadapter und Etherreal in dieser Form reproduzieren.

Ich glaube, jetzt verstehe ich, worauf du hinaus willst.

Hilft das hier ?

http://vmware.itst.org/viewtopic.php?p=3578

Hallo!

Mein Ansatz wäre folgender: den Router so konfigurieren, dass er die NTP Antworten an die Clients schickt (Phys. vorhandenes IF) und dort dann Routing zu den VMs aktivieren. Damit bekommen die VMs Ihre korrekte Zeit und die Pakete laufen nicht über die ISDN Leitung oder?

Leider hilft das beides nicht. Das Problem hat NICHTS mit den virtuellen Maschinen zu tun. Deren Zeit ist mir ziemlich egal. Die brauchen nicht mal laufen damit der Fehler auftritt. Es ist ein Problem jeglichen WindowsXP-Rechners mit mehr als einem Interface welches eine IP-Adresse hat.

Selbst ein Testclient (Hardware, Windows XP) ohne VMWare, der einen Loopback Adapter mit einer IP eines anderen Netzes besitzt, produziert auf seinem physikalischen Interface derartige Pakete (Mac Adresse des physikalischen Interfaces, IP des Loopbackadapters, ntp Anfrage) sobald der Zeitgeber konfiguriert und aktiviert wird.

Windows halt

SCNR

Dann wirst du wohl nicht drumrum kommen an irgendeiner Stelle zu filtern...

Genau danach fragte ich ja... Am liebsten wäre mir auf dem Client den w32time an ein Interface zu binden. (Ohne Flame-Wars auslösen zu wollen, aber unter Linux kann man so ziemlich jede Anwendung auf ein Interface binden, sowas muss es doch unter Win auch geben)

Zur Not wäre es akzeptabel auf dem Timeserver die Antwort auf alle IP-Kreise ausser einem zu deaktivieren... gibts sowas?

Die einfachste möglichkeit Packete zu filtern wäre eine Desktopfirewall auf den betreffenden Clients zu installieren (die WinXP SP2 Firewall nützt nix, denn die filtert keinen ausgehenden Datenverkehr) mit boardmitteln fällt mir hierfür keine Lösung ein...

Windows halt;)