2.11.2001

Wiederholung: DHCP-Anfragen sind Broadcasts, die durch Router normalerweise blockiert werden. Es gibt drei Möglichkeiten, dieses Manko zu umgehen. Immer wenn eine Domäne im Netz ist, müssen sich W2k-DHCP-Server am Domänencontroller autorisieren. Sobald man eine Zone einrichtet, steht im SOA-Eintrag, welcher Rechner für DNS verantwortlich ist. In einer ForwardLookup-Zone gibts Host-Einträge, die die Namen mit den IP-Adressen verbinden. Zusätzlich kann man weitere Namen für denselben Rechner vergeben. Das wäre dann ein Alias. In der ReverseLookUp-Zone nennt man diese Einträge Zeiger.

Der Nachteil bestand im allgemeinen darin, dass der DNS die Einträge des DHCP-Servers erst übernehmen muss. Vergisst man das Häkchen, funktioniert garnichts.

NetBIOS / WINS:

Eine weitere Namensauflösung ist NetBIOS über TCP/IP. Das nennt man dann WINS (Windows Internet Naming Service). NetBIOS ist mehr als nur ein Namensdienst. Dieses System war bis W2k der Standardnamensdienst für MS-Betriebssysteme. Meistens wird es deswegen für alle anderen MS-Systeme benötigt. Ausserdem ist es für Anwendungen geeignet, die NetBIOS mit einbeziehen. Im Gegensatz zu DNS ist NetBIOS auch mit IPX/SPX und NetBEUI lauffähig. Nachteilig ist, dass NetBIOS mit einem flachen Namensraum arbeitet, und damit jeder Computer einen eindeutigen Namen benötigt. Das ist der Grund, warum sich NetBIOS nicht als Netzwerkstandard im Web durchsetzte. Es fehlt die hierarchische Struktur und die Namen sind nur 16 Zeichen lang, von denen nur 15 frei wählbar sind. Das 16. Zeichen gibt den Dienst an, wobei dieser ein Name, ein Serverdienst oder ein Nachrichtendienst sein kann. Die Namen sind Not-Case-Sensitive. NetBIOS benötigt aber keinen Server, d.h. die Namensauflösung funktioniert offenbar etwas anders als bei DNS:

Bei NetBIOS ohne WINS sind drei wichtige Vorgänge erforderlich. Das sind die Namensregistrierung, die Namensauflösung und die Namensfreigabe. Wenn ein Rechner startet, sendet er einen Broadcast. Dort ist sein Name enthalten. Gibt es den Namen schon im LAN, entsteht ein Konflikt, und der Rechner ist am Netzwerk nicht vollständig beteiligt. Ist die Registrierung erfolgreich verlaufen, erfolgt die Namensauflösung. Gebe ich ein UNC-Pfad ein, schaut der Rechner erstmal in seinem NBT-Cache (NetBIOS over TCP/IP). Der Befehl lautet nbtstat -c. Als nächstes wird am NBT Knotentyp mit einem Broadcast gesucht. Hat man keinen WINS-Server, ist dieser kein Hybrid-, sondern ein Broadcastadapter. Zusätzlich gibt es die LMHOSTS-Datei im Verzeichnis winnt \ system32 \ drivers \ etc. Dort kamm man ebenfalls Einträge vornehmen. Ist diese Datei nicht vorhanden, wird sie ohne Kommentar übersprungen.

Mit der Namensfreigabe wird ebenfalls ein Broadcast gesendet, in dem mitgeteilt wird, dass der Name nicht mehr verwendet wird.

Bei NetBIOS mit WINS ist ein WINS-Server erforderlich. Der WINS-Client kennt die Adresse des WINS-Servers. Hier kann man ebenfalls mehrere WINS-Server angeben (bis zu 12) , und die Abfrage läuft wie bei DNS. Das heisst, der erste der antwortet, wird benutzt, egal, wie die Antwort lautet. Diesmal wird der Name allerdings beim WINS-Server registriert. Der WINS-Server kontrolliert seine eigene Datenbank, in der die Namensregistrierung drinsteht. Damit ist schon mal ein Broadcast pro Rechner eingespart. Es gibt mehrere Knotentypen, und je nach Knotentyp reagiert der Client: bei B (Broadcast) wird ein Broadcast an alle gesendet, bei P (Peer) wird der WINS-Server angesprochen. Es gibt ja auch M (Mixed) und H (Hybrid)-Adapter. Bei Mixed ist erst ein B, dann ein P, bei Hybrid erst ein P und dann ein B konfiguriert. Sinnvoll ist es also, einen Hybrid-Adapter einzurichten. Danach kommt wieder die LMHOSTS-Datei dran, wenn sie vorhanden und konfiguriert ist, wie bei NetBIOS ohne WINS. Beim Beenden wird dem WINS-Server mitgeteilt, dass der Name freigegeben ist. NetBIOS bietet dynamische Registrierung und damit Auflösung an. Was DNS erst seit einiger Zeit beherrscht.

