Gesetzliche Grundlagen für Kryptographie, Schlüssel und Signaturen

Ponencia / Ensayo (Colegio) , 2001 , 22 Páginas , Calificación: 2

Ciencia de la Computación - IT-Security

INHALTSVERZEICHNIS

1. WINS
1.1 Windows Internet Name Service
1.2 Wie funktioniert Name Resolution (Namensauflösung)?
1.3 Unterschied TCP/IP und NetBIOS Name Resolution
1.4 NetBIOS Name Resolution
1.5 Das NetBIOS Interface
1.6 NetBIOS Namen
1.7 NetBIOS Namensregistrierung und Auflösung
1.8 Der WINS Server
1.9 Die Implementierung von WINS
1.10. Installation und Konfiguration
1.10.1 Administration
1.10.2 Die Datenbasis von WINS (wins.mdb)
1.10.3 Sichern der Datenbank
1.10.4 Aufräumen der Datenbank
1.10.5 Wiederherstellen der Datenbank
1.10.6 Komprimieren der Datenbank

2 DNS
2.1 Domain Name System
2.2 Wie arbeitet DNS?
2.3 Installation und Konfiguration

3 DHCP
3.1 Dynamic Host Configuration Protocols
3.2 Wie arbeitet DHCP?
3.3 Installation und Konfiguration eines DHCP Servers

1. WINS

1.1 Windows Internet Name Service

Die Hauptfunktion von WINS ist es den NetBIOS Namen des Computers mit einer IP Adresse zu verbinden (Namensauflösung). Da der NetBIOS Name-Space flach und nicht hierarchisch ist, gibt es keine Möglichkeit, zwischen einem Server namens SRV1 in der Domäne DOM1 und einem Server namens SRV1 in der Domäne DOM2 zu unterscheiden. Aus diesem Grund muss jeder Computer einen eindeutigen Namen in einem Windows Netzwerk haben. Wenn ein Rechner mit dem NetBIOS Basisprotokoll initialisiert wurde, sendet er einen Broadcast aus und wartet auf eine Registrierung. Falls kein anderer Computer auf diese Anfrage reagiert, darf der Computer den Namen für die Dauer der Sitzung verwenden. Hat ein anderer Rechner den Namen schon in Gebrauch, wird die Registrierung verweigert und der Rechner kann seine Netzwerkdienste nicht starten bis er mit einem anderen Namen konfiguriert wird.

Früher war NetBIOS mit NetBEUI verknüpft, wurde aber herausgetrennt und arbeitet heute über TCP/IP. NetBEUI verursacht zu viele Broadcasts im Netz und kann nicht geroutet werden, daher sollte dieses Protokoll nach Möglichkeit nicht verwendet werden.

Anstatt die Namensanforderung (Name Registration Request) als Broadcast zu senden, schickt ein WINS Client eine Nachricht direkt an den WINS Server. Beim Herunterfahren wird erneut eine Meldung an den WINS Server gesendet, damit der NetBIOS Name wieder freigegeben wird. Wenn Clients einen Server suchen, wenden sie sich zuerst an den WINS Server um Broadcasts zu vermeiden. Standardmäßig werden NetBIOS Broadcasts auf Port 137-139 nicht über IP Router weitergegeben. Es ist zwar machbar, aber in einem zusammenhängenden Netz sollte eine Möglichkeit gefunden werden, Server in einem anderen Netz auch ohne Broadcasts zu finden.

Unter LanManager nutzte Microsoft früher eine Textdatei namens LMHOSTS um Rechner ohne Broadcast zu finden. Die Dateien enthielten die IP Adresse und den NetBIOS Namen im folgenden Format:

127.0.0.1 localhost

192.168.1.1 Server1

192.168.1.2 Server2

Dieser Weg ist umständlich weil für jeden Client der NetBIOS Ressourcen nutzen möchte eine LMHOSTS Datei konfiguriert werden muss. Weiterhin besteht die Pflicht die Liste bei allen Clients zu aktualisieren wenn neue Clients hinzukommen. Bei einem DHCP Server wäre das eine unlösbare Aufgabe.

