next up previous contents
Next: NetBT-Datagrammdienst Up: NetBT - Netbios über Previous: NetBT - Netbios über   Contents

NetBT-Namensdienst

Microsoft hat im Laufe der unterschiedlichen Windows-Versionen mehrmals die Methoden der Namensauflösung verändert, musste aber immer kompatibel zu den vorherigen Versionen bleiben. Das hat dazu geführt, dass die Namensauflösung bei den Windows-Betriebssystemen immer komplizierter wurde. Es werden Methoden verwendet, die den Namen durch Broadcast versuchen aufzulösen und welche, die das durch Unicast erreichen. Windowsrechner verwenden oft beides zugleich.

NETBIOS-Namen dürfen bis zu 15 Zeichen lang sein und dürfen keinen 'Punkt' im Namen enthalten30. Es werden - nicht wie bei DNS - Hierarchien unterstützt. Damit in einem größeren Netz die Probleme gleicher Rechnernamen leichter gelöst werden können, hat Microsoft NETBIOS-Bereiche eingeführt. Bereichsnamen und Rechnername zusammen dürfen maximal 255 Zeichen lang sein. Ursprünglich wurden Namen durch Broadcast-Anfragen aufgelöst. In größeren Netzen führt das zu einer erheblichen Belastung weshalb Microsoft WINS (Windows Internet Name Service) eingeführt hat. Die Namen werden auf einem WINS-Server verwaltet. Clients wenden sich per Unicast an den WINS-Server um Namen aufzulösen. Jedoch müssen trotz Einsatz von WINS auf Rechnern weiterhin Server laufen, die Broadcast-Anfragen behandeln. Ab Windows 2000 wird bevorzugt DNS zur Namensauflösung verwendet. Für Namen, die länger als 15 Zeichen sind, funktioniert die Namensauflösung nur über DNS.

Es kann vorkommen, dass Clients DNS-Antworten bekommen, obwohl keine DNS-Anfrage gestellt wurde. Das kommt daher, dass WINS-Server auch Gateways zum DNS-Dienst sein können. Umgekehrt können DNS-Server auch Gateways zu WINS-Server sein. Der 2. Fall wird deshalb verwendet, weil sich Rechner, die soeben hochgefahren werden, beim WINS-Server anmelden und deshalb dort bekannt sind. Dadurch bleiben die Daten aktuell.

In Windows stehen also folgende Möglichkeiten der Namensauflösung zur Verfügung:

Da sich Rechner je nach Betriebssystem und Konfiguration unterschiedlich verhalten (die Reihenfolge der Auflösungsversuche betreffend), verwendet Microsoft in der Literatur spezielle 'Node-Bezeichnungen':

B-Node
(Broadcast) - der Rechner führt nur Broadcast-Abfragen durch
P-Node
(Punkt-zu-Punkt) - der Rechner führt nur WINS-Abfragen durch
M-Node
(Mixed) - der Rechner versucht zuerst einen Broadcast und dann erst eine WINS-Abfrage
H-Node
(Hybrid) - der Rechner versucht zuerst eine WINS-Abfrage und dann einen Broadcast (das ist die übliche Methode bei Rechnern ab Windows-NT, welche WINS verwenden)
Um mehr Ausfallssicherheit zu erreichen, kann man mehrere WINS-Server betreiben. Die Daten werden zwischen den WINS-Servern repliziert. WINS-Server senden zunächst IGMP-Pakete, um mögliche Partner zu finden und um Multicast-Adressen anzumelden. Die Replikation selbst erfolgt über TCP-Port 42. Es werden immer Verbindungen in beiden Richtungen aufgebaut weshalb eine Firewall nicht so konfiguriert werden kann, dass Verbindungen nur in eine Richtung ermöglicht werden.

Für die Administration von fernen WINS-Servern kann ein WINS-Manager verwendet werden. Dieser benützt Microsoft-RPC (siehe Kapitelsec:RPC).

Der NetBT-Namensdienst verwendet TCP und UDP auf Port 137. TCP wird nur von Servern verwendet, oder von Clients, wenn UDP keine oder eine verstümmelte Antwort liefert. Microsoft verwendet Port 137 sowohl für Anfragen als auch für Antworten. Zur Auflösung von Namenskonflikten müssen Verbindungen in beiden Richtungen erlaubt werden. Wird kein WINS verwendet, so werden Anfragen an die Broadcastadresse gesendet. Antworten erfolgen über Unicast. WINS-Server kommunizieren untereinander über Multicast und verwenden zusätzlich IGMP. Die WINS-Replikation verwendet TCP-Port 42.

Microsoft stellt einen WINS-Proxy-Dienst zur Verfügung, welcher Broadcast-Anfragen in WINS-Anfragen umwandelt. NAT ist in der Praxis nicht verwendbar. Es werden nicht nur eingebettete Adressen verwendet, sondern es muss sich ja auch jeder Rechner registrieren wodurch keine Adressen eingespart werden können.

WINS-Anfragen und WINS-Replikationen sollen nicht über Firewalls geführt werden. Damit keine Probleme mit Bastion-Hosts entstehen, sollten die Namen entweder statisch in den WINS-Servern eingetragen werden, oder deren Namen müssen länger als 16 Zeichen sein, damit auf DNS ausgewichen werden muss.

Richtung Proto- Port
Status
Anmerkung
Client Server koll Quelle Ziel
 
         
 
>   UDP 137, 1024: 137
Broadcast!!
Anfrage an NetBT-Namensdienst über UDP, Client -> Server
>   UDP 137, 1024: 137
WINS-Anfrage über UDP, Client -> Server
  < UDP 137 137, 1024:
Antwort auf UDP-Anfrage, Server -> Client
>   TCP 137, 1024: 137
NEW, ESTABLISHED
Anfrage über TCP, Client -> Server
  < TCP 137 137, 1024:
ESTABLISHED
Antwort auf TCP-Anfrage, Server -> Client
>   TCP 1024: 42
NEW, ESTABLISHED
Replikationsanfrage eines WINS-Servers
  < TCP 42 1024:
ESTABLISHED
Antwort auf Replikationsanfrage


next up previous contents
Next: NetBT-Datagrammdienst Up: NetBT - Netbios über Previous: NetBT - Netbios über   Contents
Ernst Pisch 2003-05-17