Zur Konfiguration eines WINS-Servers ist es sinnvoll, ihm eine feste IP-Adresse zu vergeben. Das Installieren des Dienstes ist obligatorisch (Systemsteuerung \ Software \ Windows Komponenten \ usw.). Auf dem WINS-Client muss die IP-Adresse des WINS-Servers konfiguriert werden (Netzwerkumgebung \ TCP/IP \ Erweitert \ WINS). Ergänzenderweise gibt es eine Checkbox, ob die LMHOSTS abgefragt werden soll oder nicht. Weiterhin kann man NetBIOS über DHCP beziehen lassen.

Als Aufgabe werden wir an unserem Tisch mit dem funktionierenden DHCP- und DNS-LAN einen zusätzlichen WINS-Server einrichten.

Schauen wir uns mal eine Übersicht an:

DHCP-Server

IP-A (statisch)

DNS-Server

IP-B (statisch)

WINS-Server

IP-C (statisch)

DHCP-Client

IP-automatisch

- - - * IP automatisch (DHCP-Client)
IP-B IP-B IP-B [=> IP-B über DHCP] (DNS-Client)
IP-C IP-C IP-C [=> IP-C über DHCP] (WINS-Client)
DHCP-Server-Einstellungen:

Bereich: IP-D bis IP-X

Optionen:

6 DNS-Server IP-B
15 Domänenname test.de
44 WINS-Server IP-C
46 Knotentyp 0x8 (H)
  DDNS  
DNS-Server-Einstellungen:

Forward-Zone (primär): test.de mit dynamischer Aktualisierung: ja

Inhalt von test.de:

DHCP A (Adress/Host) IP-A
DNS A IP-B
WINS A IP-C
Client1 A IP-D
ohne DDNS alles statisch
WINS-Server-Einstellungen:

Inhalt der WINS-Datenbank:

DHCP IP-A
DNS IP-B
WINS IP-C
Client1 IP-D
wird automatisch angelegt
- erhält IP-Adresse aus Bereich D bis X

- erhält Domänennamen (DNS) test.de

Der Client, der sich am DHCP anmeldet, bekommt von ihm eine Adresse und meldet ihm daraufhin Adresse und Namen. Die teilt der DHCP dem DNS mit.

Ein Beispiel: Wir haben einen Rechner A auf der einen Seite eines Routers, Rechner B und Rechner C auf der anderen Seite. Wir möchten die NetBIOS-Konfiguration über den Router nutzen. Neben A befindet sich noch ein W2k-WINS-Server D. Eine Möglichkeit, die Clients zur Kommunikation zu bewegen, ist, die Ports 137 und 138 auf dem Router zu öffnen. Tolle Sicherheitslücken! Ne bessere Möglichkeit wäre, die LMHOSTS-Datei auf jedem Rechner zu editieren. Noch ne bessere Möglichkeit ist, den WINS-Server zu nutzen und auf den Clients einen Hybridadapter einzurichten. Somit wird erst eine direkte IP-Adresse abgefragt (Unicast) und mit dem Router gibt es keine Probleme mehr.

Zusätzlich stellen wir einen Rechner E neben C, der kein WINS-Client ist, sonder nur mit NetBIOS-Broadcasts kommunizieren kann. Da der Router auf der anderen Seite steht, wird die Kommunikation etwas erschwert. Solche Clients treten, nach Microsoft-Aussage, nur bei Windows 3.1 auf. Die Lösung: Zur Integration solcher Clients machen wir einen der anderen Clients (Rechner B oder C) im Teilnetz zum WINS-Proxy-Agent. Dieser Agent ist möglich auf allen NT- und W2k-Rechnern. Dazu ist nur ein Registry-Eintrag notwendig. Rechner B, auf dem wir den Proxy aktiviert haben, macht in dem Fall im Auftrag von Rechner E die Anfrage an den WINS-Server. Der korrekte Eintrag in der registry lautet HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\. Dort trägt man einen hexadezimalen RegDWord-Wert namens EnableProxy ein und stellt ihn auf 1.

Stellt man jetzt noch einen weiteren Rechner auf, welcher kein NetBIOS beherrscht (Rechner F). Microsoft sieht zur Integration von Rechnern, die sich in WINS überhaupt nicht registrieren können. Dafür ist nur ein statischer Eintrag in der WINS-Datenbank hilfreich. Ich lege einen Namen "F" mit der passenden Adresse ab. Ein Client, der jetzt mit Rechner F kommunizieren will, fragt den WINS-Server, bekommt von ihm die IP-Adresse von F, und kann somit mit F kommunizieren. Client F kann aber auf keinen Rechner mit NetBIOS-Namen zugreifen.