Box 24

 Home   Infos   Tipps   Webmail   Humor   Polizei   Gästebuch   Downloads   Chat   Suchen   Feedback   Links 

 

 Anmelden/Login   Neuanmeldung/New User   Java Telnet Applet   Telnet   
 

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.