Während die Clients anfragen und registriert werden baut der WINS Server eine Datenbank mit registrierten Namen auf. NetBIOS Namen dürfen 15 Zeichen lang sein. Das 16. Zeichen in eckigen Klammern ist reserviert und kennzeichnet den Dienst oder die Aufgabe in einer Domäne (PDC, BDC, Browsing). In einer WINS Datenbank erscheinen Computernamen mehrmals auf Grund der Dienste die konfiguriert sind. Hier die wichtigsten:

[00h] Arbeitsstationsdienst

[03h] Nachrichtendienst

[20h] Server Dienst

[21h] RAS Dienst

Die genauen Bezeichnungen können im NT Ressource Kit nachgelesen werden. Unter Windows gibt es mehrere Möglichkeiten in welcher Reihenfolge der NetBIOS Name mit der IP Adresse aufgelöst werden kann. Die genaue Reihenfolge wird als Knotentyp bezeichnet. Falls kein WINS Server konfiguriert ist, wird Knoten B als Standard verwendet. Hier die verschiedenen Knotentypen:

- B-Knoten - 0x1 (Broadcast)
- P-Knoten - 0x2 (WINS)
- M-Knoten - 0x4 (Mixed, zuerst Broadcast dann WINS)
- H-Knoten - 0x8 (Hybrid, zuerst WINS dann Broadcast)

B-Knoten

Cache

Broadcast LMHOSTS HOSTS

DNS

H-Knoten

Cache

WINS

Broadcast LMHOSTS HOSTS

Broadcast

Erfolgt der WINS Eintrag über DHCP muss der richtige Knotentyp gewählt werden. Wird bei einer Workstation der WINS Server manuell im TCP/IP Protokoll eingetragen wird automatisch der H-Knoten verwendet.

WINS wird als Netzwerkdienst hinzugefügt und unter Verwaltung (Allgemein) konfiguriert. An den Clients kann unter Windows der WINS Server über DHCP übermittelt werden.

1.2 Wie funktioniert Name Resolution (Namensauflösung)?

- Der direkte Umgang mit Netzwerkadressen wäre für den Anwender nicht komfortabel
- Daher werden Hosts zusätzlich mit einem Namen versehen
- Der Hostname muß in eine IP Adresse übersetzt werden, damit der TCP/IP Treiber ein IP Paket übertragen kann
- Für die Namensauflösung gibt es verschiedene Konzepte:

Abbildung in dieser Leseprobe nicht enthalten

1.3 Unterschied TCP/IP und NetBIOS Name Resolution

- Je nachdem auf welcher Schnittstelle ein Dienstprogramm aufsetzt wird eine andere Name Resolution verwendet.

Abbildung in dieser Leseprobe nicht enthalten

- Unter NT stehen drei verschiedene Protokolle für die Kommunikation zwischen Server und Client zur Verfügung: NetBEUI, NWLink und TCP/IP.

- Über die drei Transportprotokolle ist eine allgemeine Programmierschnittstelle (NetBIOS) gelegt.

- Durch diese Schnittstelle wird es dem Programmierer erspart, sich jeweils um die Details der Transportprotokolle zu kümmern.

- Dienstprogramme die auf der NetBIOS Schnittstelle aufsetzten (z.B. der Befehl net use) verwendet bei der Name Resolution die NetBIOS-Name-Resolution.

- TCP/IP Dienstprogramme (z.B. ping, ftp, telnet, Web-Browser) verwenden dagegen die TCP/IP -Name-Resolution.

- Ein NT basierendes Netzwerk sollte normalerweise beide Namensauflösungen unterstützen.

- Zwingend notwendig beim Einsatz von TCP/IP ist in jedem Fall WINS.

1.4 NetBIOS Name Resolution

- für NetBIOS stehen folgende Verfahren zur Namensauflösung zur Verfügung:

- Broadcast
- tabellengesteuert über die Datei lmhosts
- Windows Internet Name Service (WINS)

