Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Einführung
2 Virtuelle Maschinen im Unternehmen
3 Virtualisierungssoftware – eine Marktübersicht
4 Auswahl der möglichen virtuellen Maschine
5 Auswahl der richtigen Virtualisierungssoftware
6 Auswahl der richtigen physikalischen Infrastruktur
7 Installation und Update des Wirt-Systems
8 Verwaltung der Virtualisierungssoftware
9 Virtuelle Netzwerke
10 Virtuelle Festplatten
11 Erstellung einer virtuellen Maschine
12 Verwaltung der virtuellen Maschinen
13 VMware VirtualCenter
14 Skriptierung und Programmierung unter VMware und MS Virtual Server
15 Backup, Restore und Disaster Recovery
16 Templates (VM-Vorlagen)
17 Zusatzsoftware
18 Nützliche Adressen im Web
A Clustereinrichtung und Beispielumgebungen
B Kommandozeile und wichtige Dateien
C Häufige Fragen
Stichwort

Jetzt Buch bestellen
Ihre Meinung?

Spacer
<< zurück
VMware und Microsoft Virtual Server von Dennis Zimmer
Virtuelle Server im professionellen Einsatz
Buch: VMware und Microsoft Virtual Server

VMware und Microsoft Virtual Server
geb., mit CD
612 S., 49,90 Euro
Rheinwerk Computing
ISBN 978-3-89842-701-2
Pfeil 9 Virtuelle Netzwerke
Pfeil 9.1 Allgemeines
Pfeil 9.1.1 Adapter Teaming, Fault Tolerance, Load Balancing
Pfeil 9.1.2 Geswitchtes Netzwerk
Pfeil 9.1.3 Dedizierte LAN-Kopplung
Pfeil 9.1.4 VLAN (virtual Local Area Network)
Pfeil 9.1.5 NAT (Network Address Translation)
Pfeil 9.2 VMware GSX
Pfeil 9.2.1 Interner DHCP-Server
Pfeil 9.2.2 Host-Only
Pfeil 9.2.3 Bridged
Pfeil 9.2.4 NAT
Pfeil 9.3 Microsoft Virtual Server
Pfeil 9.3.1 Interner DHCP-Server
Pfeil 9.3.2 Host-Only
Pfeil 9.3.3 Virtual Networking
Pfeil 9.3.4 NAT
Pfeil 9.4 VMware ESX
Pfeil 9.4.1 Host-Only
Pfeil 9.4.2 Virtual Switch
Pfeil 9.4.3 VLAN


Rheinwerk Computing - Zum Seitenanfang

9.2 VMware GSX Zur nächsten ÜberschriftZur vorigen Überschrift

VMware GSX stellt Ihnen drei virtuelle Netzwerktechniken zur Verfügung, namentlich Host-Only, bridged und NAT. Bei einer Standardinstallation sind die drei Netzwerke auch schon installiert und konfiguriert. Zusätzlich können Sie dann noch bis zu sieben weitere Netzwerke anlegen, sodass insgesamt zehn eingerichtet werden können. Allerdings kann das erste virtuelle Netzwerk nur für ein bridged Network und nicht für Host-Only oder NAT verwendet werden. Diese Netzwerke kann man mit Netzwerkswitches vergleichen, da sich alle virtuellen Maschinen innerhalb des gleichen virtuellen Netzwerks sehen. Wenn eine virtuelle Maschine in mehreren virtuellen Netzwerken verfügbar sein soll, müssen Sie in dieser Maschine mehrere Netzwerkkarten in den entsprechenden virtuellen Netzwerken »einbauen« oder eine virtuelle Maschine oder das Wirt-System so einrichten, dass sie als Router zwischen den Netzen fungieren. Daher werden diese virtuellen Netzwerke auch »virtual Switch« genannt.

