LMHOSTS statt WINS
Auf der Ebene von TCP/IP werden IP-Adressen wie 192.168.1.10
verwendet, um Knoten wie PCs, Server oder Router in einem Netzwerk zu identifizieren. Damit Anwender sinnvoll im Netzwerk arbeiten können, muss die 12stellige IP-Adresse in freundliche und einfach zu merkende Namen wie etwa
www.box24.ch oder server1 umgewandelt werden.
Dazu kann auf unterschiedliche Verfahren zurückgegriffen werden, dies hängt von der Art der Namen ab: Bei NT und anderen Windows-Versionen gibt es grundsätzlich zwei unterschiedliche
Namenstypen. Da sind zum einen die Internet-Namen wie www.box24.ch, deren Auflösung über einen DNS-Server oder die lokale HOSTS
-Datei erfolgt. Zum anderen gibt es die NetBIOS-Namen wie server1, die von Windows NT als Computernamen verwendet werden. Im Gegensatz zu den
Internet-Bezeichnungen kommen hier Verfahren wie WINS (Windows Internet Name Service), die lokale LMHOSTS oder Broadcasts zum Einsatz.
WINS oder LMHOSTS?
Bei WINS handelt es sich um einen serverbasierenden Mechanismus. Ein Client, der etwa auf server1
zugreifen möchte, sendet eine Anfrage an einen WINS-Server, der darauf die IP-Adresse des Servers zurückliefert. Dies ist praktisch, wenn es um kleine Netzwerke geht. In grösseren, gerouteten Netzwerken verursacht dieses Verfahren aber eine nicht unerhebliche Netzlast. Zudem kann die Konfiguration von WINS mit der steigenden Komplexität des Netzwerks sehr anspruchsvoll werden.
Die LMHOSTS
dagegen ist eine lokale Datei, in der die Zuordnungsinformationen gespeichert werden. Sie muss auf jedem Client lokal vorhanden sein. Das Problem beim Einsatz der LMHOSTS ist vor allem die Pflege. Werden neue Server oder Clients dem Intranet hinzugefügt oder IP-Adressen geändert, muss auch die LMHOSTS-Datei auf allen Clients aktualisiert werden. Auf den ersten Blick scheint LMHOSTS kein besonders sinnvoller Mechanismus zu sein, wenn es doch mit WINS eine Server-basierende Alternative gibt. Aufgrund der oben erwähnten Nachteile ist es aber empfehlenswert, WINS in grösseren, gerouteten Umgebungen nur in den entsprechenden Subnetzen einzusetzen.
Wenn überwiegend auf Server im lokalen Subnetz zugegriffen wird und nur in Ausnahmefällen oder für besondere Anwendungen (wie beispielsweise Datenbank-Abfragen oder der Zugriff auf einen
SNA-Server) mit Servern in anderen Subnetzen gearbeitet werden muss, ist es oft viel einfacher, die Zuordnung von NetBIOS-Namen dieser wenigen Server in LMHOSTS-Dateien zu speichern. Für
den Zugriff auf lokale Server wird dann weiterhin WINS genutzt.
Alternativ kann im Subnetz aber auch mit Broadcasts gearbeitet werden. In diesem Fall sendet ein Client, der auf einen Server zugreifen möchte, eine Rundsendung (Broadcast) an alle
Rechner im Subnetz, in der er fragt, wer denn nun server1
ist und welche IP-Adresse er hat. Da Broadcasts bei TCP/IP aber nicht geroutet werden, lässt sich dieses Verfahren nur im lokalen Subnetz verwenden.
Reihenfolge der Auflösungs-Verfahrung
Nachdem Windows NT mehrere Formen der Namensauflösung für NetBIOS-Namen unterstützt, muss es folgerichtig auch die Möglichkeit geben, die Reihenfolge zu steuern, in der diese Mechanismen
verwendet werden. Die Basis dafür bilden die NetBIOS-Knotentypen. Wie aus der untenstehenden Tabele ersichtlich ist, wird bei allen Varianten erst im NetBIOS-Namens-Cache nachgesehen. Dabei
handelt es sich um einen lokalen Cache, in dem die zuletzt verwendeten Zuordnungen von IP-Adressen und NetBIOS-Namen gespeichert sind. Es macht offensichtlich Sinn, zunächst dort
nachzuschauen, bevor auf das Netzwerk zugegriffen wird. Als Standard sind 16 Einträge in diesem Namens-Cache gespeichert, was für den normalen Client-Einsatz, bei dem typischerweise nur auf
wenige verschiedene Server zugegriffen wird, problemlos ausreicht.
Die LMHOSTS wird immer erst dann durchsucht, wenn die anderen Varianten der Namensauflösung fehlgeschlagen sind. Das bedeutet, dass die LMHOSTS normalerweise nicht für die Namensauflösung
im lokalen Subnetz verwendet wird, da dafür die Broadcasts eingesetzt werden können. Die LMHOSTS ist vielmehr die Alternative für Einsatzbereiche, in denen Server in entfernten Subnetzen
gefunden werden sollen, ohne dass WINS verwendet wird.
Als Knotentypen bieten sich damit entweder der B-Knoten oder der H-Knoten an:
B-Knoten
Diese Reihenfolge wird verwendet, wenn kein WINS-Server vorhanden ist. In diesem Fall wird für Zugriffe auf lokale Systeme eine Namensauflösung über Broadcasts verwendet, während das
Anwählen von Servern in anderen Subnetzen via LMHOSTS geschieht.
H-Knoten
Falls dagegen im lokalen Subnetz ein WINS-Server eingesetzt wird, ist der H-Knoten die ideale Lösung. Broadcasts werden in diesem Fall zur Sicherheit eingesetzt, falls der WINS-Server
einmal nicht verfügbar sein sollte. Für Zugriffe auf Systeme in anderen Subnetzen, die dem WINS-Server nicht bekannt sind, wird im Anschluss in der LMHOSTS nachgesehen.
Tabelle Knotentypen
Windows NT unterstützt vier verschiedene Reihenfolgen für die Namensauflösung. Diese sind in der Tabelle aufgeführt. Die Knotentypen können wahlweise über DHCP durch Verwendung der Option
0x46 oder direkt in der Registry konfiguriert werden. In der Registry steht der Knotentyp im Schlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters
als Wert DHCPNodeType. Die möglichen Werte sind ebenfalls in der Tabelle angegeben. Wenn kein WINS-Server angegeben wird, wird der Knotentyp automatisch auf den
H-Knoten gesetzt.
Knotentyp
|
Reihenfolge der Namensauflösung
|
Wert
|
B-Knoten (Broadcast)
|
NetBIOS-Namens-Cache, Broadcast
|
1
|
P-Knoten (Point-to-Point-Knoten)
|
NetBIOS-Namens-Cache, WINS-Server
|
2
|
M-Knoten (Mixed-Knoten)
|
NetBIOS-Namens-Cache, Broadcast, WINS-Server
|
4
|
H-Knoten (Hybrid-Knoten)
|
NetBIOS-Namens-Cache, WINS-Server, Broadcast
|
8
|
Aktivieren von LMHOSTS
Bevor NT Workstation für die Namensauflösung überhaupt in der LMHOSTS-Datei nachsieht, muss dem System mitgeteilt werden, dass dieses Verfahren zum Einsatz kommen soll. Um LMHOSTS zu
aktivieren, muss im Bereich Netzwerk der Systemsteuerung das Register Protokolle angewählt
werden. Bei den Eigenschaften des TCP/IP-Protokolls wird nun im Bereich WINS-Adresse die Option LMHOSTS-Abfrage aktivieren
ausgewählt. Hier kann auch eine LMHOSTS importiert werden. Das ist vor allem bei der Installation von Bedeutung, wenn bereits während des Setups auf
einen Server in einem anderen Subnetz zugegriffen werden soll. Über diese Schaltfläche kann so eine LMHOSTS-Datei von einer Diskette importiert werden.
Die Struktur der LMHOSTS
In der Regel wird die LMHOSTS aber direkt auf dem System editiert oder in das richtige Verzeichnis kopiert. Die LMHOSTS findet sich im Verzeichnis %systemroot%\system32\drivers\etc
. Dort steht allerdings standardmässig nur eine Datei mit dem Namen LMHOSTS.SAM. Diese Beispieldatei kann als Basis für die Erstellung der eigenen LMHOSTS
verwendet werden. Sie muss dann allerdings noch umbenannt werden, da die LMHOSTS keine Dateitypendung besitzen darf. Ausserdem sollten die vielen Kommentare aus der Beispieldatei
gelöscht werden. Da die LMHOSTS sequentiell gelesen wird, erhöhen diese den Verarbeitungsaufwand. Ein simples Beispiel für eine LMHOSTS-Datei:
# Beispiel 192.168.144.10 Server11 192.168.144.11 Server13 192.168.144.12 Server14
|
Die LMHOSTS besteht zunächst einfach aus einer Liste von IP-Adressen und den entsprechenden Servernamen. Die Struktur unterscheidet sich bis auf den Unterschied zwischen Internet-Namen
und NetBIOS-Namen nicht von der HOSTS-Datei.
Die Parameter der LMHOSTS
Zusätzlich zu diesen Grundinformationen können bei der LMHOSTS aber noch eine Reihe von Parametern genutzt werden (siehe nachfolgende Tabelle), um besondere Systeme erkennen und
den Umgang mit der LMHOSTS effizienter gestalten zu können. Von den Parametern sind vor allem #PRE, #DOMund#INCLUDE von Bedeutung.
Mit #PRE können Einträge beim Systemstart in den NetBIOS-Namens-Cache geladen werden. Sie
bleiben dort dauerhaft stehen. Normalerweise verfallen solche Einträge nach zehn Minuten. Mit #PRE
müssen sowohl die Verweise auf Domänencontroller ausserhalb des lokalen Subnetzes, bei denen gegebenenfalls eine Anmeldung erfolgen muss, als auch die Namensinformation für Server, die bei
#INCLUDE angegeben sind, geladen werden. Diese Informationen werden unabhängig vom Knotentyp eingelesen. Dazu ein Beispiel: Wenn sich ein Benutzer an einer Windows NT
Workstation im Netzwerk anmeldet, muss auf einen Domänencontroller zugegriffen werden. Dieser kann über Broadcasts gefunden werden, wenn er im lokalen Subnetz steht. Ist das hingegen
nicht der Fall, muss seine IP-Adresse bekannt sein. Für die Anmeldung muss diese Information aber bereits im NetBIOS-Namens-Cache stehen, in den sie mit #PRE
geladen wird. Damit erkannt wird, dass es sich um einen Domänencontroller handelt, muss zudem noch die Option #DOM angegeben werden:
192.168.144.10 Server11 #PRE #DOM:Domaene1 192.168.144.11 Server13 192.168.144.12 Server14
|
Zentrale LMHOSTS Informationen
Der dritte wichtige Parameter ist #INCLUDE. Damit können Teile der LMHOSTS von einem Server
geladen werden. Statt also alle Informationen in die lokale LMHOSTS zu schreiben, werden dort nur Verweise auf wenige Server wie den Domänencontroller und die Systeme, von denen Teile der
LMHOSTS geladen werden sollen, aufgenommen. Änderungen an der LMHOSTS lassen sich dann in den meisten Fällen in der zentralen Datei vornehmen. Ein Beispiel mit dem #INCLUDE
-Parameter:
192.168.144.13 Server11 #PRE #DOM:Domaene1 192.168.144.14 Server13 #PRE 192.168.144.15 Server14 #PRE #BEGIN_ALTERNATE #INCLUDE Server13/Files\LMHOSTS
#INCLUDE Server14/Files\LMHOSTS #END_ALTERNATE
|
In diesem Beispiel werden auch die Parameter #BEGIN_ALTERNATE UND #END_ALTERNATE verwendet. Damit werden die #INCLUDE
-Anweisungen der Reihe nach durchgearbeitet, bis ein Server gefuden wird und die Datei geladen werden kann. Falls der Zugriff auf Server13 funktioniert, wird nicht mehr auf Server14
zugegriffen.
Die Verwendung von #INCLUDE hat allerdings auch einen Haken: Anweisungen aus der zentralen Datei, die nicht mit #PRE
gekennzeichnet werden, verfallen standardmässig ebenfalls nach zehn Minuten und werden dann aus dem NetBIOS-Namens-Cache gelöscht. Beim nächsten Zugriff auf einen solchen Server muss die
#INCLUDE-Anweisung also erneut ausgeführt werden, wodurch das Netzwerk höher belastet wird.
Zusätzlich muss auf den Servern, von denen Teile der LMHOSTS geladen werden, der Wert NullSessionShares in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
mit dem Datentyp REG_MULTI_SZ so angepasst werden, dass die Freigabe, von der diese Dateien geladen werden, darin aufgeführt ist. Im obigen Beispiel wäre das die Freigabe
Files. Damit kann ein anonymer Zugriff auf diese Freigabe erfolgen, der beim Systemstart notwendig ist. Da die erste Ausführung der #INCLUDE
-Anweisung vor dem Login erfolgt, kann der Zugriff auch nicht im Kontext eines bestimmten Benutzers erfolgen, er muss anonym stattfinden.
Tabelle Parameter der LMHOSTS
Parameter
|
Bedeutung
|
#BEGIN_ALTERNATE
|
Dieser Parameter wird verwendet, um mehrere #INCLUDE-Anweisungen zu gruppieren. Die Abarbeitung dieser Einträge wird beendet, so bald eine #INCLUDE-Anweisung zum Erfolg führt.
|
#END_ALTERNATE
|
Dieses Kommando kennzeichnet das Ende der hinter #BEGIN_ALTERNATE stehenden #INCLUDE-Anweisungen.
|
#DOM:Domäne
|
Gibt an, dass es sich bei dem entsprechenden Eintrag um einen Domänencontroller in der nach dem Schlüsselwort angegebenen Domäne handelt.
|
#INCLUDE Dateiname
|
Lädt die angegebene Datei, die durch einen lokalen oder einen UNC-Pfadnamen angegeben wird.
|
#MH
|
Dieser Parameter legt fest, dass es sich um einen Computer handelt, der über mehrere Netzwerkadapter mit einem lokalen Subnetz verbunden ist. Der Parameter muss hinter jedem Eintrag
für diesen Computer angegeben werden. Die Zahl der Einträge muss der Zahl der Netzwerkadapter entsprechen.
|
#PRE
|
Die Verwendung dieser Anweisung führt dazu, dass der entsprechende Eintrag beim Starten des Systems in den NetBIOS-Namens-Cache für die gesamte Dauer der Arbeitssitzung geladen wird.
|
#SG:Gruppe
|
Dieser Parameter kennzeichnet den Eintrag als Bestandteil einer speziellen Gruppe mit einem NetBIOS-Namen vom Typ 0x20. Diese Gruppe fasst Systeme für spezielle Verwaltungszwecke
zusammen.
|
LMHOSTS und Windows 9x
Auch unter Windows 9x lässt sich LMHOSTS einsetzen. Die Beispieldatei LMHOSTS.SAM befindet sich im Systemverzeichnis. Gemäss der technischen Referenz zu Windows 95 muss bei den
Einstellungen für das TCP/IP-Protokoll im Register DNS-Konfiguration die Option DNS aktivieren
gewählt werden, damit LMHOSTS überhaupt genutzt wird. Tests haben aber gezeigt, dass Windows 9x sowohl mit als auch ohne die DNS-Aktivierung auf die LMHOSTS-Datei zugreift, wenn
die anderen für die Namensauflösung konfigurierten Mechanismen nicht gegriffen haben.
Ob und wie die Namensauflösung funktioniert, kann mit einfachen Mitteln selbst überprüft werden. Mit dem Kommando NBTstat -c
kann der aktuelle NetBIOS-Namens-Cache des lokalen Rechners betrachtet werden. Dort finden sich die Systeme, mit denen aktuell eine Verbindung aufgebaut wurde.
Im nächsten Schritt wird ein nicht existenter Rechner mit einer nicht genutzten IP-Adresse in die LMHOSTS aufgenommen und anschliessend der ping
-Befehl auf diesen Rechner in der Form ping Rechnername ausgeführt. Damit wird Windows 9x zur Namensauflösung gezwungen. Da es den
Rechner nicht gibt, kann der Name weder über einen Broadcast noch über DNS oder WINS aufgelöst werden. Folglich muss Windows in der LMHOSTS-Datei nachsehen. Ob das der Fall ist,
kann durch einen erneuten Aufruf von NBTstat -c getestet werden. Wenn die LMHOSTS genutzt wurde, findet sich der gesuchte Rechner in dieser Liste.
Letztlich lässt sich das Ergebnis der Namensauflösung schon am Verhalten des ping-Befehls
ablesen. Wenn nach längerer Wartezeit für die erfolglose, Broadcast-basierende Namensauflösung
ein Ping durchgeführt wird, dann nur, weil die LMHOSTS genutzt wurde. Als Ergebnis wird dann die Meldung Request timed out
ausgegeben, weil die angegebene IP-Adresse nicht gefunden wurde. Falls die Namensauflösung überhaupt nicht funktioniert, erscheint die Meldung Bad IP address.
Der Knotentyp für Windows 9x-Systeme kann übrigens über den Parameter NodeType, wie in der Microsoft Knowledge Base beschrieben, gesetzt werden. Die Einstellungen für die Knotentypen entsprechen denen von Windows NT.
|