- Die NetBIOS Name Resolution wird verwendet, wenn ein auf NetBIOS basierendes Dienstprogramm verwendet wird (z.B. beim Befehl net use).

- Das Microsoft Netzwerk basiert auf NetBIOS. Somit muss in einer Microsoft Umgebung immer für eine korrekte NetBIOS Name Resolution gesorgt werden.
-Zusätzlich zur Name Resolution kommt in Microsoft Netzwerken der Browserdienst zum Einsatz. Er ist dafür verantwortlich, die Hostnamen zu ermitteln und sie als Browserlisten den Clients zur Verfügung zu stellen.

- Erst wenn ein Client auf eine Ressource zugreift erfolgt die Namensauflösung.

- Beispiel:

Auf einem Client wird im Explorer der Ordner „Netzwerkumgebung“ geöffnet. Alle Rechnernamen die darin aufgelistet sind wurden durch den Browserdienst ermittelt.

Beim Zugriff auf eine der Ressourcen wird durch die NetBIOS Namensauflösung die Netzwerkadresse zum entsprechenden Namen gesucht.

Broadcast:

- Bei der Namensauflösung über Broadcasts sendet ein Client der einen Namen in eine Netzwerkadresse auflösen will ein Broadcast-Paket an alle Hosts.
- Alle Hosts empfangen das Paket. Der Hosts mit dem gesuchten Namen antwortet dem suchenden Client, indem er ihm seine Netzwerkadresse mitteilt. Alle anderen Hosts ignorieren das Paket, nachdem sie festgestellt haben, dass ihr Name nicht der gesuchte ist.
- Die Namensauflösung über Broadcast ist in kleinen Netzen eine akzeptable Lösung. In großen Netzen sollte sie vermieden werden, um nicht unnötig Bandbreite zu verschwenden.
- Da Broadcast-Pakete normalerweise von Routern nicht weitergeleitet werden funktioniert die Namensauflösung über Broadcasts nicht über Routergrenzen hinweg.
- Um auch über Routergrenzen hinweg auf NetBIOS Namen zugreifen zu können muss entweder die tabellengesteuerte Namensauflösung über die Datei lmhosts oder der Windows Internet Name Service (WINS) zum Einsatz kommen (s.u.).

1.5 Das NetBIOS Interface

Network Basic Input/Output System (NetBIOS) definiert eine Softwareschnittstelle und eine Namenskonvention; also kein Protokoll.

Das NetBEUI Protokoll, 1985 von IBM eingeführt, unterstützte ein Protokoll speziell für Anwendungen, die um das NetBIOS Interface angelegt waren. NetBEUI ist ein sehr einfaches Protokoll, das keinen Network Layer kennt und daher nicht geroutet werden kann. Es ist also nur für kleine LANs geeignet.

NetBIOS over TCP/IP (NetBT) unterstütz das NetBIOS Programm Interface über das TCP/IP Protokoll. Es erweitert die Fähigkeiten eines NetBIOS Client/Server Programms hinsichtlich der Verwendung in einem WAN und unterstützt die Interoperlabilität mit einer Vielzahl von anderen Betriebssystemen.

Der Aufbau von NetBT und NetBIOS:

Abbildung in dieser Leseprobe nicht enthalten

Der Windows NT Workstation Dienst, Server Dienst, Browser, Benachrichtigungsdienst und Netlogon Dienste sind alle unmittelbare NetBT Clients, die das TDI für die Kommunikation mit NetBT benutzen. Windows NT beinhaltet auch einen NetBIOS Emulator. Dieser Emulator nimmt Standard NetBIOS Requests von NetBIOS Programmen entgegen und übersetzt diese in gleichlautende TDI - Anforderungen.

1.6 NetBIOS Namen

- Die NetBIOS Namensunterstützung ist flach, d.h. das alle Namen innerhalb eines Netzwerkes eindeutig sein müssen.
- NetBIOS Namen sind maximal 16 Zeichen lang.
- Microsoft NT erlaubt aber nur 15 Zeichen, das 16te Zeichen ist reserviert Als sog. SUFFIX.
- Resourcen werden durch ihren NetBIOS Namen identifiziert.
- diese werden dynamisch beim Computerstart, Start eines Dienstes, Benutzeranmeldungen registriert.
- Namen können als „unique“ (ein Benutzer) oder als „group“ (mehrere Benutzer) verwendet werden.
- Eine NetBIOS Namensanfrage wird dazu benutzt, den Namen einer Ressource in eine IP -Adresse aufzulösen.

