Ich habe einen Windows 8.1-Host, auf dem ich Ubuntu Server 15.05 in einer virtuellen Maschine installiert habe. Ich richte einen SSH-Server im Gast (Ubuntu) ein und erstelle dann eine Weiterleitungsregel vom Host-Port 2222 zum Gast-Port 22.
Wenn ich versuche, vom Host aus eine SSH-Verbindung herzustellen, ssh -p 2222 username@localhostkann ich problemlos eine Verbindung zur VM herstellen.
Wenn ich versuche, von einem Remote-Rechner (einem OS X-Rechner) im selben lokalen Netzwerk eine Verbindung herzustellen, erhalte ich in den meisten Fällen einen Timeout-Fehler. Wenn ich es tatsächlich schaffe, eine Verbindung herzustellen, friert sie nach einiger Zeit ein, bis ich den Fehler erhaltessh -p 2222 [email protected]Schreiben fehlgeschlagen: Rohr defekt.
Ich habe die Firewall meines Antivirenprogramms (Bitdefender) deaktiviert und in der Windows-Firewall Regeln erstellt, um Datenverkehr von den Ports 22 und 2222 zuzulassen. Das Problem besteht weiterhin, auch nachdem ich beide Firewalls deaktiviert habe (tatsächlich ist die von Bitdefender immer deaktiviert).
Ich habe es auch UseDNS noin der Datei des Gastes eingestellt sshd_config. Im Gast (Ubuntu) ist keine Firewall installiert.
Ich sehe, dass das Problem sowohl bei VMware Workstation 11 als auch bei VirtuaBox auftritt.
Antwort1
Das Problem scheint zu sein, dass das VM-Netzwerk von außerhalb der Windows 8.1-Maschine nicht erreichbar ist. Sie können sehen, dass es funktioniert, wenn Sie per SSH auf localhost:2222 zugreifen. Dies kann an der Netzwerkkonfiguration liegen (wahrscheinlich ist es als NAT konfiguriert, die Standardeinstellung).
Wenn Sie VirtualBox verwenden, sollten Sie das Netzwerk der zu überbrückenden VM konfigurieren, dann sollte das funktionieren. Weitere Informationen erhalten Sie unterhttps://superuser.com/questions/810097/vmware-player-bridged-networking-no-longer-works-host-win8-1-guest-mint-17-l
Antwort2
Ich hatte ein ähnliches Problem auf einem Windows 7-Host mit WMware Workstation 12.5.9. Die einzige Lösung, die mir wirklich geholfen hat: https://communities.vmware.com/thread/590825
Das Setzen alternativer QoS-Flags scheint das Problem zu umgehen, z. B.ssh -o IPQoS=throughput ...