Sehr geehrte Damen und Herren,
seit einigen Tage nutze ich VMware Workstation (15.5.6 build-16341506) auf meinem PC (windows 10 x64, 32 GB Ram, 16 Kerne)
und habe in meiner virtuellen Umgebung Kali Linux (Debian 10 x64) aus beruflichen Gründen laufen, welches über das VMware NAT an
das lokale Lan angebunden ist.
Leider fällt immer nach einiger Zeit die Netzwerkfunktionalität bei einiger Auslastung (z.B. div. Portscans) flach und auch einfache Pings funktionieren nicht mehr.
Wenn ich den VMware Nat Dienst neustarte geht es wieder einige Zeit. Von daher vermute ich, dass der Fehler irgendetwas mit Timeouts oder einer vollen NAT-Tabelle zu tun hat. Wie kann ich das troubleshooten ? Gibt es irgendwelche Logs ? Kann ich Timeouts anpassen oder die NAT Tabelle manuell erweitern ? Oder liegt der Fehler vlt irgendwo ganz anders ?
Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
Probleme mit NAT
-
- King of the Hill
- Beiträge: 13652
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Re: Probleme mit NAT
Die häufigsten Probleme sind:
Die Punkte 1 und 2 kannst du in der WS ganz einfach über den VMware-Netzwerk-Editor (vmnetcfg.exe) einstellen, sollte auch in der aktuelle Version einen eigenen Win-Startmenueintrag haben und in der WS gibt es auch einen Menupunkt zu den Netzwerkeinstellungen. Die voreingestellten VMnet0 (Bridge), VMnet1 (Host-only) und VMnet8 (VMware-NAT) würde ich nicht bzw ggf (VMnet1 und VMnet8) nur den genutzten IP-Bereich ändern. Die erste und für die Funktion des VMware-Netzwerks wichtigste NIC weist man manuell dem VMnet0 und alle weiteren NIC entsprechend einem noch unbenutzen VMnetX zwischen 2 bis 7 und 9 bis je nach WS-Version fast unbegrenzt zu. Es besteht also inzwischen kein Grund mehr, die voreingestellten VMnetX zu verstellen. Hintergrund ist, daß in der VMware-Welt beim Sprechen über "Host-only" und "VMware-NAT" immer von den dafür voreingestellten VMnetX ausgegangen wird.
Die erste NIC ist deshalb so wichtig, weil es in der WS keine feste Reihenfolge der NICs gibt. Landet eine NIC im Offline-Zustand auf dem VMnet0, stottert die ganze VMware-Netzwerkumgebung. Deshalb überläßt man VMware bei mehr als einer NIC im Host nicht mehr die Zuweisung zu den VMnetX.
Bei mehr als einer NIC im Host gibt es eine zusätzliche Besonderheit und zwar wenn die VMware-Bridge (VMnet0) eingesetzt werden soll. In diesem Fall weist man allen VMs gleich das Custom-Interface zu und kann dann im sich darunter öffnenden Menu das gewünschte VMnetX auswählen. Andernfalls könnte eine VM im falschen Subnetz arbeiten.
- 2 oder mehr NICs im Host/Wirt stecken und nur 1 ist mit einem Router verbunden
- bei 2 oder mehr NICs überläßt man VMware trotzdem das Auto-Bridging zu übernehmen
- in Sec-Suite/Antivirus wurden keine Ausnahmen sowohl für den VMware-Programmeordner als auch VMDK-Dateien angelegt
Die Punkte 1 und 2 kannst du in der WS ganz einfach über den VMware-Netzwerk-Editor (vmnetcfg.exe) einstellen, sollte auch in der aktuelle Version einen eigenen Win-Startmenueintrag haben und in der WS gibt es auch einen Menupunkt zu den Netzwerkeinstellungen. Die voreingestellten VMnet0 (Bridge), VMnet1 (Host-only) und VMnet8 (VMware-NAT) würde ich nicht bzw ggf (VMnet1 und VMnet8) nur den genutzten IP-Bereich ändern. Die erste und für die Funktion des VMware-Netzwerks wichtigste NIC weist man manuell dem VMnet0 und alle weiteren NIC entsprechend einem noch unbenutzen VMnetX zwischen 2 bis 7 und 9 bis je nach WS-Version fast unbegrenzt zu. Es besteht also inzwischen kein Grund mehr, die voreingestellten VMnetX zu verstellen. Hintergrund ist, daß in der VMware-Welt beim Sprechen über "Host-only" und "VMware-NAT" immer von den dafür voreingestellten VMnetX ausgegangen wird.
Die erste NIC ist deshalb so wichtig, weil es in der WS keine feste Reihenfolge der NICs gibt. Landet eine NIC im Offline-Zustand auf dem VMnet0, stottert die ganze VMware-Netzwerkumgebung. Deshalb überläßt man VMware bei mehr als einer NIC im Host nicht mehr die Zuweisung zu den VMnetX.
Bei mehr als einer NIC im Host gibt es eine zusätzliche Besonderheit und zwar wenn die VMware-Bridge (VMnet0) eingesetzt werden soll. In diesem Fall weist man allen VMs gleich das Custom-Interface zu und kann dann im sich darunter öffnenden Menu das gewünschte VMnetX auswählen. Andernfalls könnte eine VM im falschen Subnetz arbeiten.
Re: Probleme mit NAT
Die Portscans von nmap haben unter Umständen ein aggressives Timing (Pakete/s) und wenn zusätzlich der zu scannende Bereich (Anzahl der Hosts) nicht klein ist, dann können locker mehrere Tausend "Verbindungen" entstehen, die der arme NAT-Dienst der Workstation alle im Speicher halten soll.
Keine wirklich gute Idee.
Keine wirklich gute Idee.
Re: Probleme mit NAT
hilmbert hat geschrieben:Sehr geehrte Damen und Herren,
seit einigen Tage nutze ich VMware Workstation (15.5.6 build-16341506) auf meinem PC (windows 10 x64, 32 GB Ram, 16 Kerne)
und habe in meiner virtuellen Umgebung Kali Linux (Debian 10 x64) aus beruflichen Gründen laufen, welches über das VMware NAT an
das lokale Lan angebunden ist.
Leider fällt immer nach einiger Zeit die Netzwerkfunktionalität bei einiger Auslastung (z.B. div. Portscans) flach und auch einfache Pings funktionieren nicht mehr.
Wenn ich den VMware Nat Dienst neustarte geht es wieder einige Zeit. Von daher vermute ich, dass der Fehler irgendetwas mit Timeouts oder einer vollen NAT-Tabelle zu tun hat. Wie kann ich das troubleshooten ? Gibt es irgendwelche Logs ? Kann ich Timeouts anpassen oder die NAT Tabelle manuell erweitern ? Oder liegt der Fehler vlt irgendwo ganz anders ?
Hallo,
warum überhaupt NAT?
Kali genatted in einem Netzwerk für bei uns, sofern nicht abgesprochen, für mächtig Ärger sorgen.
Gruß
Zurück zu „VMware Workstation und VMware Workstation Pro“
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 6 Gäste