Die für Ihre Station bekannten Namen der lokalen Computer erhält man über: Eingabeaufforderung: nbtstat -n.

1.7 NetBIOS Namensregistrierung und Auflösung

Windows NT 4.0 und 3.5 x Computer benutzen unterschiedliche Methoden um NetBIOS Ressourcen zu lokalisieren:

- NetBIOS name cache
- NetBIOS name server
- IP subnet broadcasts
- Static LMHOSTS files
- Static HOSTS files
- DNS servers

Die Auflösung von NetBIOS Namen hängt vom sog. Node Type und der Computerkonfiguration ab. Die folgenden Node Types werden unterstützt:

- b-node — benutzt Broadcasts für Namensregistrierung und Auflösung
- p-node — benutzt nur Punkt-zu-Punkt Anfragen an einen NetBIOS Namensserver (z.B. WINS) für Namensregistrierung und Auflösung
- m-node — benutzt Broadcasts für die Namensregistrierung und für die Namensauflösung zunächst ebenfalls Broadcast, schaltet aber bei Nichterhalt einer Antwort in einen p-node um
- h-node — benutzt NetBIOS Namensserver für Namensregistrierung und Auflösung

wird kein Name Server erreicht schaltet er in einen b-node um, er pollt solange weiter bis er einen Name Server erreicht und schaltet dann in einen p-node um.

WINS Clients sind standardmäßig als h-node konfiguriert

- Microsoft-enhanced — lokale LMHOSTS Datei oder WINS Proxies mit Windows Sockets gethostbyname() Anfragen (benutzen Standard DNS und lokale HOSTS Dateien)

1.8 Der WINS Server

Abbildung in dieser Leseprobe nicht enthalten

1.9 Die Implementierung von WINS

- Der Windows Internet Name Service (WINS) ist ein Dienst, der NetBIOS Namen in IP Adressen auflöst.
- WINS arbeitet dynamisch. WINS-Clients registrieren ihren Namen automatisch beim WINS-Server. Dadurch ist der WINS-Server in der Lage, Anfragen nach dem registrierten Namen zu beantworten.
- WINS steht als Dienst unter Windows NT Server zur Verfügung. Rechner unter Windows NT Workstation, Windows 95 oder Windows for Workgroups können nur als WINS-Client fungieren.
- Alle NT Server müssen gegenüber dem WINS-Server ebenfalls als WINS-Client konfiguriert werden, damit sie ihren Namen beim WINS-Server registrieren.
- Zwischen mehreren WINS-Servern kann ein Abgleich der Datenbank erfolgen (Push-Pull Partner, s.u.).
- Ein Rechner unter Windows NT Workstation kann als WINS-Proxy fungieren. Er empfängt die Namensanfragen anderer Rechner, leitet sie an einen WINS-Server weiter und sendet die vom WINS-Server empfangene Antwort zurück an den anfragenden Rechner.

1.10 Installation und Konfiguration

Auch der WINS Server Dienst wird, wie die anderen Netzwerkdienste, in der Option Netzwerk in der Systemsteuerung installiert.

1.10.1 Administration

WINS auf Client aktiviert:

- Computer gibt beim ordnungsgemäßen Herunterfahren seinen Namen am WINS Server frei.
- der WINS vermerkt den Eintrag in seiner Datenbank als released.
- Ist der Eintrag längere Zeit released trägt der WINS extinct ein, erneuert die Versionsnummer und benachrichtigt andere WINS Server über diese Änderung.

Wurde ein Name als released auf dem WINS Server registriert, und folgt eine neue Registrierung, die den gleichen Namen aber unter einer anderen Adresse verwendet, so kann der WINS Server sofort diesen Namen an den anderen Client freigeben, weil er weis, dass der andere Client nicht mehr diesen Namen benutzt. Das kann z.B. bei Laptop´s mit DHCP sinnvoll sein.

