NetBIOS-Namen
Der NetBIOS-Namespace ist flach, was bedeutet, dass alle Namen innerhalb des Namespace eindeutig sein müssen. NetBIOS-Namen haben eine Länge von 16 Zeichen. Ressourcen werden mit NetBIOS-Namen bezeichnet, die dynamisch beim Booten des Computers oder beim Starten der Dienste oder Anwendungen oder beim Anmelden von Benutzern registriert werden. Namen können als eindeutige (ein Besitzer) oder als Gruppennamen (mehrere Besitzer) registriert werden. Eine NetBIOS-Namensabfrage wird verwendet, um eine Ressource durch die Auflösung des Namens in eine IP-Adresse zu suchen.
Microsoft-Netzwerkkomponenten, wie Arbeitsstationsdienst und Server, ermöglichen das Angeben der ersten 15 Zeichen eines NetBIOS-Namens durch den Benutzer oder Administrator, reservieren jedoch das 16. Zeichen des NetBIOS-Namens für die Angabe einer Ressourcenart (00-FF hex). Viele verbreitete Softwarepakete von Drittanbietern verwenden ebenfalls dieses Zeichen zur Bezeichnung und Registrierung ihrer speziellen Dienste. Tabelle 3 führt einige Beispiele für NetBIOS-Namen auf, die von Microsoft-Komponenten verwendet werden.
Tabelle 3 Beispiele für NetBIOS-Namen, die von Microsoft-Komponenten verwendet werden.
Eindeutiger Name
|
Dienst
|
computer_name[00h]
|
Arbeitsstationsdienst
|
computer_name[03h]
|
Nachrichtendienst
|
computer_name[06h]
|
RAS-Serverdienst
|
computer_name[1Fh]
|
NetDDE-Dienst
|
computer_name[20h]
|
Server
|
computer_name[21h]
|
RAS-Clientdienst
|
computer_name[BEh]
|
Network Monitor Agent
|
computer_name[BFh]
|
Network Monitor-Anwendung
|
user_name[03]
|
Nachrichtendienst
|
domain_name[1Dh]
|
Hauptsuchdienst
|
domain_name[1Bh]
|
Hauptsuchdienst der Domäne
|
Gruppenname
|
Dienst
|
domain_name[00h]
|
Domänenname
|
domain_name[1Ch]
|
Domänencontroller
|
domain_name[1Eh]
|
Auswahl Suchdienst
|
\\--__MSBROWSE__[01h]
|
Hauptsuchdienst
|
Um zu sehen, welche Namen ein Computer über NetBT registriert hat, geben Sie Folgendes an der Eingabeaufforderung ein:
nbtstat -n
Windows 2000 ermöglicht Ihnen das erneute Registrieren von Namen beim Namenserver, nachdem ein Computer bereits gestartet wurde. Geben Sie dafür an der Eingabeaufforderung Folgendes ein:
nbtstat –RR
Registrierung und Auflösung des NetBIOS-Namens
Die Windows TCP/IP-Systeme verwenden mehrere Methoden, um NetBIOS-Ressourcen zu suchen:
NetBIOS-Namenzwischenspeicher
NetBIOS-Namenserver
IP-Subnetz-Broadcasts
Statische Lmhosts-Datei
Lokaler Hostname (optional, abhängig vom Registierungsparameter EnableDns)
Datei der statischen Hosts (optional, hängt vom Registrierungsparameter EnableDns ab)
DNS-Server (optional, hängt vom Registrierungsparameter EnableDns ab)
Die Reihenfolge der NetBIOS-Namensauflösung hängt vom Knotentyp und von der Systemkonfiguration ab. Die folgenden Knotentypen werden unterstützt:
B-Knoten verwendet Broadcasts für die Namensregistrierung und -auflösung.
P-Knoten verwendet einen NetBIOS-Namenserver (wie WINS) für die Registrierung und Auflösung von Namen.
M-Knoten verwendet Broadcasts für die Registrierung von Namen. Für die Namensauflösung testet es die Broadcasts zuerst, schaltet dann aber um auf den P-Knoten, wenn es keine Antwort erhält.
H-Knoten verwendet einen NetBIOS-Namenserver sowohl für die Registrierung als auch für die Auflösung von Namen. Wenn jedoch kein Namenserver gefunden werden kann, wird auf den B-Knoten umgeschaltet. Er sucht weiterhin nach einem Namenserver und schaltet zurück zum P-Knoten, wenn einer verfügbar wird.
Microsoft-enhanced verwendet die lokale LMHOSTS-Datei oder WINS-Proxys und gethostbyname-Aufrufe von Windows Sockets (mit Standard-DNS und/oder lokalen Hosts-Dateien) zusätzlich zu Standardknotentypen.
Microsoft stellt einen NetBIOS-Namenserver bereit, der unter dem Namen WINS (Windows Internet Name Service) angeboten wird. Die meisten WINS-Clients sind als H-Knoten eingerichtet, d. h. sie versuchen zuerst, Namen mit WINS zu registrieren und aufzulösen, und falls dies nicht gelingt, versuchen sie es mit lokalen Subnetz-Broadcasts. Das Verwenden eines Namenservers zum Suchen von Ressourcen ist generell aus zwei Gründen dem Broadcasting vorzuziehen:
Broadcasts werden gewöhnlich nicht von Routern weitergeleitet.
Broadcasts werden von allen Computern in einem Subnetz empfangen und nehmen auf jedem Computer Zeit für die Verarbeitung in Anspruch.
NetBIOS-Namensregistrierung und -auflösung für mehrfach vernetzte Computer
Wie bereits erwähnt, stellt NetBT eine Verbindung nur zu einer IP-Adresse pro physischer Netzwerkschnittstelle her. Aus der Sicht von NetBT ist ein Computer nur dann mehrfach vernetzt, wenn darauf mehr als eine NIC installiert ist. Wenn ein Datenpaket für die Namensregistrierung von einem mehrfach vernetzten Computer gesendet wird, wird es als mehrfach vernetzte Namensregistrierung gekennzeichnet, so dass kein Konflikt auftritt, wenn derselbe Name von einer anderen Schnittstelle auf demselben Computer registriert wird.
Wenn ein mehrfach vernetzter Computer eine Broadcastnamensabfrage erhält, antworten alle NetBT/Schnittstellenbindungen, die die Anfrage erhalten, mit ihren Adressen. Standardmäßig wählt der Client die erste Antwort und stellt eine Verbindung zu der darin enthaltenen Adresse her. Dieses Verhalten wird von dem Registrierungsparameter RandomAdapter gesteuert, der in Anhang B beschrieben wird.
Wenn eine gerichtete Namensabfrage an einen WINS-Server gesendet wird, antwortet der WINS-Server mit einer Liste aller IP-Adressen, die von dem mehrfach vernetzten Computer bei WINS registriert wurden.
Das Auswählen der besten IP-Adresse für die Verbindung zu einem mehrfach vernetzten Computer ist eine Clientfunktion. Gegenwärtig wird der folgende Algorithmus in der angegebenen Reihenfolge angewendet:
Wenn eine der IP-Adressen in der Antwortliste für die Namensabfrage sich in demselben logischen Subnetz befindet wie die rufende Bindung von NetBT auf dem lokalen Computer, wird diese Adresse ausgewählt. Wenn mehr als eine Adresse diese Kriterien erfüllen, wird von den passenden eine per Zufall ausgewählt.
Wenn eine der IP-Adressen in der Liste sich in demselben (klassenlosen) Netzwerk befindet wie die rufende Bindung von NetBT auf dem lokalen Computer, wird diese Adresse ausgewählt. Wenn mehr als eine Adresse diese Kriterien erfüllen, wird von den passenden eine per Zufall ausgewählt.
Wenn eine der IP-Adressen in der Liste sich in demselben logischen Subnetz befindet wie eine Bindung von NetBT auf dem lokalen Computer, wird diese Adresse ausgewählt. Wenn mehr als eine der Adressen diese Kriterien erfüllen, wird eine davon per Zufall ausgewählt.
Wenn keine der IP-Adressen in der Liste sich in demselben Subnetz befindet wie eine Bindung von NetBT auf dem lokalen Computer, wird eine Adresse nach dem Zufallsprinzip aus der Liste ausgewählt.
Dieser Algorithmus ist ein ziemlich gutes Verfahren, Verbindungen zu einem Server über mehrere NCIs zu verteilen und gleichzeitig die direkten Verbindungen (dasselbe Subnetz) zu bevorzugen, wenn diese verfügbar sind. Wenn eine Liste von IP-Adressen zurückgegeben wird, werden sie in der besten Reihenfolge sortiert, und NetBT versucht, jede der Adressen in der Liste per Ping anzusprechen, bis eine davon reagiert. NetBT versucht dann, eine Verbindung zu dieser Adresse aufzubauen. Wenn keine der Adressen antwortet, wird dennoch versucht, eine Verbindung zu der ersten Adresse in der Liste aufzubauen. Dies wird für den Fall versucht, dass eine Firewall oder ein anderes Gerät, den ICMP-Verkehr filtert. Windows 2000 unterstützt die NetBT-Namenszwischenspeicherung pro Schnittstelle und nbtstat -c zeigt den Namenszwischenspeicher für jede einzelne Schnittstelle an.
Verbesserungen an NetBT Internet/DNS und das SMB-Gerät
Es war immer schon möglich, mit NetBT über das Internet eine Verbindung zwischen zwei Windows-basierten Computern herzustellen. Dafür musste ein Hilfsmittel für die Namensauflösung bereitgestellt werden. Zwei weit verbreitete Methoden waren die Verwendung der Lmhosts-Datei oder eines WINS-Servers. Schon in Windows NT 4.0 wurden verschiedene Verbesserungen eingeführt, die dann in Windows 2000 übernommen wurden, um diese speziellen Konfigurationsanforderungen überflüssig zu machen.
Es ist jetzt möglich, eine Verbindung zu einer NetBIOS über TCI/IP-Ressource auf zwei neue Weisen herzustellen:
Mit dem Befehl net use \\ip address\share_name. Dadurch entfällt die Konfiguration der NetBIOS-Namensauflösung.
Mit dem Befehl net use \\FQDN\share_name. Dies ermöglicht die Verwendung einer DNS zur Herstellung einer Verbindung zu einem Computer mit seinem voll gekennzeichneten Domänennamen (Fully Qualified Domain Name, FQDN).
Beispiele für das Verwenden der neuen Funktionalität zur Zuordnung eines Laufwerks zu ftp.microsoft.comsehen Sie unten. Die hier aufgeführte IP-Adresse kann sich jedoch ändern.
net use f: \\ftp.microsoft.com\data
net use \\198.105.232.1\data
net view \\198.105.232.1
dir \\ftp.microsoft.com\bussys\winnt
Darüber hinaus können Sie in verschiedenen Anwendungen, wie mit der Option Computer auswählen im Menü Protokoll der Ereignisanzeige von Windows NT 4.0 einen FQDN oder eine IP-Adresse direkt eingeben. Unter Windows 2000 ist es auch möglich, mit dem Direct Hosting Redirectordienst- oder Serververbindungen zwischen Windows 2000-Computern ganz ohne die Verwendung des NetBIOS-Namespace oder der Zuordnungsschicht herzustellen. Standardmäßig versucht Windows, Verbindungen mithilfe beider Methoden herzustellen, so dass es Verbindungen zu Computern einer niedrigeren Ebene unterstützen kann. In reinen Windows 2000-Umgebungen können Sie jedoch NetBIOS vollständig aus dem Ordner Netzwerkverbindungen herausnehmen.
Die neue Schnittstelle in Windows 2000, die NetBIOS-lose Vorgänge ermöglicht, wird als SMB-Gerät bezeichnet. Für den Redirectordienst und den Server sieht sie wie eine ganz normale Schnittstelle aus, ähnlich einer einzelnen Kombination aus Netzwerkadapter und Protokollstapel. Am TCP/IP-Stapel jedoch ist das SMB-Gerät mit ADDR_ANY gebunden, und es verwendet den DNS-Namespace nativ, ganz wie eine Windows Sockets-Anwendung. Aufrufe des SMB-Geräts führen zu einem standardmäßigen DNS-Lookup, um den (DNS)-Namen einer IP-Adresse zuzuordnen, gefolgt von einer einzigen ausgehenden Verbindungsanforderung (selbst auf einem mehrfach vernetzten Computer) mit der besten Quell-IP-Adresse und Schnittstelle, die aufgrund der Routingtabelle ermittelt wurde. Außerdem ist kein Einrichten einer NetBIOS-Sitzung zusätzlich zur TCP-Verbindung erforderlich, wie dies beim traditionellen NetBIOS über TCP/IP der Fall ist. Standardmäßig schickt der Redirectordienst Aufrufe sowohl zu dem (den) NetBIOS-Gerät(en) als auch zum SMB-Gerät, und der Dateiserver empfängt beide Aufrufe. Das Dateiserver-SMB-Gerät hört den TCP-Port 445 ab statt wie beim traditionellen NetBIOS über TCP den Port 139.
NetBIOS über TCP-Sitzungen
NetBIOS-Sitzungen werden zwischen zwei Namen aufgebaut. Beispielsweise läuft die folgende Sequenz von Ereignissen ab, wenn eine Windows 2000 Professional-basierte Workstation eine Verbindung zur Dateifreigabe an einen Server mit NetBIOS über TCP/IP aufbaut:
Der NetBIOS-Name für den Server wird in eine IP-Adresse aufgelöst.
Die IP-Adresse wird in eine MAC-Adresse aufgelöst.
Eine TCP-Verbindung wird von der Workstation zum Server unter Verwendung von
Port 139 aufgebaut.
Die Workstation sendet eine NetBIOS-Sitzungsanforderung an den Servernamen über die TCP-Verbindung. Wenn der Server nach dem Namen abhört, signalisiert er seine Zustimmung, und es wird eine Sitzung begonnen.
Wenn die NetBIOS-Sitzung begonnen worden ist, handeln die Workstation und der Server aus, welche Ebene des SMB-Protokolls verwendet werden soll. Das Microsoft-Netzwerk verwendet zu einem gegebenen Zeitpunkt nur eine NetBIOS-Sitzung zwischen zwei Namen. Für alle zusätzlichen Verbindungen zur Freigabe von Dateien oder Druckern wird über dieselbe NetBIOS-Sitzung mit Bezeichnern im SMB-Header ein Multiplexing durchgeführt.
NetBIOS-Keepalives werden bei jeder Verbindung verwendet, um zu überprüfen, ob sowohl der Server als auch die Workstation noch in der Lage sind, ihre Sitzung fortzuführen. Wenn also eine Workstation vorzeitig die Sitzung beendet, bereinigt der Server die Verbindung und die entsprechenden Ressourcen, und umgekehrt. NetBIOS-Keepalives werden von dem Registrierungsparameter SessionKeepAlive gesteuert und sind standardmäßig auf einmal pro Stunde eingestellt.
Wenn LMHOSTS-Dateien verwendet werden und diese einen falsch geschriebenen Eintrag enthalten, ist es möglich, den Verbindungsaufbau zum Server mit der richtigen IP-Adresse aber mit einem falschen Namen zu versuchen. In diesem Fall wird die TCP-Verbindung zum Server dennoch hergestellt. Jedoch wird die NetBIOS-Sitzungsanforderung (mit dem falschen Namen) von dem Server abgelehnt, da für diesen Namen kein Abhören vorgesehen ist. Ein Fehler 51, "Remotecomputer wartet nicht", wird zurückgegeben.
NetBIOS-Datagrammdienste
Datagramme werden von einem NetBIOS-Namen zu einem anderen über den UDP-Port 138 gesendet. Der Datagrammdienst bietet die Möglichkeit, eine Meldung an einen eindeutigen Namen oder einen Gruppennamen zu senden. Gruppennamen können einer Liste von IP-Adressen oder einem Broadcast zugeordnet werden. Beispielsweise sendet der Befehl net send /d:mydomain test ein Datagramm mit dem Text "test" an den Gruppennamen mydomain[03]. Der Name mydomain[03] wird in ein IP-Subnetz-Broadcast aufgelöst, so dass das Datagramm mit den folgenden Charakteristika versendet wird:
Ziel-MAC-Adresse: Broadcast (FFFFFFFFFFFF).
Quell-MAC-Addresse: Die NIC-Adresse des lokalen Computers.
Ziel-IP-Adresse: Die lokale Subnetz-Broadcastadresse.
Quell-IP-Adresse: Die IP-Adresse des lokalen Computers.
Zielname: mydomain[03h] (der Nachrichtendienst auf den Remotecomputern).
Quellname: Benutzername[03h] (der Nachrichtendienst auf dem lokalen Computer).
Alle Hosts in dem Subnetz nehmen das Datagramm an und verarbeiten es mindestens bis zur UDP-Protokollschicht. Auf Hosts, die einen NetBIOS-Datagrammdienst ausführen, gibt UDP das Datagramm auf Port 138 an NetBT weiter. NetBT prüft den Zielnamen, um zu sehen, ob eine Anwendung einen Datagrammempfang dafür gemeldet hat, und wenn dies der Fall ist, leitet er das Datagramm dahin weiter. Wenn kein Empfang gemeldet wird, wird das Datagramm verworfen.
Wenn die NetBIOS-Unterstützung in Windows 2000 deaktiviert wird (wie weiter oben in diesem Abschnitt beschrieben), stehen keine NetBIOS-Datagrammdienste zur Verfügung.
Kritische Clientdienste und Stapelkomponenten
Der Schwerpunkt dieses Whitepapers liegt auf den KernTCP/IP-Stapelkomponenten, nicht auf den vielen verfügbaren Diensten, die das Protokoll verwenden. Jedoch stützt sich der Stapel selbst auf ein paar Dienste für Konfigurationsdaten und für die Auflösung von Namen und Adressen. Einige dieser kritischen Clientdienste werden hier erläutert.
Automatische Clientkonfiguration und Media Sense
Einer der wichtigsten Clientdienste ist der DHCP-Client (Dynamic Host Configuration Protocol). Der DHCP-Client spielt eine größere Rolle in Windows 2000. Seine wichtigste neue Funktion ist die Fähigkeit, eine IP-Adresse und Subnetzmaske automatisch zu konfigurieren, wenn der Client auf einem kleinen privaten Netzwerk gestartet wird, ohne dass ein DHCP-Server für die Zuweisung von Adressen (wie z. B. ein Heimnetzwerk) verfügbar ist. Eine weitere neues Funktion ist die Unterstützung von Media Sense, wodurch das Roaming für Benutzer von tragbaren Geräten verbessert werden kann.
Wenn ein Microsoft TCP/IP-Client installiert wird und auf das dynamische Erhalten von TCP/IP-Protokollkonfigurationsinformationen von einem DHCP-Server festgelegt ist (anstatt manuell mit einer IP-Adresse und anderen Parametern konfiguriert zu werden), wird der DHCP-Client jedes Mal eingesetzt, wenn der Computer neu gestartet wird. Der DHCP-Client verwendet nun einen zweistufigen Prozess zum Konfigurieren des Clients mit einer IP-Adresse und anderen Konfigurationsinformationen.
Wenn der Client installiert ist, versucht er einen DHCP-Server zu finden und von dort eine Konfiguration zu erhalten. Viele TCP/IP-Netzwerke verwenden DHCP-Server, die administrativ so konfiguriert sind, dass sie Informationen an Clients im Netzwerk ausgeben. Wenn dieser Versuch, einen DHCP-Server zu finden, fehlschlägt, konfiguriert der Windows 2000 DHCP-Client seinen Stapel automatisch mit einer ausgewählten IP-Adresse aus dem von der IANA (Internet Assigned Numbers Authority) reservierten Klasse B-Netzwerk 169.254.0.0 mit der Subnetzmaske 255.255.0.09 . Der DHCP-Client testet (mit einer unbegründeten ARP-Anfrage), ob die gewählte IP-Adresse nicht schon verwendet wird. Wenn sie verwendet wird, wählt er eine andere IP-Adresse (dies macht er mit bis zu 10 Adressen). Nachdem der DHCP-Client eine Adresse gewählt hat, die nachweislich nicht verwendet wird, konfiguriert er die Schnittstelle mit dieser Adresse. Er überprüft weiterhin alle 5 Minuten im Hintergrund, ob ein DHCP-Server vorhanden ist. Wenn ein DHCP-Server gefunden wird, werden die Informationen der automatischen Konfiguration aufgegeben und die von dem DHCP-Server angebotene Konfiguration wird stattdessen verwendet. Diese Funktion der automatischen Konfiguration wird als APIPA (Automatic Private IP Addressing) bezeichnet und ermöglicht einzelnen Subnetz-, Homeoffice- oder kleinen Firmennetzwerken die Verwendung von TCP/IP ohne statische Konfiguration oder die Administration eines DHCP-Servers.
Wenn der DHCP-Client zuvor ein Lease von einem DHCP-Server erhält, treten diese Ereignisse in der folgenden Reihenfolge ein:
Wenn das Lease des Clients beim Start noch gültig ist (nicht abgelaufen), versucht der Client, sein Lease beim DHCP-Server zu verlängern. Wenn der Client während des Verlängerungsversuchs keinen DHCP-Server findet, versucht er, das Standardgateway mit einem Pingsignal zu erreichen, das in dem Lease aufgeführt ist. Wenn das Pingsignal beim Standardgateway erfolgreich ist, nimmt der DHCP-Client an, dass es sich noch auf demselben Netzwerk befindet, in dem er sein aktuelles Lease erhalten hat und verwendet das Lease weiter. Standardmäßig versucht der Client, sein Lease im Hintergrund zu verlängern, wenn die Hälfte der ihm zugewiesenen Leasegültigkeit abgelaufen ist.
Wenn der Versuch, das Standardgateway mit einem Pingsignal zu erreichen, fehlgeschlagen ist, nimmt der Client an, dass es in ein Netzwerk verschoben wurde, das gegenwärtig keine DHCP-Dienste zur Verfügung stellt (wie ein Heimnetzwerk) und konfiguriert sich wie oben beschrieben automatisch selbst. Nach dem automatischen Konfigurieren versucht er im Hintergrund alle 5 Minuten, einen DHCP-Server zu finden.
Die Unterstützung von Media Sense wurde unter NDIS 5.0 hinzugefügt. Sie stellt einen Mechanismus für die Netzwerkschnittstellenkarte (NIC) zur Benachrichtigung des Protokollstapels über die Medienereignisse Anschließen und Trennen bereit. Windows 2000 TCP/IP verwendet diese Benachrichtigungen zur Unterstützung der automatischen Konfiguration. Wenn beispielsweise unter Windows NT 4.0 ein tragbarer Computer gefunden und DHCP in einem Ethernetsubnetz konfiguriert und dann ohne erneutes Starten auf ein anderes Subnetz verschoben wurde, erhielt der Protokollstapel keinen Hinweis auf diese Verlagerung. Das bedeutet, dass die Konfigurationsparameter veralteten und nicht mehr relevant für das neue Netzwerk waren. Wenn der Computer abgeschaltet, nach Hause getragen und neu gestartet wurde, wusste der Protokollstapel außerdem nicht, dass die NIC nicht mehr an ein Netzwerk angeschlossen war und wiederum blieben veraltete Konfigurationsparameter bestehen. Dies könnte problematisch sein, da Subnetzrouten, Standardgateways usw. im Konflikt zu DFÜ-Parametern stehen können.
Durch die Unterstützung von Media Sense kann der Protokollstapel auf Ereignisse reagieren und veraltete Parameter entwerten. Wenn beispielsweise ein Computer, auf dem Windows 2000 ausgeführt wird, vom Netzwerk getrennt wird (angenommen, die NIC unterstützt Media Sense), macht TCP/IP die mit dem abgetrennten Netzwerk verbundenen Parameter nach einer Dämpfungszeit, die im Stapel (gegenwärtig 3 Sekunden) implementiert ist, ungültig. Die IP-Adresse(n) lassen kein Senden mehr zu und alle der Schnittstelle zugeordneten Routen werden ungültig gemacht. Sie können den Status der Netzwerkverbindungen in der Taskleiste sichtbar machen, indem Sie eine Verbindung auswählen, auf Eigenschaften klicken und das Kontrollkästchen Symbol bei Verbindung in der Taskleiste anzeigen aktivieren. Das Symbol der Netzwerkverbindung wird automatisch mit einem roten "X" angezeigt, wenn der Adapter Verbindungssprobleme hat.
Wenn eine Anwendung an ein Socket gebunden ist, das eine ungültig gemachte Adresse verwendet, sollte sie das Ereignis verarbeiten und auf adäquate Weise reagieren, wie z. B. durch einen Versuch, eine andere IP-Adresse auf dem System zu verwenden oder den Benutzer über das Trennen zu informieren.
|
