=work in progress=
Dies soll ein generisches DDI-Konzept sein, das als Grundlage (Blaupause) dienen kann. Es soll exemplarisch die Stichpunkte liefern, die dann in einer konkreten Ausarbeitung auf die relevanten Absätze reduziert wird. Test wie gut man hier schreiben kann.
IPAM, DDI, Netzbasisdienste, Netznahe Dienste sind alles Begriffe für die Dienste, die man neben dem Kabel und der Hardware braucht, damit ein Netzwerk praktisch nutzbar wird.
Eine der wesentlichen Aufgaben von Computer-Netzwerken ist die Verwaltung von Netzwerkadresse (IPs), d.h. deren Zuordnung und Dokumentation. Das kann im einfachsten Fall ein Zettel oder Excel-Liste sein. In umfangreicheren Fällen nennt man das IP-Address Management (IPAM) und kann eine spezielle Softwarelösung sein. Nicht selten werden mit IPAM auch daran anschließende Dienste wie DNS und DHCP mit gemeint.
%BROWN%IPAM = IP-Address Management%ENDCOLOR%
Wenn man neben IPAM auch DNS und DHCP meint, wird auch zunehmend die Abkürzung DDI verwendet, um auszudrücken, dass man diese Netzbasisdienste als integralen Service auffasst.
%BROWN%DDI = DNS, DHCP, IPAM%ENDCOLOR%
Dabei will man alle Prozesse um IPs vereinfachen, automatisieren und zuverlässig machen. Wenn DNS-, DHCP- und IP-Adress-Management-Dienste als integrale Bestandteile eines Netzzugangs betrachtet werden, lassen sich einige sehr ähnliche Arbeitsabläufe zusammenfassen und deutlich einfacher gestalten und viele Mitarbeiter können gleichzeitig auf einer gemeinsamen Datenbasis arbeiten. Aus diesen Daten wird direkt die Konfiguration für die Dienste DNS und DHCP gespeist.
Der erste Vorteil entsteht, wenn alle Leute auf einer Datenbasis arbeiten, die der realen Konfiguration entspricht.
Der zweite Vorteil – meinst unterschätzt – ist, dass Skripte und andere Werkzeuge die Datenbasis via API ansteuern können.
Netze und IPs können leicht mit weitere Eigenschaften (z.B. Umgebung, Verantwortlichkeit, Sicherheitszonen) versehen werden, die für die Automatisierung genutzt werden können (Security, ACLs, SDN usw.). Durch den Zugriff auf Netzbasisdienste via API wird die DDI-Software zum Dreh- und Angelpunkt für Cloud, XAAS, DevOps und Automatisierungen.
Die Beplanung und Dokumentation von IPs, der DNService und DHCP (evtl. NAC) erfordern sehr ähnliche Arbeitsschritte – IP raussuchen, Benennung und weitere Informationen (MAC, Netz, Loka-tion, Name). Diese Schritte sind im großen Maßstab mühsam und fehleranfällig (IP, MAC), so dass es oft sinnvoll ist diese Schritte in einem Service zu integrieren.
2.1 DDI als Überbegriff für netznahe Basisdienste Der Begriff DDI – DNS DHCP IPAM – ist noch nicht weit verbreitet, denn bis vor wenigen Jahren sprach man einfach von IPAM bzw. IP-Adress-Management; meinte aber in der Regel DNS und DHCP mit. Denn auch wenn IPAM eine wichtige Aufgabe ist, hat es sich gezeigt, dass man für ein funktionierendes Netzwerk auch ein paar Basisdienste braucht, damit das ‚Netzwerk‘ funktioniert. Und da diese Dienste ähnliche Arbeitsschritte erfordern (IP und MAC raussuchen, dokumentieren, Namen vergeben), hat es sich etabliert, diese Dienste zusammenfassend als DDI zu bezeichnen. DDI beschreibt also die – meist gebündelten – netznahen Basisdienste, die man über das ‚Kabel‘ hinaus braucht, damit ein Netzanschluss funktioniert; das sind in der Regel DNS, DHCP und IPAM und manchmal – je nach Auffassung – auch noch NTP, TFTP und PKI.
Generelle Regeln für die Netzbasisdienste:
demain ohne weiter Hierarchie bzw. Subdomain genutztDie Dokumentation und Strukturierung von Netzwerkadressen ist die zentrale Aufgabe eines IP-Address Managements. Dabei muss garantiert werden, dass keine IP doppelt vergeben wird und der IP-Raum so aufgeteilt wird, dass er den Anforderungen des Routings und der Security genügt (und implizit einer Organisationsstruktur). Das bedeutet, dass Routen und/oder ACLs sich gut über Masken zusammenfassen lassen (route summarization, route aggregation). Diese Anforderungen lassen sich nicht gleichzeitig erreichen, insofern liegt je nach Anforderung die Gewichtung mehr bei 'schönen' Routen oder bei 'schönen' ACLs oder man versucht beiden ein bisschen gerecht zu werden.
Grundlage für die Aufteilung des IP-Raums – egal ob IPv4 oder IPv6 – ist eine Adresskonzept, in dem man die Struktur der IP-Aufteilung festlegt. Dabei versucht man die Anzahl der benötigen IPs, die für möglichst wenige Routen und wenige ACLs unter einen Hut zu bekommen. Gleichzeitig soll das Adresskonzept Reserven für zusätzliche Bedarfs und Anforderungen besitzen, so dass es für eine lange Zeit nutzbar ist, denn eine Anpassung des Adresskonzepts ist für die bestehende Infrastruktur mit sehr viel Aufwand verbunden (eine IP-Änderung bei komplexeren Systemen kommt quasi einer Neuinstallation gleich).
Ein IPv6-Adresskonzept ist insofern anders, als man nicht auf die Anzahl der benötigten IPs schauen muss (jedes Netz ein /64), und dafür seine Routen besser strukturieren kann – und auch muss, weil die Routen die Hardware stärker belasten (TCAM und Dual Stack, analoges gilt auch für ACLs).
Im Ergebnis soll ein überlappungsfrei routebarer IP-Raum zur Verfügung stehen, in dem die gegenläufigen Anforderungen abgewogen wurden.
DNS ist ein elementarer Dienst, ohne den größere Netze nicht funktionieren. DNS sorgt für eine eindeutige Auflösung von Namen zu IP-Adressen und umgekehrt.
Dadurch kann im Netzwerk mit sprechenden Namen gearbeitet und diese auch zentrale leicht geändert und angepasst werden. Dadurch schafft DNS eine Abtraktionsebene, die den Betrieb und die Administration einer IT-Infrastruktur vereinfachen.
Das im ersten Punkt angesprochene Namenskonzept ist, neben dem reinen Service und der Server-Hardware, der wesentliche Teil des DDI-Konzepts, weil darin den IPs Bedeutung, Struktur und Hierarchie gegeben werden.
Mit Blick auf IPv6 bekommt DNS noch mehr Bedeutung, da IPv6-Adressen kaum manuell handhabbar sind.
Nur auf einem überlappungsfrei routbaren IP-Raum kann man einen konsistenten DNS-Namensraum aufbauen.
DNS ist wie ein Baum strukturiert, um Eindeutigkeit und Auffindbarkeit der Namen zu gewährleisten. Vollständige Namen (FQDN) bestehen aus einem sog. Präfix oder Hostname (z. B. www), einem Domainnamen (z. B. spiegel.de) und einer Wurzel ('.', die meistens weggelassen wird).
Im Internet gibt es eine Wurzel (engl.: root), auf der alle Domainnamen aufbauen und von der ausgehend alle Domainnamen auflösbar sind. Wenn ein Intranet vom Internet entkoppelt ist, betreibt Kunden eine eigene Wurzel (root-Server), von der alle internen Domains aufrufbar sind.
Vor diesem Hintergrund sind folgende Ziele für ein funktionierendes Domänenkonzept von Bedeutung bzw. sehr wichtig:
Kunden/Anwendungen können mit ihren Domains über die gleiche Infrastruktur angebunden werden.Rechenzentrumsstandort einen oder mehrere autoritative DNS-Server, d. h. vollwertige DNS-Server mit eigenen Konfigurationsdateien. Diese beantworten Anfragen von Clients rekursiv (d. h. der Client darf dumm/stub sein bzw. der Client fragt einfach seinen DNS-Server, welcher die Arbeit übernimmt, verschiedene DNS-Server abzufragen, die für die Auflösung notwendig sind).Hinter einem SOA-Record werden in einem TXT-Record die verantwortlichen Ansprechpartner benannt.XAAS muss diese Aussage relativiert werden, weil dieser Dienst in schneller Folge Änderungen für den Betrieb benötigt._TCPMit DNS ist das Domain Name System gemeint, das sind die verständlichen Namen – wie z.B. www.spiegel.de oder www.heise.de – die man im Browser oben eingibt. Ohne DNS müsste man immer und überall IP eingeben, die weit schlechter zu merken sind und leicht zu Verwechselungen führen. Aber auch über das Internetsurfen hinaus schafft DNS eine Abtraktionsebene, die den Be-trieb und die Administration einer IT-Infrastruktur vereinfachen. • Man kann sprechende Namen statt IPs nutzen und kann, durch ein DNS-Namenskonzept unterstützt, die IPs benennen, gruppieren und ihnen Bedeutung geben. • Durch DNS bekommt man auch für die Konfiguration eine Abstraktionsebene, d.h. man kann auf allen Systemen einen Namen für z.B. Log-Server, ftp-Server usw. konfigurieren; wenn sich dann die IP des Servers ändert, muss nur an einer Stelle – im DNS – die IP anpassen werden und nicht die Konfiguration auf jedem einzelnen Server, der diesen Server nutzt. • Auch die Reverse-Auflösung – von IP zu Name statt von Name zu IP – ist sehr hilfreich, weil man in Logs und beim Debuggen mit ping und traceroute direkt die Namen sieht und ihnen Bedeutung zuordnen kann. Das im ersten Punkt angesprochene Namenskonzept ist, neben dem reinen Service und der Server-Hardware, der wesentliche Teil des DDI-Konzepts, weil darin den IPs Bedeutung, Struktur und Hierarchie gegeben werden.
Das Namenskonzept ist die logische Struktur der Namen im DNS (FQDN z.B. parkausweis.konstanz.bw.de). Wie die Namen genau aufgebaut werden ist meist umstritten, da in einem Namenskonzept oft sehr unterschiedliche Gruppen mit sehr unterschiedlichen Blickwinkeln und Anforderungen zusammenkommen und sich auf ein Konzept einigen müssen.
Hier eine beispielhafte Liste von Anforderungen:
Damit soll gezeigt werden, dass ein DNS-Namenskonzept verschiedene Anforderungen erfüllen muss und in der Regel ein Kompromiss ist – und oft hitzig diskutiert wird. Zum Glück ist DNS aber recht flexibel, so dass man bis zu einem gewissen Grad auch widersprüchliche Anforderungen erfüllen kann. So kann z.B. über Aliase (CNAME) verschiedene Konzepte erfüllt werden (pc1234234-bla.company.com verweisst auf hugo.personal.mainau.konstanz.bw.de verweist auf 120.34.56.78).
DHCP steht für Dynamic Host Configuration Protocol und bezeichnet die automatische Netzkonfiguration von einem – möglicherweise zentralen – DHCP-Server aus. DHCP ermöglicht dadurch ein zentrales IP-Konfigurations-Management und die Konfiguration weiterer zahlreicher Parameter (DHCP-Options). Nicht selten werden über die DHCP-Options noch nachgelagerte Services (TFTP, NFS, SMB), Skripte und Images geladen. Dabei ist DHCP aber der erste und wesentliche Baustein eines Zero Touch Provisioning oder Zero Touch Deployment, bei dem im Idealfall eine unkonfigu-riertes Gerät an das Netz angeschlossen wird und die komplette Konfiguration dieses Geräts statt-findet, ohne das ein Administrator das Gerät anfassen muss bzw. vor Ort sein muss. Man benötigt nur eine Hilfskraft, die den Strom anschließt und die Kabel steckt – sog. helping hands. Genauso ist es durch DHCP möglich, skalierbar Konfigurationsparameter auszurollen oder anzupas-sen, z.B. andere DNS-Server, IP-Konfigurationen, Proxy-Konfiguration oder Ähnliches. Mit einem sog. static DHCP kann durch einen statischen Eintrag, einem Gerät bzw. Interface (MAC) immer die gleiche IP und spezifische Konfigurationen zugewiesen werden.
Die Netzwerkkonfiguration erfolgt grundsätzlich zentral durch DHCP. Der Mehrwert durch zentrale Konfiguration der wesentlichen Netzparameter und zusätzlicher Optionen (Zeit-Server, Proxy, Domainname, Log-Server usw.) wird genutzt. Für automatisierte Installationen können Netboot-Optionen (PXE) in DHCP genutzt werden. Sicherheitsbedenken kann durch DHCP-Filter auf Switch-Ebene begegnet werden. Wenn Network-Access-Control (NAC) gefordert wird, ist die IP fest an eine MAC-Adresse gebunden. Es gibt mehrere DHCP-Server, die Ausfallsicherheit und Lastverteilung gewährleisten. Sie laufen in einem vollständigen Failover-Betrieb, d. h. sie kennen alle ausgegeben Leases, arbeiten auf den gleichen IP-Bereichen und sind nicht auf die Zusammenarbeit mit den Clients angewiesen (nicht unterschiedliche IP-Bereiche oder Anhängigkeit von Echo-Requests – die zwei üblichen Methoden, DHCP-Failover mit Einschränkungen einzurichten).
Grundlagen sind:
Der Vollständigkeit halber sei hier noch Bootp, das Vorgängerprotokoll von DHCP, erwähnt. Bootp wird fast immer auch noch von dem DHCP-Service unterstützt. Es wird gelegentlich noch von Altgeräten und Druckern in ihren default-Einstellungen gesprochen. Wo es möglich ist, sollten die Geräte aber von Bootp auf DHCP umgestellt werden, da Bootp keine Leasetime kennt und daher ihre IP quasi ewig behalten können.
=Zentrale IP Konfiguration, kein manuelles Turnschuhnetz, flexibel anpassbar, PXE-Betankung, Zero-Touch=
Die meisten DDI-Software-Lösungen werden über ein Webinterface administriert. Die Optik und die Philosophie des User-Interfaces können sehr variieren und hängen vom jeweiligen Produkt ab.
Die DDI-Software sollte über eine API bedienbar sein. Oft wird dafür Rest oder Soup benutzt. Die Details und der Umfang der API-Unterstützung hängen vom jeweiligen Produkt ab und können variieren.
NTP ist wichtig für die Zeitsynchronisation von am Netzwerk angeschlossenen Komponenten und eine wichtige Voraussetzung für Authentifizierung, Logging, Zertifikate, Debugging und Synchronisation. Dieser Service erfordert spezielle Hardware und kann nicht direkt von einer DDI-Software erbracht werden, organisatorisch wird dieser Service aber zu den Netzbasisdiensten gezählt.
NTP ist ein grundlegender Dienst, der vom Netz-Betrieb erbracht werden sollte. Zu diesem Zweck werden mindestens drei dezidierter Zeitserver betrieben, die direkt an zwei Zeitnormale (meistens DCF77/PZF und GPS/GNSS) angeschlossen sind (Stratum 1). Diese synchronisieren sich auch gegenseitig (peer), sodass sie gegen Ausfall oder Manipulationen gesichert sind. Nachrangig können noch andere Zeitserver betrieben werden, die diese Stratum-1-Zeitserver abfragen (Stratum 2). Ein Zeitserver-Client (auch ein Server in der Rolle eines Clients) braucht mindestens drei Zeitserver zur Auswahl damit der Sync-Algorithmus korrekt arbeiten kann. Bei Bedarf wird das Zeitsignal noch mittels MD5-Hash signiert, um eine Manipulation des Zeitsignals auszuschließen.
Nachrangige Stratum-2-Server sind bei weitem ausreichend für die Anfragen von Clients ohne spezielle Ansprüche an die Präsision. Die Stratum-1-Zeitserver werden nur von Systemen genutzt werden, die sehr hohe Anforderungen an die Genauigkeit haben. Die Stratum-1-Server würden etwas an Genauigkeit verlieren, wenn sie von zu vielen Systemen genutzt werden (durch zu viele Interrupts der vielen Anfragen). Außerdem werden die Stratum-1-Server auch aus Sicherheitsgründen nicht direkt genutzt. Mit dieser Struktur wird effektiv die Genauigkeit für die Clients verbessert, da entsprechend ausgelegt Stratum-2-Server eine bessere Zeit liefern als überlastete Stratum-1-Server.
Gegebenenfalls muss bei Zeitservern in Rechenzentren darauf geachtet werden, dass vom Zeitserver Antennenkabel für DCF77 und GPS auf das Dach des Rechenzentrums benötigt werden und es je nach Technik und Kabelqualität die Länge der Antennenkabel limitiert ist. Speziell GPS-Antennen brauchen einen freien Blick auf den Himmel.
Zur Zeitsynchronisation aller im Netzwerk angeschlossenen Geräte werden in der Regel mehrere NTP-Server verwendet, die mit einer externen Zeitquelle (andere NTP-Server, DCF77 oder GPS) eine interne Uhr genau halten und mit Hilfe des NTP-Protokolls (UDP 123) Zeitstempel im Netz verteilen und die Laufzeiten herausrechnen. Neben den naheliegenden Gründen einer Zeitsynchronisation – Logging, Debugging – ist es wichtig zu beachten, dass verschiedene Dienste eine gute Zeitsynchronisation voraussetzen. Das gilt für: • kerberos-Authentifizierung (AD) • Zeitbasierte Zweifaktorauthentifizierung • Backup und Repositories • Datenbank-Transaktionen • Debugging und Forensik (Kausalität bei 10GE) • Zertifikate und PKI (IPSec) • Virtualisierungen (z.B. VMWare) können das Problem erheblich verschärfen (Live-Migration)
=Sehr wichtiger, aber meist unterschätzter Dienst=
Mitunter wird auch TFTP zu den Netzbasisdiensten gezählt, da die initiale Installation via PXE neben DHCP auch einen TFTP-Server mit einem bootloader erfordert. Dieser Service soll hier nur kurz erwähnt werden, um eine Idee zu geben, wie der Begriff Netzbasisdienste mehr oder weniger weit gefasst werden kann.
Mitunter wird auch eine PKI zu den Netzbasisdiensten gezählt, da die Arbeitsschritte in DNS und IPAM (IPv6) Zertifikate für TSL/SSL, DNSSEC, IPSec, 802.1x involvieren. Dieser Service soll hier nur kurz erwähnt werden, um eine Idee zu geben, wie der Begriff Netzbasisdienste mehr oder weniger weit gefasst werden kann.
Mitunter wird auch eine NAC (Network Access Control z.B. 802.1x) zu den Netzbasisdiensten gezählt, da eine statische DHCP-Reservierung fast die gleichen Schritte wie NAC erfordert und leicht in eine DDI-Lösung integriert werden kann. Dieser Service soll hier nur kurz erwähnt werden, um eine Idee zu geben, wie der Begriff Netzbasisdienste mehr oder weniger weit gefasst werden kann.
Die DDI-Software muss die konsistente und effektive Bewirtschaftung eines IP-Bereiches ermöglichen und helfen die angrenzenden Services DNS und DHCP zu betreiben.
Folgende Anforderungen können wichtig sein:
Hier eine offene Liste möglicher DDI-Lösungen ohne Priorisierung irgendwelcher Art.
commercial
open source (free)