WINS auf Client deaktiviert:

- wenn ein nicht-WINS Computer einen Namen freigibt wird ein Broadcast gesendet.
- alle angeschlossenen Systeme entfernen diesen Namen aus ihrem Cache. - wird der gelöschte Name angefragt, ignorieren die Computers dies einfach.
- anderen Computern ist die Verwendung des gelöschten Namens aber jetzt möglich.

Nicht-WINS Computer die in anderen Subnetzen erreichbar sein sollen, müssen als sog. Statische Einträge in die WINS Datenbank oder die LMHOSTS Datei(en) auf dem entfernten System(en) eingetragen werden, da Sie auf Anfragen aus dem jeweiligen lokalen Subnetz reagieren.

1.10.2 Die Datenbasis von WINS (wins.mdb)

Neben der WINS.MDB werden weitere Informationen in den nachfolgenden Dateien festgehalten:

Abbildung in dieser Leseprobe nicht enthalten

1.10.3 Sichern der Datenbank

- im WINS-Manger.
- Sicherungsordner angeben.
- danach führt WINS alle 3 Stunden eine vollständige Sicherung durch.

1.10.4 Aufräumen der Datenbank

- Aufräumprozeß wird im WINS-Manager konfiguriert.

1.10.5 Wiederherstellen der Datenbank

- zuerst eine Kopie der WINS.MDB anlegen.
- Im Ornder \%systemroot\system32\wins folgende Dateien löschen: J50.log, J50#####.log und Wins.tmp.
- unbeschädigte Sicherungskopie in das Verzeichnis \%systemroot\system32\wins kopieren.
- WINS Dienst neu starten.

1.10.6 Komprimieren der Datenbank

Wird ab einer Größe von 30 Mbyte von Microsoft empfohlen:

- Programm JETPACK.EXE wird benötigt, liegt unter \%systemroot\system32\wins. - Kopieren der Datenbankinformationen eine temporäre Datenbankdatei z.B. TMP.MDB.
- Löschen der WINS.MDB.
- Umbenennen der TMP.MDB in WINS.MDB.
- Beenden des WINS-Dienstes in der Systemsteuerung. - JETPACK.EXE starten.
- WINS-Dienst erneut starten.

2 DNS

2.1 Domain Name System

Ein DNS wird benutzt um Hostnamen in IP Adressen umzuwandeln. Anders als NetBIOS Namen die bei allen Windows Rechnern vorausgesetzt werden, ist der Host Name optional und dient lediglich dazu sich nicht die langen IP Adressen merken zu müssen. Der Vorteil eines NT DNS Servers besteht darin, daß er in Windows Netzwerken NetBIOS Namen in Verbindung mit WINS auflösen kann. Im Gegensatz zu WINS der alle Namen in einem Flat Name Space speichert, speichert DNS die Namen hierarchisch mit einem Fully Qualified Domain Name (FQDN) der im ganzen Internet bekannt ist. Microsoft Betriebssysteme benutzen momentan noch NetBIOS als primäres Netzwerkprotokoll. Wenn in einem Netzwerk nur Windows Rechner vorhanden sind, kann auf DNS verzichtet werden. NetBIOS over TCP/IP ein schlankes Protokoll d.h. es werden wesentlich weniger Header Informationen über das Netz übertragen. In Kombination mit WINS ist diese Art der Kommunikation und Namensauflösung schneller als TCP/IP und DNS. Der Trend geht aber zu TCP/IP und DNS (aufgrund der Beschränkung auf Windows Netze), sodass in Zukunft NetBIOS und WINS ihre Bedeutung verlieren werden.

Wichtig!!! Ein DNS hat nichts mit einer Windows NT Domäne (PDC/BDC) zu tun. Diese zwei Begriffe sorgen oft für Verwirrung.

2.2 Wie arbeitet DNS?

Der Anfang einer Domäne nennt sich root der durch einen Punkt dargestellt wird.