Den virtuellen Maschinen werden virtuelle Netzwerke zugeordnet, indem eine Netzwerkkarte hinzugefügt wird, die für das entsprechende Netzwerk konfiguriert ist. In Abbildung 9.2 ist dieser Vorgang zu sehen. Unter dem Auswahlpunkt Custom findet man alle verfügbaren virtuellen Netzwerke, während die drei Auswahlpunkte darüber direkt auf die durch VMware GSX selbst installierten Netzwerke zeigen. Alle virtuellen Netzwerke, die Sie sich selbst anlegen, müssen Sie über Custom auswählen.

Abbildung 9.2 Zuordnung virtuelle Maschine – virtuelles Netzwerk

Da es sich hier um keine physikalischen Geräte handelt, können Sie jederzeit, also auch im laufenden Betrieb, das der Netzwerkkarte zugeordnete Netzwerk verändern oder deaktivieren, indem Sie das Häkchen im Feld Connected herausnehmen.

Seit einiger Zeit haben Sie auch die Wahl zwischen unterschiedlichen Netzwerktreibern innerhalb der virtuellen Maschine: vlance und vmxnet. Während vlance den AMD PCNet32 10MBit-Adapter emuliert und daher von fast jedem Betriebssystem ohne gesonderten Treiber unterstützt wird, ist vmxnet ein proprietärer 32Bit-Adapter von VMware, dessen Treiber durch die VMware Tools installiert werden. Obwohl der Vlance-Treiber als 10 MBit-Netzwerkkarte vom Betriebssystem erkannt wird, leistet er deutlich mehr, also lassen Sie sich nicht täuschen. Dennoch empfiehlt es sich, wann immer möglich den Vmxnet-Adapter zu benutzen, da dieser in Bezug auf Geschwindigkeit und Prozessorlast optimiert ist.


TIPP
Installieren Sie das Gast-System mit dem Vlance-Adapter und schalten Sie nach der Installation der VMware Tools auf den Vmxnet-Treiber um. Während Sie den Status der Netzwerkkarte und deren Netzwerkverbindung innerhalb der VM selbst im laufenden Betrieb ändern können, muss die VM für das Ändern des Adaptertyps jedoch ausgeschaltet werden.


Rheinwerk Computing - Zum Seitenanfang

9.2.1 Interner DHCP-Server Zur nächsten ÜberschriftZur vorigen Überschrift

Nach der Installation des VMware GSX Servers steht Ihnen ein interner virtueller DHCP-Server zur Verfügung, der den virtuellen Maschinen bei Verwendung von Host-Only- und NAT-Netzwerken dynamische IP-Adressen zuweist. Die zu verwendenden Adressbereiche können Sie über die Funktion virtual Network Settings auf dem VMware GSX Server abändern. Erreichen können Sie diese über das Startmenü • VMware • VMware GSX Server • Manage Virtual Networks oder über die Virtual Machine Console im Host-Abschnitt (Abbildung 9.2). Dort müssen Sie dann auf den Reiter DHCP wechseln.

Abbildung 9.3 Einrichtung des internen DHCP-Servers unter VMware GSX

Hier können Sie vorhandene virtuelle Netzwerke über Properties anpassen oder über Remove löschen. Denken Sie immer daran, die Änderungen direkt zu übernehmen, da Sie sonst keine aktuelle Anzeige erhalten. Falls Sie neue Netzwerke hinzugefügt haben, die Sie mit DHCP versorgen möchten, können Sie über den Add New das entsprechende virtuelle Netzwerk auswählen und dann über Properties den IP-Bereich zuweisen.

Sollte der DHCP-Server mal Probleme bereiten, oder sollten Sie ihn abschalten wollen, können Sie den DHCP-Dienst von dieser Verwaltungsanzeige aus steuern. Übrigens können Sie diesen DHCP-Dienst auch über die normale »Microsoft Windows Dienste Verwaltung« steuern, die unter dem Namen VMware DHCP-Service zu finden ist.

