Tatsächlich gibt es eine ganze Reihe guter Gründe, NAT für Ihre VMs zu verwenden, anstatt für eine überbrückte Schnittstelle. (Dies ist eine alte Frage, aber als erstes Ergebnis stellte sich die Frage, wie dies zu tun ist und wie ich von VirtualBox migriere es die ganze Zeit, also dachte ich, es lohnt sich hinzuzufügen)
Nur einige Gründe, NAT zu verwenden, sind:
- Es ist einfach und portabel
- Wenn Sie sich in einem Kunden-LAN befinden, das eine bekannte MAC-Adresse benötigt, um eine IP zu erhalten (andernfalls müssen Sie versuchen, nicht verwendete zu erraten und einen Konflikt zu riskieren, und im Allgemeinen schlechte Aufmerksamkeit auf sich ziehen :)),
- Dinge wie das Zulassen, dass Ihre VMs einen einzelnen Proxy-Server auf Ihrem Host verwenden (IE, wenn Sie nicht das Netzwerk steuern, in dem Sie sich befinden), oder das Filtern des Broadcast-Verkehrs (Windows usw.) auf dem Weg nach draußen in einem günstiger Ort.
- in der Lage zu sein, ihnen eine feste oder reservierte IP zuzuweisen, so dass Sie von außerhalb des Hosts nach Namen / IP suchen können (auch hier, wenn Sie mit einer überbrückten Schnittstelle keine Reservierungen im Netzwerk erhalten können)
- Vor allem aber können Sie sich hinter einer einzigen Firewall - Konfiguration auf Ihrem Host verstecken und Dinge auf eine geschütztere Weise zwischen Ihnen / ihnen austauschen, anstatt jede VM der Natur auszusetzen und sie alle einzeln schützen zu müssen usw .. Genau wie bei einem Internetmodem / Router
Für meinen Fall (VMWare Workstation 10, Linux-Host, OS X-Gast) und jeden, der darauf stößt, ist dies die Übersicht darüber, was für mich funktioniert hat. Neben dem Waffeln und Was-wäre-wenn gibt es eigentlich nur 3 Hauptschritte.
- Zunächst müssen Sie also entscheiden, was Sie Ihrer VM / Ihrem Gast von "außerhalb" Ihres Hosts erlauben möchten (beachten Sie, dass Sie dies wie unten beschrieben problemlos vom Host selbst erreichen können). Eine sichere Möglichkeit wäre, nur SSH (Port 22) für Computer in Ihrem Subnetz verfügbar zu machen / zuzulassen. Sie können auch Port 80/443 zulassen, wenn Sie einen Webserver auf der VM usw. haben, und Sie können auch einen "Tunnel" verwenden, um mit SSH auf andere Dienste zuzugreifen (siehe Beispiel unten), und FUSE / SSHFS verwenden, um Ihrem Host zuzuweisen Dateisystemzugriff. (Oder die Funktion für freigegebene Ordner unter VMWare, die ich jedoch noch nicht verwendet habe.)
Die Idee ist also wie folgt: "Erlaube Dingen im lokalen Netzwerk meines Hosts (z. B. 10.1.1.0/24 oder 192.168.1.0/24), eine Verbindung zu Port 22222 auf dem Host herzustellen, die wir an Port 22 von a weiterleiten bestimmter Gast ". Natürlich muss es sich um einen bestimmten Gast handeln (dies macht es umso nützlicher, Ihre IPs konfigurieren zu können und Sie können sie alle an einem Ort ändern, ohne jede VM zu öffnen), genauso wie dies über Ihren Internet-Router geschieht, um Spielesachen zuzulassen durch usw.
Sobald dies erledigt ist, können Sie sich auf Ihrem Laptop oder einem anderen Computer im LAN befinden, auf Ihre Workstation (VMware-Host) auf 22222 ssh und Sie werden an den Gast verwiesen, an den Sie weitergeleitet werden sollen. Wie oben erwähnt, können Sie, wenn Sie auch sagen, dass Sie in der Lage sein möchten, eine Verbindung zu einem Postgres-Server auf dem Gast (oder einem vnc-Server, der oft unverschlüsselt ist) herzustellen, denselben Befehl tunneln (anstatt ihn auch zur dhcp conf hinzuzufügen). Zum Beispiel
console ~> ssh root@hostip -p 22222 -L 54320:localhost:5432
und Sie würden über die IP-Weiterleitung in VMware an den Gast weitergeleitet und könnten Ihr pgadmin3-Tool auf localhost verweisen: 54320 (nicht privilegiert) auf Ihrem Laptop, und Ihr Datenverkehr im Netzwerk würde verschlüsselt. (Hinweis 'localhost' wird dort bereits an den Gast weitergeleitet)
Anmerkungen
- Es gibt alle möglichen Möglichkeiten, dies zu tun. Zum einen könnten Sie einfach einen Tunnel zum Host erstellen und die IP des Gasts in -L angeben, und es würde "ausbrechen" und Sie dorthin verweisen, aber die Option nat.conf ist nett und praktisch, und Sie müssen es nicht jedes Mal eingeben. Es gibt auch andere Möglichkeiten der Portweiterleitung
- Ich hatte in ein paar Threads einer virtuellen Netzwerk-Benutzeroberfläche einen Verweis darauf gesehen, um dies zu tun (wie dies bei virtualbox der Fall ist), aber ich konnte ihn in dieser Version nicht finden
- Ich verwende kein Windows. Obwohl ich davon ausgehe, dass die Konfiguration als Host sehr ähnlich ist, bin ich mir nicht sicher. Die NAT-Konfigurationen sollten jedoch für jeden VMware-Gast funktionieren (obwohl ich keine anderen Versionen von VMWare verwendet habe).
VMware richtet eine Route ein, damit der Host den NAT-Gast direkt kontaktieren kann, IE von der Host-Konsole, ich kann den NAT-Gast 192.168.198.10 (wie oben definiert) direkt pingen / ssh usw.
console ~> route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
<snip>
192.168.198.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet8
192.168.233.0 0.0.0.0 255.255.255.0 U 0 0 0 vmnet1
- Aus einer Linux-Notiz geht hervor, dass mit systemd init einiges an VMware herumgespielt wird, um automatisch zu starten, und außerdem habe ich festgestellt, dass ich VMware nicht einfach neu starten kann (VMCI wird nicht erneut geladen) und neu starten muss mein Rechner macht das NAT / DHCP-Zeug über Stick, aber vielleicht hast du das Problem nicht. Es gibt jedoch einige Threads mit systemd-Lösungen