Unterhalb der root gibt es Top Level Domains die entweder nach Organisationen oder Länder gegliedert sind z.B. .com, .edu, .de etc. Die Struktur wird in einem Baum dargestellt in dem jeder Knoten 63 Zeichen lang sein darf (NetBIOS 15 Zeichen) und durch einen Punkt getrennt wird. Der root des Internets wird von der InterNIC verwaltet. Der nächste Level beschreibt den Namen der Organisation z.B. sul.de. Eine Domäne kann in weitere Subdomains gegliedert werden. Um den Namen einer Domäne zu registrieren, muss man einen eigenen DNS betreiben oder über einen ISP (Internet Service Provider) gehen.

Um ein Host zu suchen, wird der FQDN verwendet um den Server im DNS Baum zu finden. NTSERVER01.edv.sul.de ist der FQDN für einen Server mit dem Namen NTSERVER01 in der Subdomain edv, die wiederum ist in der sul Domäne unter der Top Level Domain .de.

Um diesen DNS Baum zu verwalten, werden die einzelnen Domänen in Zonen unterteilt. Jede Zone enthält einen primären DNS. Aus Gründen der Sicherheit können auch sekundäre Name Server eingerichtet werden. Auf einem primären Name Server können sekundäre Zonen eingerichtet werden die dann auf dem sekundären Server als primäre Zonen existieren. Diese Zonen müssen dann zwischen den Name Servern repliziert werden.

Ein DNS hat die Aufgabe einen Hostnamen mit der passenden IP Adresse aufzulösen. Möchte man aber eine IP Adresse mit dem dazugehörigen Hostnamen auflösen muß eine Reverse Lookup Zone eingerichtet werden. Diese Einträge in der Reverse Lookup Zone werden auch als PTR Einträge bezeichnet. Die Domäne inaddr.arpa. ist für die Reverse Lookup Zone zuständig.

2.3 Installation und Konfiguration

Um einen DNS Server einzurichten muss der DNS Netzwerkdienst hinzugefügt werden und über Verwaltung (Allgemein) konfiguriert werden.

Zuerst wird der Server hinzugefügt (Name oder IP Adresse). Mit einem Doppelklick auf Zwischenspeicher sind die Stammserver des Internets zu sehen. Unter Optionen - Einstellungen aktiviert man das Kontrollkästchen " Automatisch erzeugte Zonen anzeigen". Mit dieser Einstellung werden die Reverse Lookup Zonen 0, 127 und 255 angezeigt.

Da 127.0.0.1 localhost ist kann man es testen mit Doppelklick auf 127.in-addr.arpa und zweimal null. Hier muß dann der PTR Eintrag localhost erscheinen.

Nun müssen die Zonen eingerichtet werden. Mit Rechtsklick auf die IP Adresse des Servers und neue Zone wählen. Der Name der Zonendatei wird automatisch erzeugt.

Damit der DNS mit WINS Informationen austauschen kann muss mit Rechtsklick auf die Zone sul.de unter Eigenschaften der WINS Server hinzugefügt und aktiviert werden.

In der Zone sul.de sind jetzt die Einträge NS (Name Server) und SOA (Start of Authority) zu sehen. Hiermit weiß der DNS Server, dass die Domäne sul.de im Class C Netz unter 192.168.205.1 zu finden ist aber immer noch nicht welcher Hostname damit verknüpft ist. Als nächstes muss eine DNS Reverse Lookup Zone eingerichtet werden. Wieder mit Rechtsklick auf den Server 192.168.205.1 und eine neue primäre Zone erstellen. Für das Reverse Lookup werden die letzten drei Oktette der IP Adresse in einem Class C Netz in umgekehrter Reihenfolge eingetragen. Das vierte Oktett der IP Adresse entspricht dem FQDN. Der Eintrag für das Reverse Lookup sieht wie folgt aus: 205.168.192.in-addr.arpa Zum Schluss müssen alle Rechner mit fester IP Adresse einen A Eintrag (z.B. ntserver01) in der Zone sul.de bekommen. Es ist die IP Adresse und der dazugehörige Host Name einzugeben. Das Feld "Entsprechenden PTR-Eintrag erzeugen" muss aktiviert sein damit der Eintrag auch in der Reverse Lookup Zone erfolgt. Zusätzlich können Aliase erzeugt werden. Falls mein Server auch unter www.sul.de oder ftp.sul.de erreichbar sein soll, muss der Eintrag CNAME hinzugefügt werden. Der Alias wäre dann z.B. www und der DNS Name ntserver01.sul.de Zum Schluss kann man den Server testen. Der Befehl nslookup muss nun die Adresse des DNS Servers liefern.