Die Konfiguration des DHCP-Servers ist in den folgenden Dateien auf der Festplatte abgelegt, die Sie im VMware GSX-Konfigurationsverzeichnis (unter Windows: C:\Dokumente und Einstellungen\All Users\Anwendungsdaten\VMware) des Servers finden:

  • vmnetdhcp.conf: komplette Konfiguration des DHCP-Servers
  • vmnetdhcp.leases: die Gültigkeit der DHCP-Clientadressen

Rheinwerk Computing - Zum Seitenanfang

9.2.2 Host-Only Zur nächsten ÜberschriftZur vorigen Überschrift

Dieses Netzwerk stellt Ihnen nur Netzwerkverbindungen innerhalb der virtuellen Umgebung zur Verfügung, d. h., alle virtuellen Maschinen, die einen solchen Adapter ihr Eigen nennen und das Wirt-System selbst können untereinander kommunizieren. Diese Netzwerkart wird häufig auch für Heartbeat-Netze bei geclusterten virtuellen Maschinen verwendet. Problematisch ist logischerweise die mangelnde Flexibilität, was das Verschieben einer virtuellen Maschine auf ein anderes Wirt-System angeht, da sich diese dann in einem »neuen« Host-Only-Netzwerk befindet. Bei geclusterten virtuellen Maschinen bedeutet diese Einschränkung, dass beide VMs auf dem gleichen Wirt-System laufen müssen, um sich gegenseitig über das Host-Only-Netzwerk finden zu können.

VMware GSX installiert Ihnen standardmäßig einen virtuellen Netzwerkadapter, der unter dem Namen VMnet1 in der Liste der Netzwerkkarten des Wirt-Systems erscheint. Innerhalb dieses Netzwerkes läuft im Normalfall auch schon ein interner DHCP-Server, den Sie bei Bedarf manuell abschalten müssen.

Da eine virtuelle Netzwerkkarte im Wirt-System existiert, haben Sie durch Anschalten der Routingfunktion am Wirt-System und entsprechende Routingeinträge die Möglichkeit, Host-Only-Netze in die physikalische Welt zu routen. Dadurch tun sich natürlich schöne Möglichkeiten zum Aufbau eines eigenen virtuellen Adressbereichs mit Kontakt zur Außenwelt auf. Solche Konstellationen sind häufig in Testumgebungen zu finden.

Um eine neues Host-Only-Netzwerk anzulegen, müssen Sie in den Virtual Network Editor wechseln und unter Host Virtual Adapter (Abbildung 9.3) Add new Adapter auswählen.

Abbildung 9.4 Neues virtuelles Netzwerk anlegen

Jetzt erscheint ein Auswahlmenü, in dem Sie eines der noch verfügbaren Netzwerke auswählen können. Dieses wird nun in die Liste der Netzwerkkarten mit aufgenommen und steht Ihnen alsdann zur Verfügung. Wichtig hierbei ist, dass dieses Netzwerk auf Status Enabled steht. Sobald dies der Fall ist, finden Sie dieses Netzwerk im Reiter Host Virtual Network mapping, wo Sie den Netzwerkadressbereich anpassen können.

Wie Sie sicher auch Abbildung 9.4 sehen, existiert hinter jedem virtuellen Netzwerknamen ein Auswahlfeld für den zu verwendenden Adapter und ganz rechts ein Knopf mit drei Punkten. Über diesen Knopf können Sie in alle derzeit verfügbaren Konfigurationen des virtuellen Adapters springen. Im Falle eines Host-Only-Adapters gäbe es eine Auswahl Subnet, in der Sie die Netzwerkadresse festlegen, und eine Auswahl DHCP, falls Sie diesen für das interne Netzwerk aktiviert haben.

Abbildung 9.5 Anzeige und Konfiguration aller verfügbaren virtuellen Netzwerke

Alle hier zu sehenden Netzwerke können Sie als virtuelle Netzwerkadapter auf Ihrem Wirt-System wiederfinden. Unter Windows können Sie das im Startmenü unter Einstellungen • Netzwerkverbindungen oder mit dem Kommandozeilenbefehl ipconfig einsehen, unter Linux mit dem Befehl ifconfig.


