|
|
| (61 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| | | #WEITERLEITUNG [[Dynamic Host Configuration Protocol]] |
| = Historie =
| |
| | |
| * DHCP kann als Nachfolger vom BOOT-Protokoll verstanden werden, das entwickelt wurde, um Rechner ohne Festplatte in IP-Netzen zu starten und automatisch zu konfigurieren.
| |
| * Veröffentlichung der ersten DHCP-Version Ende 1993 im RFC 1541
| |
| * Ablösung durch neue Version in RFC 2131 im März 1997
| |
| * Erweiterungen von RFC 2131 durch die RFCs 2132, 3396 & 4361
| |
| | |
| = Grundlagen =
| |
| | |
| * DHCP regelt die dynamische Vergabe von IP-Adressen und kann die Konfiguration von Rechnern unterstützen
| |
| * DHCP funktioniert nach dem Client-Server-Prinzip
| |
| * Benutzer eines Rechners benötigt keine IP-Adresse von einem Administrator - werden vom DHCP-Server zur Verfügung gestellt
| |
| * IP-Konfigurationsparameter für die Clients sind auf dem DHCP-Server gespeichert
| |
| * Vergabe der IP-Adressen erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
| |
| * Implementierung von DHCP-Relays, um DHCP-Nachrichten in andere Subnetze weiterzuleiten, die über keinen DHCP-Server verfügen
| |
| | |
| Beim Start einer DHCP-Client-Applikation werden vom Server folgende Informationen angefordert:
| |
| | |
| * Client-IP-Adresse
| |
| * Lease-Dauer
| |
| * Identifikation des DHCP-Servers
| |
| * Subnetzmaske
| |
| * Default-Gateways
| |
| * statische Routen
| |
| * Hostname & Domainname
| |
| * Lokation externer Server (z. Bsp. Time-Server)
| |
| | |
| == Anforderungen an den DHCP-Server ==
| |
| | |
| * Ein DHCP-Server muß über einen Bereich gültiger IP-Adressen verfügen.
| |
| * Der Server benötigt eine manuell zugewiesene statische IP-Adresse (Der Server selbst kann kein Client sein).
| |
| * Soll ein Server IP-Adressen für Clients in verschiedenen Subnetzen verteilen, so müssen sämtliche Router zwischen den Subnetzen als DHCP-Relay-Agenten konfiguriert werden. Wird dies von den Routern nicht unterstützt, benötigt jedes Subnetz einen eigenen DHCP-Server.
| |
| * Im Pool der IP-Adressen dürfen keine statischen IP-Adressen enthalten sein, da diese anderenfalls doppelt vergeben würden.
| |
| | |
| | |
| = Ablauf des DHCP-Verfahrens =
| |
| | |
| '''Automatische Zuweisung''':
| |
| | |
| * IP-Adressen werden automatisch an die MAC-Adressen von neuen DHCP-Clients vergeben & diese Zuordnung in einer Tabelle festgehalten
| |
| * Vergabe der IP-Adresse an den Client erfolgt aus einem Pool von IP-Adressen, der vom Server verwaltet wird
| |
| * Zuordnungen sind permanent und werden nicht entfernt - jeder Client erhält somit stets die gleiche IP-Adresse
| |
| | |
| | |
| '''Dynamische Zuweisung''':
| |
| | |
| * Vergabe erfolgt analog der ''Automatischen Zuweisung''
| |
| * Zuweisung der IP-Konfiguration jedoch für einen bestimmten Zeitraum (''Lease''-Dauer)
| |
| * Verfall der IP-Adresse nach Ablauf der Lease-Dauer - Neuvergabe an anderen Client durch den DHCP-Server möglich
| |
| * Client kann/muß vor Ablauf der ''Lease''-Dauer eine Verlängerung beantragen
| |
| * erlaubt, als einzige Zuweisungsmethode die Wiederverwendung von IP-Adressen, wenn der Client diese nicht mehr benötigt
| |
| | |
| | |
| '''Manuelle Zuweisung''':
| |
| | |
| * DHCP-Server führt eine Zuweisungstabelle: feste Zuordnung von MAC-Adresse zu IP-Adresse (statisches DHCP)
| |
| * Client erhält immer die gleiche IP-Adresse
| |
| * nur Rechner mit bekannten & registrierten MAC-Adressen erhalten eine IP-Adresse
| |
| * sinnvoll bei Servern, die stets unter der gleichen IP-Adresse erreichbar sein sollen
| |
| | |
| = DHCP-Nachrichten =
| |
| | |
| * Austausch von festgelegten DHCP-Nachrichten zwischen Server & Client
| |
| * Übermittlung durch das verbindungslose Transportprotokoll UDP (Server-Port: 67 & Client-Port: 68)
| |
| * Der DHCP-Client stellt einen Anwendungsprozess auf einem Rechner dar & ist auf dem Well-Known-Port 68 erreichbar
| |
| * Der DHCP-Server läuft als Anwendungsprozess auf einem dedizierten Rechner & ist auf dem Well-Known-Port 67 zu erreichen
| |
| | |
| | |
| == Aufbau von DHCP-Nachrichten ==
| |
| | |
| [[File:DHCP-Paket.png|400px|none]] | |
| | |
| | |
| {| class="wikitable"
| |
| |-
| |
| ! Feld !! Länge [Byte] !! Bedeutung !! Beschreibung
| |
| |-
| |
| | op || 1 || Operation || gibt an, ob es sich um eine Anfrage oder Antwort handelt
| |
| |-
| |
| | htype || 1 || Netztyp || Angabe des Netztyps gemäß RFC 1340 (z. Bsp. 6 = 802.x-LAN)
| |
| |-
| |
| | hlen || 1 || Länge der Hardware-Adresse || physikalische Netzadresse (z. Bsp. 6 = MAC-Adresse)
| |
| |-
| |
| | hops || 1 || Anzahl der Hops || Anzahl von Routern mit DHCP-Relay-Funktion auf dem Weg zwischen Client & Server
| |
| |-
| |
| | xid || 4 || Transaktions-ID || Identifikationsnummer für die Transaktion zwischen Client & Server
| |
| |-
| |
| | secs || 2 || Sekunden || von Seiten des Clients, die Zeit seit Beginn des Vorgangs
| |
| |-
| |
| | flags || 2 || Flags || nur das höchstwertige Bit wird verwendet, um anzuzeigen, ob der Client noch über eine IP-Adresse verfügt
| |
| |-
| |
| | ciaddr || 4 || Client-IP-Adresse || wird vom Client angegeben, falls dieser noch über eine IP-Adresse verfügt
| |
| |-
| |
| | yiaddr || 4 || Your-IP-Adresse || IP-Adresse, die der Server dem Client zugewiesen hat
| |
| |-
| |
| | siaddr || 4 || Server-IP-Adresse || IP-Adresse des DHCP-Servers
| |
| |-
| |
| | giaddr || 4 || || IP-Adresse des Routers mit DHCP-Relay-Funktion
| |
| |-
| |
| | chaddr || 16 || Client-Hardware-Adresse || Client-Mac-Adresse
| |
| |-
| |
| | sname || 64 || Server-Name ||
| |
| |-
| |
| | file || 128 || File / Datei ||
| |
| |-
| |
| | options || bis 312 || Optionen || zusätzliche Konfigurationsparameter - DHCP-Optionen nach RFC 2132
| |
| |}
| |
| | |
| | |
| == Ablauf der Kommunikation ==
| |
| | |
| [[File:DHCP-Ablauf1.png|500px|none]]
| |
| | |
| [[File:WireShark-DHCP-Phasen.png|1000px|none]]
| |
| | |
| '''Anforderungsphase''':
| |
| | |
| * Client sendet die Nachricht ''DHCP-DISCOVER'' mit einem Broadcast (Ziel-IP: 255.255.255.255) in sein lokales Netz
| |
| * ''DHCP-DISCOVER''-Nachricht kann Optionen enthalten, wie zum Beispiel Vorschläge für IP-Adresse & Lease-Dauer
| |
| * Anforderung der benötigten Konfigurationsparameter - IP-Adresse, Subnetzmaske etc.
| |
| * Angabe der MAC-Adresse des Clients (''chaddr'') zwingend erforderlich
| |
| * Nachricht ist normalerweise auf das eigene Subnetz beschränkt - kann aber durch DHCP-Relay-Agenten in andere Subnetze weitergeleitet werden
| |
| | |
| | |
| '''Angebotsphase''':
| |
| | |
| * Mit der Nachricht ''DHCP-OFFER'' läßt der DHCP-Server dem Client ein Angebot zukommen.
| |
| * Der Server versucht dabei, den Client direkt zu erreichen - was nicht immer möglich ist:
| |
| | |
| Fall A:
| |
| * Client wird gerade initialisiert & verfügt noch nicht über eine IP-Adresse
| |
| * Angebot wird als Broadcast versandt - erhält aber bereits die MAC-Adresse des Clients, so daß nur dieser die Nachricht lesen darf
| |
| | |
| Fall B:
| |
| * Client verfügt bereits über eine IP-Adresse - deren Lease-Dauer jedoch zu Ende geht
| |
| * Angebot wird in diesem Fall direkt an die IP-Adresse des Clients gesendet
| |
| | |
| * Zu diesem Zeitpunkt muß der Server die IP-Adresse noch nicht reservieren, kann dies aber tun.
| |
| | |
| | |
| '''Auswahlphase''':
| |
| | |
| * Der Client wählt die Konfigurationsparameter des zuerst erhaltenen Angebots aus.
| |
| * Senden einer Nachricht ''DHCP-REQUEST'' - Optionsfeld muß den Eintrag ''DHCP Server Identifier'' enthalten - Server, die nicht im ''DHCP-REQUEST'' erwähnt werden, erhalten somit den Hinweis, daß ihr Angebot nicht angenommen wurde
| |
| * angebotene IP-Adresse wird mit der Option ''Requested IP Address'' bestätigt
| |
| * Nachricht wird als Broadcast versendet, um andere DHCP-Server darüber in Kenntnis zu setzen, daß der Client sich entschieden hat und die entsprechenden Server die reservierten Parameter wieder freigeben können
| |
| | |
| | |
| '''Bestätigungsphase''':
| |
| | |
| * Antwort des DHCP-Servers mit der Nachricht ''DHCP-ACK'' mit allen Konfigurationsparametern für den Client
| |
| * Sollten in dieser Phase weitere Angebote eintreffen, werden diese vom Client verworfen.
| |
| | |
| | |
| [[File:DHCP-Phasen.png|1600px|none]]
| |
| | |
| | |
| '''Weitere DHCP-Nachrichtentypen''':
| |
| | |
| ''DHCP-NAK'':
| |
| * wird während der Bestätigungsphase vom Server an den Client gesendet, um diesen darauf hinzuweisen, daß die im ''DHCP-REQUEST'' angeforderten Konfigurationsparameter abgeleht wurden:
| |
| ** wenn ein Client versucht seine bisherige IP-Adresse zu verlängern, diese jedoch nicht mehr verfügbar ist
| |
| ** wenn ein Client in ein anderes Subnetz umgezogen & somit die IP-Adresse ungültig ist
| |
| | |
| ''DHCP-RELEASE'':
| |
| * Hiermit teilt ein Client dem Server mit, daß er seine IP-Adresse nicht mehr benötigt und der Server die Adresse freigeben und anderweitig vergeben kann
| |
| | |
| ''DHCP-DECLINE'':
| |
| * Der Client kann hierüber den Server in Kenntnis setzen, daß einige Parameter ungültig sind (zum Beispiel seine MAC-Adresse)
| |
| | |
| ''DHCP-INFORM'':
| |
| * Kann von Clients verwendet werden, denen eine statische IP-Adresse zugewiesen wurde, um weitere dynamische Konfigurationsparameter vom Server anzufordern.
| |