Abbildung in dieser Leseprobe nicht enthalten

3 DHCP

3.1 Dynamic Host Configuration Protocols

In einem TCP/IP Netzwerk braucht jedes Gerät eine eindeutige IP Adresse im Netzwerksegment. Die IP Adressen manuell zu verteilen und zu verwalten ist ein unverhältnismäßig großer Arbeitsaufwand. Doppelte IP Adressen können unter Umständen ein Arbeitsplatz oder sogar ein ganzes Netzwerk ausfallen lassen.

Microsoft TCP/IP minimiert diese Probleme, indem es erst ein ARP Broadcast macht, bevor der TCP/IP Stack initialisiert wird. Wenn andere Maschinen auf diesen Broadcast reagieren, ist die Adresse bereits vergeben und der Stack auf der neuen Maschine wird nicht initialisiert. Beide Maschinen erhalten eine Nachricht, dass die Adresse zweimal vergeben wurde.

Ein anderes Problem ergibt sich, wenn Maschinen von einem Subnet zu einem anderen bewegt werden, ohne dass dabei die IP Adresse neu konfiguriert wird. Der TCP/IP Stack wird dann zwar initialisiert, die Maschine kann aber nicht kommunizieren, weil lokale Daten als entfernte und entfernte als lokale behandelt werden. Um den Umgang mit IP Adressen zu erleichtern, hat die Internet Engineering Task Force (IETF) zusammen mit einigen Herstellern das DHCP erarbeitet.

3.2 Wie arbeitet DHCP?

DHCP wird als Client/Server Dienst eingerichtet und arbeitet wie folgt:

1. Sobald ein Client startet, wird ein Broadcast gesendet, der einen DHCP Server anfordert.
2. Jeder DHCP Server, der diesen Broadcast empfängt, sendet ein Broadcast an den Client und bietet eine IP Adresse für einen bestimmten Zeitraum (Lease Period) an. Die angebotene IP Adresse wird als vergeben markiert und in der Zwischenzeit an keinen anderen Client vergeben.
3. Der Client nimmt eines der Angebote an und sendet einen weiteren Broadcast, dass er seine Wahl getroffen hat. Das erlaubt allen DHCP Servern die IP Adresse die nicht gewählt wurde, anderweitig zu vergeben.
4. Der ausgewählte DHCP Server sendet einen weiteren Broadcast mit einer Bestätigung, der IP Adresse, der Subnet Mask und dem Zeitraum der Benutzung. Weiterhin können Informationen über WINS, DNS und Gateway gesendet werden.

Durch das Wort ROSA kann man sich den Ablauf gut merken.

1. IP Lease Request (Anforderung)
2. IP Lease Offer (Angebot)
3. IP Lease Selection (Auswahl)
4. IP Lease Acknowledgement (Bestätigung)

Die Lease Informationen des Clients sind mit dem Kommando ipconfig /all sichtbar. Das Kommando zeigt die IP Adresse, die Subnet Mask, den DHCP Server, den Start und das Ende der Lease Period. Falls kein DHCP Server erreichbar ist wird versucht eine IP Adresse in Intervallen von 9, 13 und 16 Sekunden zu bekommen. Nach vier erfolglosen Versuchen wird dem Client eine Nachricht angezeigt, dass kein DHCP Server erreichbar ist. Es wird versucht alle fünf Minuten eine IP Adresse zu bekommen, bis zum Erfolg.