Rheinwerk Computing - Zum Seitenanfang

9.2.3 Bridged Zur nächsten ÜberschriftZur vorigen Überschrift

Kommen wir nun zu dem am häufigsten genutzten virtuellen Netzwerk, dem bridged Network. Hier werden alle Pakete des Gast-Systems direkt auf die physikalische Netzwerkkarte des Wirt-Systems durchgereicht. Die virtuelle Maschine wird daher aus dem physikalischen LAN wie jedes andere Gerät mit einer eigenen MAC-Adresse und einer eigenen IP-Adresse wahrgenommen. Der interne VMware DHCP-Server kann diese Art von Netzwerk nicht mehr bedienen, daher müssen Sie entweder eine feste IP-Adresse vergeben, oder es muss dies ein DHCP-Server Ihres realen Netzwerkes übernehmen. Bis auf die Virtualisierung ist somit ein bridged Network nicht von einem realen Netzwerkadapter zu unterscheiden. Daher ist die virtuelle Maschine durch das reale Netzwerk auch uneingeschränkt erreichbar. Durch die Emulation der Hardware des VMware GSX Servers, ist dieses virtuelle Netzwerk protokollunabhängig und kann daher auch für Protokolle wie IPX/SPX verwendet werden.

Sie können soviele bridged Networks einrichten, wie Sie physikalische Netzwerke haben bzw. bis Sie die maximale Anzahl virtueller Netzwerke erreichen. Nach der Installation des VMware GSX Servers steht Ihnen direkt schon ein bridged Network zur Verfügung, das den Namen »VMnet0« trägt.

Zum Einrichten neuer Netzwerke können Sie sich einfach ein freies virtuelles Netzwerk (Abbildung 9.5) suchen und in der Liste die entsprechende physikalische Netzwerkkarte auswählen.

Abbildung 9.6 Konfiguration des Bridged Networks

Bei der Auswahl der Netzwerkkarte, über die das Bridge-Protokoll verwendet werden soll, steht Ihnen zu den physikalischen Karten der Punkt Bridged to an automatically chosen adapter zur Verfügung. Falls Sie diesen auswählen, sucht sich VMware GSX automatisch eine physikalische Netzwerkkarte als Bridge aus. Bei einer Netzwerkkarte ist dies kein Problem und wird auch standardmäßig für VMnet0 benutzt, allerdings sollten Sie bei mehreren Adaptern die Zuordnung selbst vornehmen, da Sie sonst keine richtige Kontrolle über die virtuellen Netzwerke haben.

Falls Sie diese Funktion gerne nutzen würden, können Sie die verwendeten physikalischen Netzwerkkarten einschränken, indem Sie diese als Excluded Adapter (Abbildung 9.6) markieren.

Abbildung 9.7 Einschränkung der automatischen Zuordnung des bridged Networks

Wenn Sie sich nach der Einrichtung der Bridge die Eigenschaften der physikalischen Adapter des Wirt-Systems anschauen, können Sie ein Protokoll namens VMware Bridge Protocol finden.

Abbildung 9.8 Eigenschaften der physikalischen Netzwerkkarte, über die ein Bridge konfiguriert wurde

Dieses Protokoll wiederum enthält als Eigenschaft den Namen des virtuellen Netzwerkes, für das es verantwortlich zeichnet, in diesem Fall das standardmäßig angelegte Bridge-Netzwerk VMnet0. Diese Eigenschaft finden Sie auf jedem als Bridge genutzten physikalischen Adapter des Wirt-Systems mit der Zuordnung auf das verwendete virtuelle Netzwerk.

Falls Sie mehrere Netzwerkadapter in Ihrem Wirt-System zur Verfügung haben und sie durch die Herstellersoftware zu einem Adapter-Team konfigurieren können, kann die entstehende logische Netzwerkkarte ganz normal unter VMware zu einem Bridge-Adapter werden. Es existiert für ihre virtuelle Maschine keinerlei Unterschied.


