NAT-Geräte - Microsoft

Windows Messenger unter Windows XP:
Arbeiten mit Firewalls und NAT-Geräten (Network
Address Translation oder Netzwerkadressübersetzung)
(Engl. Originaltitel: Windows Messenger in Windows XP: Working With Firewalls and Network Address
Translation Devices)
Betriebssystem
Autor: Tom Fout
Microsoft Corporation
Veröffentlicht: Oktober 2001
Zusammenfassung
In diesem Artikel werden verschiedene Szenarien erläutert, in denen die Voraussetzungen für die Verwendung
aller Windows Messenger-Funktionen beschrieben und mögliche Lösungen für bekannte Probleme bereitgestellt
werden.
Mithilfe des Microsoft® Windows® Messenger-Dienstes können Sie mittels Instant Messaging (IM), Sprache,
Video, der Anwendungs- und Datenfreigabe und der Remoteunterstützung mit Kontakten kommunizieren. In
vielen Netzwerken können alle diese Funktionen ohne Änderungen an der Netzwerkinfrastruktur verwendet
werden. Es gibt jedoch Netzwerke, die eine spezielle Konfiguration benötigen, damit alle neuen
Windows Messenger-Funktionen reibungslos funktionieren.
Microsoft hat sich die Zusammenarbeit mit führenden Branchenvertretern und Standardorganisationen zum Ziel
gesetzt, wie z. B. Internet Engineering Task Force (IETF), um sicherzustellen, dass diese umfangreichen
Funktionen für die Kommunikation und die Zusammenarbeit auch hinter Firewalls und NATs zur Verfügung
stehen.
Danksagungen
Ann Demirtjis, Lead Program Manager, Microsoft Corporation
Imad Yanni, Product Manager, Microsoft Corporation
Michael Kessler, Technical Editor, Microsoft Corporation
Einführung
In diesem Artikel werden verschiedene Szenarien erläutert, in denen die Voraussetzungen für die Verwendung
aller Windows Messenger-Funktionen beschrieben und mögliche Lösungen für bekannte Probleme aufgeführt
werden.
Windows Messenger stellt beeindruckende neue Kommunikationsfunktionen in Echtzeit bereit, die die Art der
Kommunikation zwischen Benutzern revolutionieren. Mithilfe von Windows Messenger können Sie mittels
Instant Messaging (IM), Sprache, Video, der Anwendungs- und Datenfreigabe und der Remoteunterstützung mit
Kontakten kommunizieren. In vielen Netzwerken können alle Funktionen ohne Änderungen an der
Netzwerkinfrastruktur verwendet werden. Bestimmte Netzwerke, wie Firmennetzwerke oder lokale Netzwerke,
können auch Firewalls und/oder NAT-Komponenten bereitstellen.
Der Zweck eines Firewalls besteht darin, Computer im Netzwerk zu schützen, indem der Direktzugriff blockiert
wird. Computer, die sich hinter einem Firewall befinden, nutzen eine NAT-Komponente, um beschränkt
verfügbare öffentliche IP-Adressen (Internet Protocol oder Internetprotokoll) gemeinsam zu nutzen. Die
gemeinsame Nutzung von IP-Adressen ist eine durch das aktuelle IPv4-Adressierungsschema (IP Version 4)
auferlegte Beschränkung. Da das IPv4-Adressierungsschema nicht genügend IP-Adressen bereitstellen kann, war
die IT-Branche gezwungen, NAT zu standardisieren und NAT-Produkte bereitzustellen, die IP-Adressen und
TCP/UDP-Ports (Transmission Control Protocol/User Datagram Protocol) gemeinsam nutzen. In bestimmten
Internetszenarien ergibt sich daraus ein eingeschränkter Funktionsumfang bei einigen Windows MessengerFunktionen – in erster Linie bei der Sprach- und Videokommunikation.
Werden UPnP-gestützte (Universal Plug and Play) Firewalls oder NAT-Komponenten zwischen
kommunizierenden Parteien verwendet, funktionieren alle neuen Windows Messenger-Funktionen
erwartungsgemäß. Bestimmte Netzwerkanordnungen erfordern jedoch einen speziellen Konfigurationsaufwand,
damit alle neuen Windows Messenger-Funktionen einwandfrei funktionieren.
Anmerkung Microsoft hat sich die Zusammenarbeit mit führenden Branchenvertretern und
Standardorganisationen zum Ziel gesetzt, wie z. B. IETF (Internet Engineering Task Force), um sicherzustellen,
dass diese umfangreichen Funktionen für die Kommunikation und die Zusammenarbeit hinter Firewalls und
NATs zur Verfügung stehen.
Zu den in diesem Artikel behandelten Themen gehören:







Probleme mit NAT und Firewalls
NAT und Windows Messenger
Firewalls und Windows Messenger
Richtige und falsche Konfigurationen
Lösungen
Audio und Video mit ISA Server
Glossar
Probleme mit NAT und Firewalls
In diesem Abschnitt werden die Windows Messenger-Funktionen erläutert, auf die sich Probleme mit NAT und
Firewalls auswirken: Instant Messaging und Präsenz, Audio und Video, Anwendungsfreigabe und Whiteboard,
Dateiübertragung und Remoteunterstützung.
Windows Messenger bietet die Möglichkeit, mithilfe von Text, Sprache und Video zu kommunizieren, durch die
Übertragung von Dateien zusammenzuarbeiten und Anwendungen und Whiteboardzeichnungen gemeinsam zu
nutzen.
Es gibt eine Vielzahl von Konfigurationen, in denen die Funktionen von Windows Messenger nahtlos
funktionieren. Es existieren jedoch auch Konfigurationen, in denen bestimmte Funktionen nur eingeschränkt
oder überhaupt nicht funktionieren. Um einige dieser Probleme zu lösen, setzt Windows Messenger die UPnPInfrastruktur unter Windows XP und unter früheren Windows-Versionen ein. Diese Art der Auflösung wird in
Zukunft in stärkerem Maß zur Verfügung stehen, da mehr Internetgatewaygeräte Unterstützung für UPnP bieten.
Anmerkung Microsoft stellt durch die Technologien der Internetverbindungsfreigabe (ICS oder Internet
Connection Sharing) und des Internetverbindungsfirewalls (ICF oder Internet Connection Firewall) umfassende
Unterstützung von UPnP unter Windows XP bereit. (Weitere Informationen zu ICS und ICF finden Sie unter
What's New In Security for Windows XP [englischsprachig].)
Die folgenden Windows Messenger-Funktionen sind von Problemen im Zusammenhang mit NAT und Firewalls
betroffen:
Instant Messaging und Präsenz
Im Allgemeinen treten keine Probleme mit IM und der Präsenz auf, die sich auf die Kommunikation über einen
Firewall oder ein NAT-Gerät auswirken. Wenn der Windows XP-Client eine Verbindung zum Server herstellen
und beibehalten kann, ist weitere auf IM und Präsenz basierte Kommunikation über diesen Weg möglich. So
überträgt beispielsweise Microsoft Exchange IM die Präsenz- und IM-basierten Nachrichten mithilfe von HTTP
(Hypertext Transfer Protocol) und verfügt über Mechanismen, um sicherzustellen, dass diese Nachrichten
Firewalls und NAT-Geräte traversieren können. Zu diesen Mechanismen gehört das Abfragen (Polling), um eine
TCP-Verbindung mit dem Server für die bidirektionale Kommunikation herzustellen und einen feststehenden
Port für die Übermittlung von Rückrufen zu reservieren.
Bei Verwendung einer SIP-Lösung (Session Initiation Protocol) können die Daten mithilfe von TCP, UDP oder
SSL (Secure Sockets Layer) gesendet werden. SIP-Signale können auch mit dynamischen Ports arbeiten. Dazu
müssen gegebenenfalls alle Ports an einem Firewall geöffnet werden. Wenn ein NAT-Gerät zwischen SIPClients und den zugehörigen Servern positioniert wird, können Unterschiede zwischen den tatsächlichen Ports
und Adressen und denjenigen, die in den SIP-Nachrichten verwendet werden, auftreten. Windows Messenger
verfügt über Mechanismen, um diese Probleme zu beheben, die nachfolgend in diesem Artikel behandelt
werden.
Audio und Video
Für die Aushandlung einer Audio-/Videositzung werden dynamische Ports für den AV-Datenstrom
(Audio/Video) gewählt. Dynamische Ports werden verwendet, damit die Anwendung unabhängig von anderen
auf dem System ausgeführten Anwendungen, die möglicherweise ebenfalls Portressourcen verwenden,
ausgeführt werden kann. Im Falle von .NET Messenger wird die Sitzungseinladung von Station B an die für
Station A erhaltene Adresse gesendet.
Die folgenden Probleme können auftreten, wenn ein Firewall oder ein NAT-Produkt in diesen Szenarien
vorkommt:



Bei der von A bereitgestellten Adresse in der Sitzungseinladung für Sitzungssignale oder in der
Sitzungsannahme für die UDP-Datenströme kann es sich um eine interne Adresse handeln, die von
einem NAT-Gerät übersetzt wird - also eine ungültige (oder falsche) Adresse für B, um sich mit A in
Verbindung zu setzen. In anderen Szenarien, an denen der 4.5-Client beteiligt ist, ist es möglich, dass A
die Sitzung initiiert, doch kommt es zu denselben oder vergleichbaren Adressproblemen.
Wenn B die Sitzungseinladung an A sendet, wird diese Einladung mithilfe der von A an B übergebenen
IP-Adresse und des Ports gesendet. Dazu muss dieser Port für die Weiterleitung über einen Firewall
zwischen A und B aktiviert sein.
Die tatsächlichen RTP-Datenströme (Real-time Transport Protocol) werden mithilfe dynamisch
zugewiesener UDP-Ports im Bereich von 5004 bis 65535 gesendet. Ohne die Möglichkeit, diese UDPPorts dynamisch an einem beliebigen Firewall auf diesem Pfad zu öffnen, erreichen die Datenströme ihr
Ziel nicht.
Anwendungsfreigabe und Whiteboard
Die folgenden Probleme entstehen bei der Verwendung der Anwendungsfreigabe und des Whiteboards in einer
Umgebung mit NAT-Komponenten oder Firewalls. (Die ersten beiden Probleme sind identisch mit jenen, die im
Abschnitt "Audio und Video" beschrieben wurden.)




Bei der von der initiierenden Station bereitgestellten Adresse kann es sich um eine interne Adresse
handeln, die von einem NAT-Gerät übersetzt wird. Der externe Client kann diese ungültige Adresse
nicht zur Initiierung der SIP-Sitzung oder TCP-Verbindung mit A verwenden.
Der vom externen Client zum Senden der SIP-Einladung verwendete Port - die Einladung, die vom
internen Client an den externen Client übergeben wird - muss so aktiviert werden, dass die SIPEinladung über jeden Firewall zwischen den Clients weitergeleitet werden kann.
Die TCP-Verbindung für die Daten der Anwendungsfreigabe (AS oder Application Sharing) und des
Whiteboards (WB) verwendet Port 1503, für den die Traversierung über Firewalls aktiviert werden
muss. Dies ist bei einem UPnP-gestützten Gateway nicht der Fall, da es den internen statischen Port
einem anderen Port zuordnet.
Da ein bestimmter Port für die TCP-Datenübertragung (1503) verwendet wird, muss dieser Port diesem
Client zugeordnet werden, falls sich der Client hinter einem nicht auf UPnP gestützten NAT-Gerät
befindet. Dadurch wird die Kommunikation über das Gerät sichergestellt, das den kleinsten
gemeinsamen Nenner darstellt. Das bedeutet auch, dass der Port normalerweise nicht von einem
anderen Client hinter dem NAT-Gerät verwendet werden kann; nur ein einzelner Client, der sich hinter
demselben NAT-Gerät befindet, kann eine aktive AS- oder WB-Sitzung führen.
Dateiübertragung
Die Dateiübertragung (FT oder File Transfer) setzt voraus, dass die initiierende Station ihre Adresse über den
Server an den FT-Peer während des Sitzungsaustauschs übergibt. Deshalb findet das erste unter
"Anwendungsfreigabe und Whiteboard" aufgeführte Problem hier Anwendung:

Bei der von der initiierenden Station bereitgestellten Adresse kann es sich um eine interne Adresse
handeln, die von einem NAT-Gerät übersetzt wird. Der Peer kann diese Adresse nicht zum Herstellen
der TCP-Verbindung verwenden.
Die für die Dateiübertragung verwendete TCP-Verbindung, die von der externen Partei initiiert werden könnte,
stellt ein zusätzliches Problem dar.

Sowohl eingehende als auch ausgehende TCP-Verbindungen verwenden den Portbereich von 6891 bis
6900. Dieser lässt bis zu 10 gleichzeitige Dateiübertragungen pro Absender zu. Diese Ports müssen an
allen Firewalls zwischen den Peers geöffnet sein. Wenn Sie nur Port 6891 öffnen, können die Benutzer
nur jeweils eine Dateiübertragung nach der anderen vornehmen.
Remoteunterstützung
Bei der Remoteunterstützung wird Remote Desktop Protocol (RDP) verwendet. Dies ist dasselbe Protokoll, das
auch von den Microsoft-Terminaldiensten verwendet wird. RDP wird auf eine TCP-Verbindung aufgesetzt.
Windows Messenger richtet die Remoteunterstützungssitzung mithilfe der Einladungslogik der serverbasierten
Sitzung ein, vergleichbar mit der Dateiübertragung. Deshalb findet das bei NAT-Adressen festgestellte Problem
auch in diesem Szenario Anwendung.
Die Remoteunterstützung umfasst zusätzliche Logik, die speziell für das NAT-Szenario entwickelt wurde. Diese
Logik versucht einfach, die TCP-Verbindung von beiden Clients aus herzustellen. Auf diese Art kann die
Verbindung auch dann noch hergestellt und die Remoteunterstützung bereitgestellt werden, wenn sich einer der
Clients hinter einem NAT-Gerät befindet. Befinden sich beide Clients hinter einem (nicht auf UPnP gestützten)
NAT-Gerät, wird die Verbindung nicht hergestellt. Die zusätzliche SIP-Einladungslogik wird nur hinzugefügt,
wenn die Remoteunterstützung durch eine Sprachsitzung erweitert wird.
Zusätzlich zu den Problemen im Zusammenhang mit NAT-Adressen, die nur bei Verwendung mehrerer NATGeräte im Kommunikationspfad berücksichtigt werden müssen, wird der TCP-Port 3389 für die TCPVerbindung des Remoteunterstützungsprotokolls verwendet. Dies bedeutet, dass Port 3389 für alle Firewalls
zwischen Clients geöffnet werden muss.
NAT und Windows Messenger
In diesem Abschnitt werden Probleme und Konfigurationen für NAT-Geräte behandelt.
Von NAT-Geräten verursachte Probleme
Zu den Problemen, die speziell NAT-Geräte bei Verwendung mit Windows Messenger-Funktionen auslösen,
gehören folgende:



Clients hinter einem NAT-Gerät wird in der Regel eine private IP-Adresse zugewiesen. Diese Adresse
wird vom NAT-Gerät in und aus einer öffentlichen IP-Adresse und einem Port übersetzt. In mehreren
Fällen wird diese private Adresse in einer Nachricht an einen Windows Messenger-Peer weitergegeben,
damit der Peer Kontakt mit dem Client aufnehmen kann. Die Adresse ist für diesen Zweck ungültig;
anstelle dessen muss die übersetzte Adresse verwendet werden.
In verschiedenen Fällen müssen Portzuordnungen am NAT-Gerät vorgenommen werden, um einem
externen Client eine Adresse und einen Port zu präsentieren und die Zuordnung zum entsprechenden
internen Client herzustellen.
In einigen Fällen, in denen statische Ports für ein bestimmtes Feature verwendet werden, kann nur ein
einzelner Client hinter dem NAT-Gerät dieses Feature nutzen.
Arbeiten mit verschiedenen NAT-Gerätekonfigurationen
Im folgenden Abschnitt werden Probleme im Zusammenhang mit verschiedenen NAT-Gerätekonfigurationen
behandelt:
UPnP-gestützte NAT-Geräte
Das UPnP-Forum enthält mehrere Arbeitsgruppen, einschließlich einer Arbeitsgruppe, die sich speziell mit
Internetgatewaygeräten beschäftigt. Diese Gruppe ist für die Definition der Details zur UPnP-Unterstützung für
diese Geräte, zu denen NAT-Geräte und Firewalls gehören, zuständig. Diese Gruppe hat einen Standard für die
ICS- und NAT-basierte Netzwerktraversierung mithilfe von UPnP definiert.
NAT- und Firewallgeräte, die diesen Standard unterstützen, können mithilfe von UPnP-Protokollen erkannt und
gesteuert werden. UPnP kann von Clients zum Lesen und Konfigurieren von Portzuordnungen verwendet
werden. ICS und ICF unter Windows XP unterstützen diesen Standard. Drittanbieter von Geräten der
Netzwerkgrenze haben ebenfalls Unterstützung für diesen Standard angekündigt, einschließlich ARESCOM Inc.,
Buffalo Technologies Corp., D-Link Systems Inc., Intel Corp., Linksys Group Inc und NetGear Inc.
Windows XP stellt auch Clientunterstützung für UPnP und APIs (Application Programming Interface oder
Anwendungsprogrammierschnittstelle) bereit, die speziell für Anwendungen entworfen wurde, um UPnPgestützte NAT-Geräte und Firewalls in einem Netzwerk zu erkennen und zu nutzen. Windows Messenger unter
Windows XP setzt diese APIs ein, um Folgendes zu erreichen:




Erkennen, ob sich der Windows Messenger-Client hinter einem NAT-Gerät befindet, und wenn dies der
Fall ist, Abrufen der übersetzten Adresse, um sie an den Peer zu senden. Dadurch werden mehrere der
oben beschriebenen Probleme gelöst.
Abrufen einer Portzuordnung für dynamisch zugewiesene Ports, die für Signale verwendet werden (also
solche, die für die Konfiguration einer SIP-Sitzung erforderlich sind). Dadurch können Signale des
externen Clients ihr Ziel erreichen.
Abrufen von Zuordnungen für die von Mediendatenströmen verwendeten dynamischen Ports einschließlich jener für AV, AS und WB.
Erkennen, ob sich der Windows Messenger-Peer hinter demselben NAT-Gerät befindet. Wenn dies der
Fall ist, werden die tatsächlichen Adressen des Peers abgerufen, und die Peers können direkt
kommunizieren.
Anmerkung Unterstützung von UPnP-Clients für die NAT-Traversierung soll auch für frühere WindowsVersionen (Windows 98, 98SE und ME) angeboten werden.
Nicht auf UPnP gestützte NAT-Geräte
Windows Messenger-Peers, die durch ein NAT-Gerät, das nicht erkannt werden kann, voneinander getrennt sind,
sollten IM und die Präsenz verwenden können. Dies trifft unabhängig davon zu, ob es sich beim Netzwerkdienst
um .NET Messenger, Exchange IM oder eine SIP-Lösung handelt. Clients, die SIP-Servern verwenden,
funktionieren ebenfalls, da die Logik des Clients so erweitert wurde, dass die Kommunikation auch beim
Herstellen der Verbindung mit dem Server sichergestellt ist.
Wie bereits weiter oben in diesem Artikel beschrieben, treten bei den anderen Funktionen von
Windows Messenger Probleme auf. Die folgenden Punkte beziehen sich auf diese Probleme:



IM und die Präsenz werden über einen vermittelnden Server mithilfe einer bei Verwendung von
NET Messenger oder Exchange IM direkten, vom Client initiierten TCP-Verbindung implementiert.
Dies sollte kein Problem im Zusammenhang mit NAT-Geräten oder Firewalls darstellen. Sitzungen
oder Verbindungen, die von Clients außerhalb des NAT-Geräts initiiert werden, sind nicht erfolgreich,
da der interne Client die NAT-übersetzte Adresse dem Peer nicht bereitstellen kann. Bei AV gilt dies
für Anrufe, die vom internen Client an den externen Client ausgeführt werden, da der externe Client
derjenige ist, der die SIP-Sitzung initiiert. Wenn der externe Client den internen Client anruft, tritt der
Fehler zu einem späteren Zeitpunkt im Prozess auf. Der interne Client kann die SIP-Einladung an den
externen Client senden, doch die im Rahmen dieser Einladung übergebene Adresse ist falsch.
Anrufe, die zwischen Peers auf derselben Seite des NAT-Geräts stattfinden, sollten uneingeschränkt
funktionieren.
Durch ein Gateway auf Anwendungsebene (ALG oder Application Layer Gateway) für SIP können
einige dieser Probleme gemindert werden. ALGs können als Filter auf der Anwendungsebene für
bestimmte Anwendungen und Protokolle verwendet werden.
Kaskadieren von NAT-Geräten
Selbst wenn kein NAT-Gerät in der Netzwerkgrenze verwendet wird bzw. ein IPnP-gestütztes NAT-Gerät
verwendet wird, kann die AV-Kommunikation von Windows Messenger durch ein kaskadierendes NATSzenario vereitelt werden. Bei diesem Szenario ist ein weiteres NAT-Gerät im Pfad zwischen Ihnen und dem
Windows Messenger-Client enthalten, mit dem Sie kommunizieren. Dieses NAT-Gerät wird von keinem der
Clients gesteuert. Dies ist der Fall, wenn der Internetdienstanbieter (ISP oder Internet Service Provider) ebenfalls
die NAT-Technologie in seinem Netzwerk verwendet. Dieses Problem tritt jedoch nicht häufig auf. Wenn Sie
diese Situation vermuten, sollten Sie sich mit Ihrem Internetdienstanbieter in Verbindung setzen, um das
Problem zu analysieren und nach möglichen Alternativen zu suchen.
Firewalls und Windows Messenger
Wie NAT-Geräte können auch Firewalls Probleme auslösen, wenn Sie versuchen, mithilfe von
Windows Messenger zu kommunizieren. Zu den von Firewallgeräten verursachten Problemen gehören folgende:


Die für SIP-Signale verwendeten Nachrichten können von einem externen Client stammen und
scheinen weder von einem dynamischen Port noch von Port 5060 angefordert zu sein. Damit diese
Nachrichten zum Windows Messenger-Client gelangen, müssen die Ports am Firewall geöffnet werden.
Wird beispielsweise ICF unter Windows XP verwendet, wird Port 5060 standardmäßig blockiert.
Ports für Mediendatenströme und andere Daten, wie dynamische Ports für AV, und Port 1503 für AS
und WB müssen die Berechtigung zum Traversieren des Firewalls haben.
Arbeiten mit verschiedenen Firewallkonfigurationen
Im folgenden Abschnitt werden Probleme im Zusammenhang mit verschiedenen Firewallkonfigurationen
behandelt:
UPnP-gestützte Firewalls
UPnP-gestützte Gatewaygeräte wurden weiter oben in diesem Artikel behandelt. Der Windows XP-Firewall, der
als Internetverbindungsfirewall (ICF oder Internet Connection Firewall) bezeichnet wird, ist UPnP-gestützt.
Windows Messenger unter Windows XP nutzt diese Funktion, indem die für Signale, Verbindungen oder
Mediendatenströme erforderlichen Ports geöffnet werden.
Nicht auf UPnP gestützte Firewalls
Es stehen nur sehr wenige Optionen für die Verwendung der erweiterten Funktionen von Windows Messenger
zusammen mit einem nicht auf UPnP gestützten Firewall zur Verfügung. In diesem Abschnitt werden die
folgenden Themen behandelt:




Peers auf derselben Seite des Firewalls können alle Funktionen von Windows Messenger verwenden.
IM und die Präsenz können in den meisten Firewallkonfigurationen eingesetzt werden.
Um AV in beiden Richtungen über den Firewall zu unterstützen, müssen alle UDP-Ports zwischen 5004
und 65535 geöffnet werden, damit Signale (SIP) und Mediendatenströme (RTP) den Firewall
traversieren können. Dies ist aufgrund der Verwendung dynamischer Ports notwendig. AS und WB
verwenden ebenfalls dynamische Ports für Signale.
Die Dateiübertragung kann durch Öffnen der Ports 6891 bis 6900 am Firewall aktiviert werden. Die
Remoteunterstützung kann durch Öffnen von Port 3389 aktiviert werden.
Kaskadieren von Firewalls
Das Kaskadieren von Firewalls kann vergleichbare Probleme wie das Kaskadieren von NAT-Geräten
verursachen.
Einschränkungen für UPnP unter Windows XP
Unter Windows XP funktionieren ausgehende Anrufe von Windows Messenger nicht, wenn ICF an der lokalen
Schnittstelle aktiviert wurde und der Benutzer nicht über Administratorrechte verfügt. Dieses Feature
funktioniert bei Benutzern mit Administratorrechten jedoch einwandfrei.
Anmerkung Windows XP Home Edition erteilt Benutzern standardmäßig Administratorrechte.
Richtige und falsche Konfigurationen für Windows Messenger
Es werden hier verschiedene Diagramme mit Windows Messenger-Konfigurationen unter Verwendung von
NAT-Geräten und Firewalls dargestellt. Diese Darstellungen werden in die Kategorien "Richtige
Konfigurationen" und "Falsche Konfigurationen" unterteilt.
Richtige Konfigurationen
Die folgenden Konfigurationen funktionieren, sofern keine Netzwerkprobleme vorliegen.
Einzelnes UPnP-gestütztes NAT-Gerät
In Abbildung 1 wird Gebäude A mit einem UPnP-gestützten Internetgatewaygerät ausgestattet. Gebäude B
verfügt über einen PC, der direkt mit dem Internet verbunden ist, und verwendet kein Gatewaygerät. Das UPnPGateway ermöglicht es Gebäude A, die externe Netzwerkadresse zu erkennen und Zuordnungen nach Bedarf zu
erstellen. Dadurch können Gebäude A und Gebäude B kommunizieren, wie in Abbildung 1 weiter unten
dargestellt.
Abb. 1: Verwenden eines einzelnen UPnP-gestützten NAT-Geräts
Zwei über UPnP-gestützte Gateways verbundene Gebäude
Abbildung 2 ist vergleichbar mit Abbildung 1, doch verfügt Gebäude B in diesem Fall über ein
Internetgatewaygerät. Da beide Geräte UPnP-gestützt sind, können Gebäude A und Gebäude B weiterhin
mithilfe aller Windows Messenger-Funktionen miteinander kommunizieren, wie in Abbildung 2 weiter unten
dargestellt.
Abb. 2: Herstellen einer Verbindung über UPnP-gestützte Gateways
Zwei Clients hinter einem UPnP-gestützten Gateway
In Abbildung 3 werden zwei Clients hinter demselben Gerät dargestellt. Wenn das NAT-Gerät UPnP-gestützt ist,
erkennen die Clients, dass sie sich hinter demselben Gerät befinden und dass sie direkt kommunizieren können,
wie in Abbildung 3 weiter unten dargestellt.
.
Abb. 3: Zwei Clients hinter einem UPnP-gestützten Gateway
Falsche Konfigurationen
Die folgenden Konfigurationen enthalten, abgesehen von IM und der Präsenz, weitere Hindernisse für die
Windows Messenger-Kommunikation.
Wenn der Internetdienstanbieter NAT verwendet
Abbildung 4 gibt das zuvor in Abbildung 1 dargestellte Szenario wieder, doch setzt der für Gebäude A
zuständige Internetdienstanbieter auch die NAT-Technologie ein. Dadurch erfährt der Computer von Gebäude A
seine tatsächliche öffentliche Adresse nicht, wie in Abbildung 4 weiter unten dargestellt.
Abb. 4: Internetdienstanbieter, der ein NAT-Gerät verwendet
Gebäude B verwendet ein nicht auf UPnP gestütztes NAT-Gerät
Abbildung 5 ist vergleichbar mit Abbildung 2, doch unterstützt das von Gebäude B verwendete NAT-Gerät
UPnP nicht und lässt nicht zu, dass der PC von Gebäude B die übersetzten Adressen ermittelt. Diese
Konstellation wird in Abbildung 5 weiter unten dargestellt.
Abb. 5: Verwenden eines nicht auf UPnP gestützten NAT-Geräts
Ein nicht auf UPnP gestütztes NAT-Gerät
Abbildung 6 stimmt mit Abbildung 1 überein, außer dass das NAT-Gerät nicht auf UPnP basiert. Auch in diesem
Fall können die übersetzten Adressen nicht ermittelt werden, und Portzuordnungen können nicht für die von
Windows Messenger verwendeten dynamischen Ports erstellt werden. Diese Konstellation wird in Abbildung 6
weiter unten veranschaulicht.
Abb. 6: Verwenden eines nicht auf UPnP gestützten NAT-Geräts
Lösungen
Wenn NAT-Geräte oder Firewalls zum Kommunikationspfad für Windows Messenger hinzugefügt werden,
können daraus verschiedene Schwierigkeiten entstehen. Beinahe alle diese Probleme werden durch die
Verwendung UPnP-gestützter Internetgatewaygeräte behoben. Viele Hersteller integrieren diese Funktion bereits
in ihre Geräte; einige ziehen sogar die Nachrüstung älterer, aktualisierbarer Geräte mit dieser Funktion in
Erwägung.
Die folgende Zusammenfassung der Probleme und Lösungen dient Ihnen als einfache Referenz.
NAT-Geräte
Der Client hinter einem NAT-Gerät verfügt über eine private Adresse, die im internen Netzwerk verwendet
werden kann, und eine über die Adressübersetzung bereitgestellte öffentliche Adresse für die Kommunikation
mit dem Netzwerk außerhalb des NAT-Geräts. Die zum Erstellen von AV-Sitzungen verwendeten Protokolle
zwischen Clients schließen Adressinformationen ein. Bei den bereitgestellten Adressen kann es sich um private,
interne Adressen und Anschlussnummern handeln, die im öffentlichen Netzwerk ungültig sind. Dadurch wird die
Kommunikation mittels Sprache und Video verhindert.
Umgehen von NAT-Problemen
UPnP-gestützte NAT-Geräte ermöglichen es Windows Messenger, die zu verwendenden Portnummern
auszuhandeln und übersetzte IP-Adressen zu ermitteln. Dadurch können Clients gültige Adressinformationen
gemeinsam nutzen und Benutzer mittels Sprache und Video in NAT-gestützten Netzwerken kommunizieren.
Verfügbare NAT-Lösungen
Windows XP enthält in Form von ICS ein UPnP-gestütztes Internetgateway. Dies ist eine einfache Lösung, wenn
ein Computer als Internetgatewaygerät verwendet wird. Andere Hersteller arbeiten an UPnP-gestützten
Gatewaygeräten oder Updates, um aktuelle Gatewayprodukte durch UPnP-Unterstützung zu erweitern. Weitere
Informationen zu diesen Produkten finden Sie in der folgenden Presseveröffentlichung unter
http://www.microsoft.com/presspass/press/2001/Jul01/07-17GatewayDevicesPR.asp und auf den Websites der
jeweiligen Hersteller.
Hersteller anderer NAT-Geräte stellen eventuell Schnittstellen für Gateways auf Anwendungsebene (ALGs oder
Application Layer Gateways) oder Anwendungsfilter bereit. Dabei handelt es sich um Plug-Ins für die
Gerätesoftware, die zur Unterstützung bestimmter Protokolle oder Anwendungen geschrieben wurden und bei
Bedarf die Daten für interne und externe Netzwerke übersetzen.
Administrator-/Benutzereingriffe erforderlich
Keine
Wenn Sie ein Problem vermuten, erkundigen Sie sich beim Internetdienstanbieter, oder lesen Sie die
Dokumentation für das Internetgateway, um zu ermitteln, ob NAT verwendet wird und ob Unterstützung für
UPnP zur Verfügung steht. Wenn Sie ein UPnP-gestütztes NAT-Gerät verwenden, erkundigen Sie sich beim
Internetdienstanbieter, ob NAT in ihrem Netzwerk verwendet wird und ob eine Lösung angeboten wird, durch
die RTP-basiertes AV aktiviert wird.
Firewallgeräte
Firewalls schützen Computer im externen Netzwerk, indem verhindert wird, dass Datenverkehr IP-Adressen und
TCP/UDP-Ports erreicht, die nicht explizit konfiguriert und aktiviert wurden. Der Datenverkehr wird basierend
auf ausgehenden Daten- und Verbindungsanforderungen zugelassen, um eine reguläre, aufgeforderte
Kommunikation zu ermöglichen.
Mit Windows Messenger kommt es zu Situationen, in denen der Datenpfad für die kommunizierenden Clients
mithilfe von Sitzungseinrichtungsprotokollen, wie z. B. SIP, konfiguriert wird. Nach der Konfiguration der
Sitzung kann die Kommunikation vom externen Client initiiert werden. Diese Kommunikation kann durch den
Firewall blockiert werden. Darüber hinaus verwendet Windows Messenger dynamische Ports für den AVDatenverkehr. So wird sichergestellt, dass Portressourcen für die AV-Datenströme zur Verfügung stehen, jedoch
wird das Problem mit dem Firewall verstärkt, da nicht bekannt ist, welche Ports verwendet werden.
Umgehen von Firewallproblemen
Die Lösung für diese Firewallprobleme wird erneut von UPnP bereitgestellt. Windows Messenger erkennt
UPnP-gestützte Firewalls und konfiguriert sie entsprechend basierend auf den aktuellen
Kommunikationsanforderungen. Ist kein UPnP-gestützter Firewall vorhanden, muss der Firewall so konfiguriert
werden, dass der Datenverkehr für das Protokoll und die Ports zulässig ist, die für die gewünschte
Windows Messenger-Funktionalität notwendig sind. Weitere Informationen finden Sie im Abschnitt
"Administrator-/Benutzereingriffe erforderlich" weiter unten.
Verfügbare Firewalllösungen
Der von Windows XP bereitgestellte Firewall, der Internetverbindungsfirewall, unterstützt die Konfiguration
mithilfe von UPnP. Windows Messenger erkennt diese Funktion und öffnet die entsprechenden Ports zur
Weiterverarbeitung der Kommunikation. Wenn Sie den Firewall eines Drittanbieters verwenden, lesen Sie die
Herstellerangaben nach, um zu ermitteln, ob UPnP unterstützt wird, und um festzustellen, wie der Firewall
konfiguriert werden muss, damit die aufgeführten Ports die Weitergabe ermöglichen. Weitere Informationen
finden Sie im Abschnitt "Administrator-/Benutzereingriffe erforderlich"
Administrator-/Benutzereingriffe erforderlich
Um Sprach- und Videokommunikationen mit Windows Messenger über einen nicht auf UPnP gestützten
Firewall zu ermöglichen, sollten Sie den Firewall so konfigurieren, dass der gesamte eingehende Datenverkehr
an den UDP-Ports 5004 bis 65535 angenommen wird.
Für sonstige Zwecke müssen Sie die folgenden Ports aktivieren:



Dateiübertragung 6891 (um 10 gleichzeitige Dateiübertragungen zuzulassen, öffnen Sie die Ports 6891
bis 6900)
Anwendungsfreigabe und Whiteboard: 1503
Remoteunterstützung: 3389
Wenn Sie ein Problem vermuten, erkundigen Sie sich beim Internetdienstanbieter, und lesen Sie in der
verfügbaren Dokumentation nach, ob die UPnP-Unterstützung eine Option ist und wie der Firewall konfiguriert
werden muss, um bestimmte Ports zuzulassen. Erkundigen Sie sich beim Internetdienstanbieter, wenn Sie ein
Problem beim Kaskadieren eines Firewalls vermuten.
Audio und Video mit Microsoft ISA Server (Internet
Security & Acceleration)
Bei AV zeichnet sich ein spezielles Szenario ab, wenn ein Server mit Microsoft ISA, der als Firewall und
Proxyserver fungiert, an der Netzwerkgrenze bereitgestellt wird, und zugleich eine SIP-Serverlösung verwendet
wird. Der Ablauf dieses Szenarios hängt vom Standort der SIP-Server im Hinblick auf den aufrufenden Client
ab.
Szenarien
Diese spezielle Situation wird in den beiden folgenden Bereitstellungsszenarien veranschaulicht:
Szenario 1: Verwenden von ISA Server als Firewall und Proxy
In diesem Szenario führt Station A den Windows Socket-Proxyclient aus. Anrufe von Station A bei Station B
oder von Station B bei Station A werden erfolgreich ausgeführt. Dies hängt mit der Art zusammen, mit der
Windows Messenger die lokale Adresse ermittelt.
Hierzu werden Sockets verwendet, um eine Verbindung mit einer Remoteadresse und dem SIP-Server
herzustellen. Die Sockets werden dann nach der verwendeten lokalen Adresse befragt. In diesem Fall ist die
empfangene Adresse die Adresse der externen Schnittstelle des ISA-Servers - Adresse X. Diese Adresse und ein
zufälliger Port werden dann an Station B in der Sitzungseinladung mithilfe von Session Description Protocol
(SDP) gesendet.
Stammt der Anruf von Station B, empfängt Station A eine Reihe von Informationen über Station B. Mithilfe
dieser Informationen, vor allem der Adresse von Station B, kann ermittelt werden, welche Adresse Station A als
Reaktion auf die Sitzungseinladung verwenden sollte (200 OK mit SDP-Informationen), wie in Abbildung 7
weiter unten dargestellt.
Abb. 7: Verwenden eines ISA-Servers als Firewall und Proxy
Szenario 2: Verwenden von ISA Server
Dieses Szenario ist leicht abgeändert. Anrufe von Station A bei Station B werden nicht erfolgreich ausgeführt,
unabhängig von den am ISA-Firewall geöffneten Ports.
Anrufe von Station B bei Station A werden so lange erfolgreich ausgeführt, wie Station A den Proxyclient
verwendet. Führt Station A den Anruf aus, wird die Adresse des SIP-Servers als Remoteadresse verwendet und
ist lokal. Die zurück erhaltene Adresse ist ebenfalls lokal. Wird sie zu einer Sitzungseinladung an Station B
hinzugefügt, kann Station B diese interne Adresse zur Kontaktaufnahme mit Station A verwenden. Als Folge
davon schlagen diese Anrufe fehl. Initiiert Station B den Anruf, kann die Adresse von Station B von den SDPDaten in der Einladung wie in Szenario 1 verwendet werden. Dieses Szenario wird in Abbildung 8 weiter unten
dargestellt.
Abb. 8: Verwenden von ISA Server
Zusammenfassung
In diesem Artikel werden verschiedene Szenarien erläutert, in denen die Voraussetzungen für die Verwendung
aller Windows Messenger-Funktionen beschrieben und mögliche Lösungen für bekannte Probleme bereitgestellt
werden.
Wenn NAT- oder Firewallgeräte zum Kommunikationspfad für Windows Messenger hinzugefügt werden,
können sich verschiedene Schwierigkeiten ergeben. Beinahe alle diese Probleme werden durch die Verwendung
UPnP-gestützter Internetgatewaygeräte behoben. Zahlreiche Hersteller integrieren diese Funktion bereits in ihre
Geräte; einige ziehen sogar die Nachrüstung älterer, aktualisierbarer Geräte mit dieser Funktion in Erwägung.
Zu den in diesem Artikel behandelten Themen gehören folgende:







Probleme mit NAT und Firewalls
NAT und Windows Messenger
Firewalls und Windows Messenger
Richtige und falsche Konfigurationen
Lösungen
Audio und Video mit ISA Server
Glossar
Glossar der verwendeten Akronyme
ALG – Application Layer Gateway oder Gateway auf Anwendungsebene
AS – Application Sharing oder Anwendungsfreigabe
AV – Audio und Video
FT – File Transfer oder Dateiübertragung
ICF – Internet Connection Firewall oder Internetverbindungsfirewall
ICS – Internet Connection Sharing oder Internetverbindungsfreigabe
IM – Instant Messaging
ISA – Internet Security and Authentication
ISP – Internet Service Provider oder Internetdienstanbieter
NAT – Network Address Translation oder Netzwerkadressübersetzung
RDP – Remote Desktop Protocol
RTC – Real Time Communication
RTP – Real-time Transport Protocol
SDP – Session Description Protocol
SIP – Session Initiation Protocol
SSL – Secure Sockets Layer
TCP – Transmission Control Protocol
UDP – User Datagram Protocol
UPnP – Universal Plug and Play
WB – Whiteboard (Freigabe)
Links zu verwandten Themen
Weitere Informationen zu Windows Messenger, das zugrunde liegende Protokoll und die Standards sowie die
Funktion im Zusammenhang mit UPnP-, NAT- und Firewallgeräten erhalten Sie, indem Sie auf folgende Links
klicken:








Inside Windows Messenger - How It Communicates
http://www.microsoft.com/windowsxp/pro/techinfo/administration/inside/default.asp
MSN Messenger Service
http://messenger.msn.de/Default.asp
bzw. http://messenger.msn.com/ (englischsprachig)
Microsoft Exchange 2000 Instant Messaging Setup
http://www.microsoft.com/exchange/techinfo/administration/2000/IMSetup.asp (englischsprachig)
RFC 2543—Session Initiation Protocol (SIP)
http://www.ietf.org/rfc/rfc2543.txt?number=2543
RFC 2327—Session Description Protocol (SDP).
http://www.ietf.org/rfc/rfc2327.txt?number=2327
Ensuring Great Experiences with NAT Traversal and Universal Plug and Play in Windows XP
http://www.microsoft.com/windowsxp/pro/techinfo/planning/networking/nattraversal.asp
(englischsprachig)
UPnP NAT Traversal FAQ
http://www.microsoft.com/windowsxp/pro/techinfo/planning/networking/natfaq.asp (englischsprachig)
Funktionen und Erweiterungen des Windows XP-Netzwerkes
http://www.microsoft.com/germany/ms/technetdatenbank/overview.asp?siteid=432800 bzw.
Windows XP Networking Features and Enhancements
http://www.microsoft.com/windowsxp/pro/techinfo/planning/networking/overview/default.asp
(englischsprachig)
Aktuelle Informationen zu Windows XP finden Sie auf unserer Website unter
http://www.microsoft.com/germany/ms/windowsxp/ bzw. http://www.microsoft.com/windowsxp
(englischsprachig).
Beim vorliegenden Dokument handelt es sich um eine Vorabversion, die vor der endgültigen kommerziellen
Freigabe der darin beschriebenen Software deutlich geändert werden kann. Die in diesem Dokument enthaltenen
Informationen stellen die behandelten Themen aus der Sicht der Microsoft Corporation zum Zeitpunkt der
Veröffentlichung dar. Da Microsoft auf sich ändernde Marktanforderungen reagieren muss, stellt dies keine
Verpflichtung seitens Microsoft dar, und Microsoft kann die Richtigkeit der hier dargelegten Informationen nach
dem Zeitpunkt der Veröffentlichung nicht garantieren.
Dieses Whitepaper dient nur zu Informationszwecken. MICROSOFT SCHLIESST FÜR DIESES DOKUMENT
JEDE GEWÄHRLEISTUNG AUS, SEI SIE AUSDRÜCKLICH ODER KONKLUDENT.
Die Benutzer/innen sind verpflichtet, sich an alle anwendbaren Urheberrechtsgesetze zu halten. Unabhängig von
der Anwendbarkeit der entsprechenden Urheberrechtsgesetze darf ohne ausdrückliche schriftliche Erlaubnis der
Microsoft Corporation kein Teil dieses Dokuments für irgendwelche Zwecke vervielfältigt oder in einem
Datenempfangssystem gespeichert oder d arin eingelesen werden, unabhängig davon, auf welche Art und Weise
oder mit welchen Mitteln (elektronisch, mechanisch, durch Fotokopieren, Aufzeichnen usw.) dies geschieht.
Microsoft Corporation kann Inhaber von Patenten oder Patentanträgen, Marken, Urheberrechten oder sonstigem
geistigen Eigentum sein, die den Inhalt dieses Dokuments betreffen. Das Bereitstellen dieses Dokuments gibt
Ihnen jedoch keinen Anspruch auf diese Patente, Marken, Urheberrechte oder auf sonstiges geistiges Eigentum,
es sei denn, dies wird ausdrücklich in den schriftlichen Lizenzverträgen von Microsoft eingeräumt.
© 2001 Microsoft Corporation. Alle Rechte vorbehalten. Microsoft, Windows und Windows NT sind entweder
eingetragene Marken oder Marken der Microsoft Corporation in den USA und/oder anderen Ländern.
Weitere in diesem Dokument aufgeführte Produkt- oder Firmennamen können geschützte Marken ihrer
jeweiligen Inhaber sein.
Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • USA