ipconfig kann auch mit dem Parameter /release ausgeführt werden, um eine Lease aufzulösen, oder mit /renew, um eine neue aufzubauen. Beim Start eines Clients wird automatisch eine Bestätigung der IP Adresse beim Server angefordert. Befindet sich der Client in einem anderen Netz, sendet der Server eine NACK (Negative Acknowledgement) und führt den Client durch den vierstufigen Prozess (ROSA) um eine neue Adresse zu bekommen, d.h. DHCP erledigt die Vergabe der Adressen vollständig alleine.

Nach der Hälfte der Lease Period wird der Client versuchen, sein Lease mit dem DHCP Server zu erneuern. Wenn der Server nicht zur Verfügung steht, versucht der Client es erneut, bis die Lease zu 87,5% abgelaufen ist (7/8 der Zeit). Nach dieser Dauer wird der Client jeden beliebigen DHCP Server nach einer Erneuerung seiner Lease fragen. Ist der Client nicht in der Lage, seine Lease zu erneuern, wird jede Kommunikation über TCP/IP eingestellt.

3.3 Installation und Konfiguration eines DHCP Servers

Der Dienst wird in der Systemsteuerung unter Netzwerkdienste hinzugefügt. Nach einem Neustart wird er unter Verwaltung (Allgemein) konfiguriert. Zuerst wird ein Adressbereich (Scope) festgelegt. In diesem Beispiel ein Class B Netzwerk mit allen verfügbaren Hostadressen. Als Ausschlussbereich (Geräte die eine statische IP Zuordnung benötigen oder nicht DHCP fähig sind: Server, Printer etc) werden 10 Adressen reserviert die nicht vom DHCP Server vergeben werden. Weiterhin ist die Lease zu konfigurieren. Eine zu kurze Lease Dauer erhöht den Netzwerk Traffic durch die vielen Anfragen der Clients, eine zu hohe Lease Dauer bewirkt, dass Änderungen der Konfiguration nicht schnell genug bei den Clients wirksam werden.

Nach dem Bestätigen mit OK, wird gefragt ob der Bereich aktiviert werden soll. Der aktive Bereich wird dann mit einer Glühlampe symbolisiert.

Es besteht die Möglichkeit weitere Optionen über DHCP den Clients zu übermitteln. Die wichtigsten Einstellungen sind: DNS, WINS, Standard Gateway und der Domain Name. Ist das Standard Gateway mit dem Internet verbunden und man möchte nicht jedem Client den Zugriff auf das Internet erlauben, muss der Eintrag weggelassen werden, da sonst jeder Client vollen Zugriff auf das Netz hat. Eine Zugriffskontrolle für das Internet bietet nur ein Proxy Server.

Die Optionen bieten die Wahl zwischen einem Bereich und Global. Die globalen Einstellungen sind für alle gültig und der Bereich nur für einen bestimmten Adressbereich. Der Bereich hat Vorrang vor den globalen Einstellungen. Der Bereich kann nur durch lokale Einstellungen am Client überschrieben werden. Die Einstellung für das Standard Gateway ist: 003 Router. Der Wert muss hinzugefügt, und der Array bearbeitet werden mit der IP Adresse des Routers.

Die WINS Server Werte sind: 044 WINS/NBNS Server und 046 WINS/NBT Node Type. 044 übermittelt die IP Adresse des WINS Servers und 046 den Knotentyp. Der Knotentyp sollte auf 0x8 (Hybrider Knoten) gesetzt sein. Falls ein DNS Server im Netzwerk vorhanden ist kann dieser mit dem Wert 006 DNS Servers an die Clients übergeben werden, der Domain Name lautet sul.de

Nachdem alle Einstellungen vorgenommen wurden, sollte es folgendermaßen aussehen:

• Calificación: 2
• Autor: Dennis Mohrmann (Autor)
• Año de publicación: 2001
• Páginas: 22
• No. de catálogo: V105813
• ISBN (Ebook): 9783640040940
• Idioma: Alemán
• Etiqueta: Gesetzliche, Grundlagen, Kryptographie, Schlüssel, Signaturen