Rheinwerk Computing - Zum Seitenanfang

9.2.4 NAT topZur vorigen Überschrift

Wie technisch in Abschnitt 9.1.5, NAT (Network Address Translation), schon erklärt, setzt das NAT-Gerät die interne Adresse der virtuellen Maschine in die physikalische Adresse des Adapters im Wirt-Systems um. Adresse meint hier MAC-Adresse und IP-Adresse. Da NAT nur mit TCP/IP möglich ist, kann kein anderes Netzwerkprotokoll verwendet werden. Durch die Umsetzung der Quelladresse ist die virtuelle Maschine aus der realen Welt nur über eine Verbindung zum NAT-Gerät zu erreichen, d. h., nur Antwortpakete können den Weg zur virtuellen Maschine finden. Diese Form des virtuellen Netzwerkes nutzt man eigentlich nur, wenn die virtuelle Maschine zwar hauptsächlich innerhalb der virtuellen Umgebung bleiben, aber beispielsweise zum Surfen den Internetzugang im realen Netzwerk nutzen soll. Vorteil hierbei ist, dass nur das Wirt-System eine IP-Adresse im realen Netzwerk erhält und alle virtuellen Maschinen innerhalb des NAT-Netzwerkes dann darüber verwaltet werden.


TIPP
Unter VMware GSX Server können Sie immer nur ein einziges NAT-Netzwerk auf dem Wirt-System konfigurieren, auf das die virtuellen Maschinen zugreifen können.

Da Sie ohnehin nur ein NAT-Netzwerk betreiben können, empfehle ich Ihnen der Einfachheit halber das durch die Installation erstellte VMnet8-Netzwerk zu nutzen, das Sie inklusive eines laufenden internen DHCP-Servers bereits konfiguriert vorfinden. Falls Sie diesen DHCP-Server abschalten wollen, funktioniert dies, wie eben erwähnt, immer auf die gleiche Art.

Abbildung 9.9 Konfiguration des NAT-Netzwerks

Um die Einstellungen dieses NAT-Netzwerkes zu ändern, müssen Sie im Virtual Network Editor den Reiter NAT auswählen (Abbildung 9.9) und auf Edit drücken. Noch eines vorweg: hier können Sie auch den NAT-Service beenden oder neu starten, falls ein Problem vorliegt. Dieser Service nennt sich »VMware NAT Service« und ist auch in der Diensteverwaltung des Betriebssystems wiederzufinden. Die Konfigurationsdateien finden Sie im gleichen Verzeichnis wie die DHCP-Konfiguration, und zwar unter den folgenden Namen:

  • vmnetnat.conf – die Konfigurationsdatei des NAT-Gerätes
  • vmnetnat-mac.txt – die MAC-Adresse des NAT-Gerätes

Nun aber wieder zurück zum Thema, das ja da lautete: Ändern der Konfiguration über den Virtual Network Editor. Nach Aufruf über Edit gelangen Sie in die Konfiguration des NAT-Netzwerkes (Abbildung 9.10), in dem Sie die IP-Adresse des NAT-Gateways (über das die virtuelle Maschine später alle, das reale Netzwerk betreffende Pakete routen wird, damit das NAT-Gerät sie umsetzen kann) und verschiedene Timeouts bzw. das Port Forwarding und das DNS-Verhalten festlegen können.

Abbildung 9.10 Konfiguration des NAT-Netzwerkes

Falls es doch einmal zum Betreiben einer Applikation durch die VM für die Umwelt kommen soll, muss ein Port Forwarding auf dem Wirt-System konfiguriert werden. Dabei legt man einen bestimmten Port fest, auf den das Wirt-System hört. Sobald nun ein Paket auf diesem Port ankommt, leitet das NAT-Gerät des Wirt-Systems das Paket an die entsprechende virtuelle Maschine weiter. Weil ein Port nur einmal belegt werden kann, kann ein Dienst auch nur einmal auf dem gleichen Port über NAT weitergeleitet werden.

Beispiel:

Es existieren vier virtuelle Maschinen im NAT-Netzwerk, die einen Webserver anbieten, der auf Port 80 läuft. Am Wirt-System müssen nun vier unterschiedliche Ports eingetragen werden. Da aber auf dem Wirt-System selbst ein Webserver konfiguriert ist, kann Port 80 nicht verwendet werden.


Tabelle 9.1 Beispiel NAT Port Forwarding

Port Forwarding Wirt-System Zielsystem: Portnummer

1080

VM1 Port 80

1081

VM2 Port 80

1082

VM3 Port 80

1083

VM4 Port 80


Die Ports auf dem Wirt-System habe ich rein zufällig gewählt. Wie Sie Tabelle 9.1 entnehmen können, werden nun alle Pakete, die an den Port 1080 des Wirt-Systems gerichtet sind, direkt zum Webserver der virtuellen Maschine VM1 auf Port 80 umgeleitet. Damit dies funktioniert, müssen Sie im Browser http://Wirtsystem:1080 angeben.

Über den Virtual Network Editor würde diese Konfiguration folgendermaßen eingerichtet: Im NAT-Menü (Abbildung 9.10) würde man Port Forwarding auswählen, woraufhin man in das nächste Konfigurationsbild (Abbildung 9.11) gelang, in dem man mit Add jeweils die Einträge hinzufügen kann.

Falls als Netzwerkprotokoll nicht TCP, sondern das verbindungslose UDP verwendet wird, müssen Sie die Ports im unteren Bereich Konfigurationsbildes einpflegen.

Abbildung 9.11 Konfiguration Port Forwarding

Eine letzte Einstellung innerhalb der NAT-Sektion betrifft die Weiterleitung von DNS-Anfragen über das NAT-Gateway, sodass dieses Gateway als DNS-Server für die virtuellen Maschinen genutzt werden kann. Dazu wird in der NAT-Konfiguration (Abbildung 9.10) DNS ausgewählt, und im folgenden Dialog (Abbildung 9.12) werden ein oder mehrere DNS-Server im realen Netzwerk angegeben. Hier können auch Timeouts, Wiederholungen bei Nichterreichbarkeit und DNS-Auswahlverfahren konfiguriert werden.

Abbildung 9.12 Konfiguration DNS Forwarding für das NAT-Gateway

Diese DNS-Auswahlverfahren, hier Policy genannt, bedeuten Folgendes:

  • order – Die angegebenen DNS-Server werden der Reihenfolge nach abgefragt, wobei immer bei dem ersten begonnen wird.
  • rotate – Die angegebenen DNS-Server werden rotierend der Reihenfolge nach abgefragt, d. h., es wird kein Server zweimal hintereinander abgefragt.
  • burst – Es werden die Server willkürlich abgefragt, und dabei wird auf den Server zurückgegriffen, der als erster antwortet.

Da die Arbeitsweise eines NAT-Netzwerks doch recht schwierig zu verstehen ist, erläutere ich die Thematik nochmals anhand einer Grafik.

Wie Sie in Abbildung 9.13 sehen können, existieren in dieser Umgebung eine virtuelle Maschine, ein DHCP-Server, ein NAT-Gerät (oder Gateway) und ein Mitarbeiter-Notebook. Bis auf das Mitarbeiter-Notebook und ein Bein des NAT-Gerätes sind alle Netzwerkgeräte Teil des virtuellen Netzwerks VMnet8, das als NAT-Netzwerk konfiguriert ist.

Wenn die virtuelle Maschine eingeschaltet wird, erhält sie vom DHCP-Server eine eigene IP-Adresse, mit der Sie im realen Firmennetz nichts anfangen kann. Aber in den DHCP-Optionen wird sowohl ein Gateway als auch ein DNS-Server mitgegeben. Sowohl Gateway als auch DNS-Server haben die virtuelle IP-Adresse des NAT-Gerätes. Will man mit der virtuellen Maschine nun ins Firmennetz, beispielsweise auf einen Internetproxy, so wird das Paket an das NAT-Gerät gesendet, das die Quelladresse durch die eigene Adresse ersetzt. Es werden dabei sowohl die IP-Adresse als auch die MAC-Adresse verändert.

Abbildung 9.13 Beispielumgebung NAT-Netzwerk

IP-Paket (Original): Quelle: 192.168.59.10 Ziel: 10.0.0.200 IP-Paket (NAT): Quelle: 10.0.0.1 Ziel: 10.0.0.200

Um eine spätere Zuordnung zu gewährleisten, hält das NAT-Gerät alle Verbindungen in einer Liste vor. Der empfangende Proxy Server sendet seine Antwort auf das Paket ganz normal an die Adresse des NAT-Gerätes (10.0.0.1), das seinerseits wiederum die Zieladresse für die virtuelle Maschine verständlich umsetzt.

Für den Fall, dass die schon angesprochene DNS-Weiterleitung durch das NAT-Gerät eingetragen ist, wird der virtuellen Maschine als DNS-Server die IP-Adresse des NAT-Gerätes entweder manuell oder durch den DHCP-Server mitgeteilt. Fragt nun die virtuelle Maschine nach einer Adressauflösung, verhält sich das NAT-Gerät wie ein echter DNS-Server, fragt im Hintergrund den DNS-Server (10.0.0.5) im Firmennetz ab und gibt dessen Antwort an die virtuelle Maschine zurück.

Der komplizierteste Fall ist das Port Forwarding, da hier nicht nur die Adresse, sondern gegebenenfalls auch der Port abgeändert werden muss. Nehmen wir mal an, der Mitarbeiter, der mit seinem Notebook im Firmennetz sitzt, wollte auf den Webserver der virtuellen Maschine zugreifen. Wir erinnern uns, dass der Webserver auf der virtuellen Maschine eigentlich auf Port 80 läuft und das NAT-Gerät einen Port Forwarding-Eintrag für auf diesen Webserver über den eigenen Port 1080 verwaltet (siehe Tabelle 9.1). Der Mitarbeiter gibt nun in seinem Browser als Adresse http://10.0.0.1:1080 ein, und es passiert daraufhin Folgendes:

  • Paket 10.0.0.10 → 10.0.0.1:1080
  • Paket wird vom NAT-Gerät umgesetzt, indem die Zieladresse und der Zielport angepasst werden: 10.0.0.1:1080 → 192.168.59.10:80
  • Paketantwort der virtuellen Maschine: 192.168.59.10 → 10.0.0.10
  • Paket wird vom NAT-Gerät umgesetzt, indem die Quelladresse angepasst wird: 192.168.59.10 → 10.0.0.1

Durch die zentrale Instanz des NAT-Geräts merkt keiner der Teilnehmer etwas von der Adressumsetzung, und die eigentliche Kommunikation wird nicht gestört.



Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.

<< zurück
  Zum Rheinwerk-Shop
Zum Rheinwerk-Shop: Vmware und Microsoft Virtual Server
Vmware und Microsoft Virtual Server


 Ihre Meinung?
Wie hat Ihnen das Openbook gefallen?
Ihre Meinung

 Buchtipps
Zum Rheinwerk-Shop: Vmware vSphere 5.5






 Vmware vSphere 5.5


Zum Rheinwerk-Shop: Vmware vSphere 5.5






 Vmware vSphere 5.5


Zum Rheinwerk-Shop: Vmware View






 Vmware View


Zum Rheinwerk-Shop: Microsoft Hyper-V






 Microsoft Hyper-V


Zum Rheinwerk-Shop: Office 365






 Office 365


 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und der Schweiz
InfoInfo




Copyright © Rheinwerk Verlag GmbH 2005
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das Openbook denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt.
Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de

Cookie-Einstellungen ändern