Netzwerkdienste
Um nun mit dem Netzwerk arbeiten zu können werden Dienste benötigt, die Netzwerkfunktionen zur Verfügung stellen. Netzwerkdienste sind Programme, die auf einem Computer laufen und über einen TCP/IP-Port angesprochen werden können.
Auf einem über das TCP/IP-Protokoll erreichbaren Server können durchaus verschiedene Netzwerkdienste angeboten werden. Damit diese über die IP-Adresse des Servers angesprochen werden können, wird zusätzlich noch ein sogenannter Port oder auch Socket eingerichtet. Dieser ist Teil der Netzwerkadresse und ermöglicht dadurch das gezielte Ansprechen von Serverdiensten.
Bekannte Ports sind zum Beispiel der Port 80, auf dem in der Standardkonfiguration ein Webserver mit dem http-Protokoll angesprochen wird. Wird eine SSL-Verschlüsselung der Website genutzt, so wird diese über den Port 443 angesprochen (https).
Dazu gehören auf einer für den Betrieb des Netzwerkes wichtigen Ebene die Dienste DHCP (Dynamic Host Configuration Protocol) und DNS (Domain Name Service). Aber auch Webserver (http / https) oder Fileservices (SMB/CIFS/NFS) gehören exemplarisch dazu.
DHCP
(Dynamic Host Configuration Protocol, UDP Port 67)
Ein wichtiger Dienst im Netzwerk ist der DHCP-Dienst, welcher die Netzwerk-Konfiguration der Clientsysteme automatisch durchführen kann. Auf den meisten Routern in Heimnetzwerken ist der DHCP-Dienst oder auch DHCP-Server normalerweise aktiviert. Der Server verteilt an die angeschlossenen Clients die Netzwerk-Konfiguration für das Netzwerk bestehend aus einer eindeutigen IP-Adresse, die anhand der MAC-Adresse der Netzwerkkarte festgelegt werden kann. Weiter wird die Subnetzmaske, die Adresse der Routers (oder Gateway) und die Adresse DNS-Server übertragen.
Die an den Router angeschlossenen Geräte suchen beim Systemstart oder beim Anschluss der Netzwerkkarte nach einem DHCP-Server, um die für dieses Netz benötigte IP-Adresse zu bekommen. Diese Suche erfolgt durch einen Netzwerk-Broadcast an die IP-Adresse 255.255.255.255 mit der Absenderadresse 0.0.0.0, also eine Nachricht an alle im Netzwerk befindlichen IP-Adressen.
Der DHCP-Server antwortet ebenfalls mit einem Broadcast auf der Adresse 255.255.255.255.255. Damit ist dann den beiden Systemen jeweils die MAC-Adresse des Anderen bekannt und der DHCP-Server kann dem Client zielgerichtet eine IP-Adresse zuweisen. Dies erfolgt entweder dynamisch aus einem Pool von IP-Adressen, die der Server verteilen darf, oder es wird statisch einer MAC-Adresse immer die gleiche IP-Adresse zugeteilt (Reservierung). Diese Zuteilung einer ‚DHCP-Lease‘ ist zeitlich befristet, bei einem Windows DHCP-Server beträgt die Lease-Dauer bei einer Standardkonfiguration 8 Tage.
Wird die Hälfte der Lease-Dauer erreicht, so fragt der Client erneut beim DHCP-Server an, ob er die Zuteilung behalten darf. Dieser antwortet im Normalfall mit einer Bestätigung der Lease und verlängert die Lease-Dauer entsprechend. Antwortet der DHCP-Server nicht, so kann der Client die IP-Adresse noch bis zum Ablauf der Lease-Dauer behalten. Nach Ablauf der Lease-Time muss der Client die IP-Adresse verwerfen und erneut mit einem Broadcast nach einem DHCP-Server suchen.
Werden Clients mit einer IP-Adresse konfiguriert und die automatische Konfiguration mittels DHCP deaktiviert, so sollte diese IP-Adresse aus einem Bereich stammen, der nicht vom DHCP-Server verteilt wird.
Ein Beispiel:
Der DHCP-Server verteilt die Adressen von 192.168.178.20 bis 192.168.178.200 mit der Subnetzmaske 255.255.255.0. Dies ist der Adresspool, aus dem den DHCP-Clients eine Adresse zugeteilt wird. Der Router selber hat in diesem Netz die IP-Adresse 192.168.178.1. Wird ein Client mit einer statischen IP-Adresse konfiguriert, so kann er entweder eine Adresse aus dem Bereich 192.168.178.2 – 192.168.178.19 oder aus dem Bereich 192.168.178.201 – 192.168.178.254.
Alternativ zum DHCP-Server auf dem Router kann auch auf vielen NAS-Systemen (Siehe auch das Kapitel Netzwerkfestplatten) ein alternativer DHCP-Server eingerichtet werden. Wichtig ist, dann den DHCP-Server auf dem Router zu deaktivieren, da es ansonsten zu Problemen kommen kann.
Ein eigener DHCP-Server ist oft auch eine Vorrausetzung für einen eigenen DNS-Server, da dieser meistens nicht über den in einem Router eingebauten DHCP-Server verteilt werden kann.
Wichtig:
Die IP-Adresse wird immer einer Netzwerkkarte zugewiesen, nicht dem Host. Ein Host, der über mehrere Netzwerkschnittstellen verfügt, kann daher auch mehrere IP-Adressen haben. Gewollt ist dies zum Beispiel bei einem Router, da dieser ja Netzwerkpakete in unterschiedliche Netze „routen“ soll. Bei einem Laptop kann es aber durchaus passieren, dass er eine IP-Adresse über seinen WLAN-Adapter bekommt, während er per Kabel ebenfalls eine IP-Adresse bekommen hat. Diese Konfiguration sollte jeden Fall vermieden werden, da dann IP-Pakete über beide Adressen gesendet und empfangen werden können und es dabei zu Übertragungsfehlern kommt.
Statische IP-Adressen
IP-Adressen können natürlich auch manuell den Hosts zugewiesen werden. In kleinen Netzwerken ist dies kein Problem, allerdings sollte man dann doch lieber eine Excel-Tabelle mit den zugewiesenen IP-Adressen pflegen, da es sonst leicht zu doppelten IP-Adressen kommen kann. Dabei können sich auch leicht Tippfehler oder Zahlendreher einschleichen, die dann meist eine lange Fehlersuche bedeuten. Daher ist die Konfiguration mittels DHCP der manuellen Vergabe der Adressen vorzuziehen.
Bei Serversystemen sollte allerdings immer eine manuelle Konfiguration der Netzwerkschnittstelle durchgeführt werden, da diese Dienste häufig eine entsprechende Konfiguration vorrausetzen. Ein Windows Server meckert gerne, wenn er eine dynamische IP-Adresse per DHCP zugewiesen bekommt. Microsoft selber unterstützt keine dynamische Adressvergabe bei Servern, obwohl es funktioniert und in bestimmten Situationen auch nicht anders geht.
Gerade bei Geräten, die ausschließlich über das Netzwerk konfiguriert werden können (kleine Printserver, NAS-Systeme oder ähnliches) ist die Verwendung von DHCP zur Netzwerkkonfiguration ein Muss. Bei diesen Geräten ist die IP-Adresse von außen nicht zu ermitteln, und meistens befindet sich auch kein Aufkleber mit der aktuellen IP-Adresse am Gerät. Die Dokumentation solcher Einstellungen wird gerne vergessen. Daher sollte im Zweifel immer die Konfiguration per DHCP aktiviert bleiben und die Zuweisung der IP-Adressen, wenn benötigt, über eine Reservierung auf dem DHCP-Server erfolgen.
DNS
(Domain Name System, UDP, TCP, Port 53)
Wir haben jetzt mit DHCP oder auch manuell jedem Gerät im Heimnetzwerk eine eigene IP-Adresse zugewiesen. Nun ist man als Mensch durchaus lernfähig und kann sich alle IP-Adressen der Geräte problemlos merken. Trotzdem würde es in manchen Situationen schon Sinn machen, nicht immer eine IP-Adresse eintippen zu müssen, um auf ein Gerät zugreifen zu wollen. Eine Übersetzungstabelle für IP-Adressen in Namen wäre dafür am besten geeignet. Und genau diese gibt es in Form der hosts-Datei auf jedem Windows- oder Linux-PC.
Unter Windows befindet sich diese Datei unter C:\Windows\System32\drivers\etc und hat auf einem frisch installierten Windows 7 diesen Inhalt:
# Copyright (c) 1993-2009 Microsoft Corp. # # This is a sample HOSTS file used by Microsoft TCP/IP for Windows. # # This file contains the mappings of IP addresses to host names. Each # entry should be kept on an individual line. The IP address should # be placed in the first column followed by the corresponding host name. # The IP address and the host name should be separated by at least one # space. # # Additionally, comments (such as these) may be inserted on individual # lines or following the machine name denoted by a '#' symbol. # # For example: # # 102.54.94.97 rhino.acme.com # source server # 38.25.63.10 x.acme.com # x client host # localhost name resolution is handled within DNS itself. # 127.0.0.1 localhost # ::1 localhost
Alle Zeilen beginnen mit einem # (Doppelkreuz, Lattenzaun oder Hashtag) und werden als Kommentar in der Datei vom Betriebssystem ignoriert.
Die Einträge in dieser Datei werden in der Form „IP-Adresse“ „Name“ eingefügt und können wieder mit einem Doppelkreuz, gefolgt von einem Kommentar, abgeschlossen werden. In jeder Zeile kann nur eine Zuordnung erfolgen.
Sollte die Datei auf ihrem PC einen anderen Inhalt haben, so kann dies zu unerwünschten Effekten führen. Eine Zeile wie diese:
204.79.197.200 www.google.com
führt dazu, dass bei Aufruf von www.google.com die Seite www.bing.com aufgerufen wird. Nicht unbedingt das erwartete Ergebnis, aber genau das, was in der hosts-Datei eingetragen wurde. Normalerweise würde man eine hosts-Datei im Heimnetzwerk vielleicht so füllen:
192.168.178.1 fritzbox 192.168.178.31 drucker 192.168.178.41 tv 192.168.178.101 pc1 192.168.178.102 pc2 192.168.178.103 laptop 192.168.178.104 tablet
Diese Datei muss natürlich auf alle Geräte verteilt werde, die diese Informationen im Netz benötigen. Bei einer Änderung der Konfiguration muss die Datei erneut verteilt werden, da sonst die Geräte mit unterschiedlichen Informationen arbeiten. In einem Heimnetzwerk ist das ein durchaus gangbarer Weg. Je grösser ein Netzwerk allerdings wird, desto komplexer wird diese Verteilung und umso mehr Fehler schleichen sich dort ein. Insbesondere bei der dynamischen Vergabe der IP-Adresse mit einem DHCP-Server benötigt man eine Lösung, die diese Namensliste automatisch aktualisiert.
Die Lösung lautet in diesem Fall dann DNS – Domain Name System und wurde 1983 entworfen. Es löst die Probleme, die mit lokalen Hosts-Dateien und deren Größe und Verteilproblemen auftreten können.
Das DNS baut auf einer hierarchischen, in einer Baumstruktur angelegten Datenbank auf. Die einzelnen Namensbestandteile sind durch Punkte voneinander getrennt. Der eigentlich abschließende Punkt wird weggelassen. Der Baum beginnt in der ersten Ebenen mit den TLDs (Top Level Domains) wie COM, ORG, NET, DE, UK, NL, DK. Die DNS-Server für diese TLDs werden von den jeweiligen, länderspezifischen NICs (Network Information Center) verwaltet. Dort werden auch die Domains registriert und verwaltet. Für die TLD „DE“ ist die DeNIC in Frankfurt/Main zuständig.
Das DNS ist in Zonen organisiert, ein DNS-Server ist für eine Zone verantwortlich (primärer DNS-Server) und kann Anfragen zu dieser Zone/Domäne direkt beantworten. Für die Domäne/Zone bielefeld.de ist dies der Nameserver pns.dtag.de und secondary.dtag.de. Diese Informationen lassen sich bei der jeweiligen NIC, die für die TLD zuständig ist, über eine sogenannte Who-Is-Abfrage erfahren.
Ein Host, der in der DNS-Domäne knufinke.net mit dem Hostname solar installiert wurde, wird also im DNS über den FQDN (Full Qualified Domain Name) solar.knufinke.net angesprochen.
Soll diese Adresse über den Internet Explorer erreicht werden, so sendet der PC eine Anfrage mit dem Namen solar.knufinke.net an den konfigurierten DNS-Server. Dieser ermittelt anhand des Domänensuffix (knufinke.net), ob er selber für die Domäne verantwortlich ist. Wenn dies der Fall sein sollte, liefert er die Adresse des Hosts aus seiner eigenen Tabelle an den anfragenden Host aus.
Sollte dies nicht der Fall sein, so schaut in seinem Cache nach, ob er die Anfrage schon einmal beantwortet hat. Jeder DNS-Eintrag hat eine bestimmte Gültigkeitsdauer, dies definiert die Zeit, die ein DNS-Client den Eintrag zwischenspeichern darf. Ist die Adresse nicht im Cache enthalten, so fragt der DNS-Server den für ihn zuständigen, übergeordneten DNS-Server nach dem DNS-Server, der für die DNS-Zone knufinke.net zuständig ist. Kann dieser die Anfrage nicht beantworten, so wird der Nameserver für die Zone .net ermittelt und dort nach dem Nameserver für knufinke.net nachgefragt.
Der Client schickt so seine DNS-Anfragen den Baum hinauf, bis ein Name-Server die Anfrage beantworten kann. Dieser schickt die Antwort zurück an die anfragenden Nameserver, bis die Abfrage des Clients beantwortet werden kann. Die Antworten werden auf den betroffenen Nameservern dann zwischengespeichert, um bei erneuten Anfragen das Ergebnis schneller liefern zu können.
Weltweit sind derzeit 13 Root-DNS-Server installiert, welche die Wurzel des weltweiten DNS-Baum darstellen. Jeder Root-Server ist über seine IP-Adresse zu erreichen. Zur Last-Verteilung setzen die Server Anycast ein, so dass die 13 Adressen tatsächlich über mehrere hundert Server weltweit erreichbar sind.
Ein Ausfall dieser Server würde theoretisch einen Zusammenbruch des Internets bedeuten, da die Infrastruktur zur Namensauflösung auf diesen Servern beruht. Da aber die DNS-Einträge auch auf tausenden von Nameservern z.B. der Internet-Zugangsprovider zwischengespeichert werden, haben Angriffe auf diese Server zumeist nur eine geringe Auswirkung auf die Namensauflösung im Internet. (siehe Wikipedia-Artikel Root-Nameserver).
Ein DNS-Server kann auch zur umgekehrten Namensauflösung (Reverse Lookup) konfiguriert werden. Dabei werden dann IP-Adressen zu DNS-Namen (FQDN) aufgelöst.
Die Namensauflösung innerhalb des Heimnetzwerks kann auch mit Hilfe eines DNS-Servers durchgeführt werden. Bei Nutzung einer Fritz!Box lautet der interne Domänenname fritz.box, und die angeschlossenen Hosts tragen sich mit ihrem Hostname in dieses DNS-System ein. Der Nameserver auf der Fritz!Box ist für die Domäne fritz.box verantwortlich und kann diese Anfragen dann direkt beantworten. Alle Anfragen an eine andere Domäne (google.com, telekom.de) werden an die Nameserver weitergegeben, die der Router bei der Verbindung mit dem Internet zugewiesen bekommen hat.
Die interne DNS-Zone sollte entweder eine untergeordnete Zone zum eigenen Domänennamen sein (bei mir z.B. intern.knufinke.net) oder eine Domäne mit einem im Internet nicht verwendeten Namen, da es sonst zu Problemen mit der Namensauflösung kommt.
Wenn der interne Domänenname z.B. bielefeld.de lautet, so ist der interne DNS-Server für diese Domäne verantwortlich. Ein Aufruf der Webseite www.bielefeld.de kann nicht durchgeführt werden, da der DNS-Server die IP-Adresse für den Eintrag www nicht kennt. In diesem Fall muss dann die IP-Adresse des Servers www.bielefeld.de im eigenen DNS gepflegt werden und bei Änderungen im externen DNS auch im internen DNS nachgetragen werden.
Früher wurden gerne Domänennamen wie firmenname.local oder firmenname.intra für den internen DNS genutzt. Mittlerweile werden von der ICANN, der Internet Corporation for Assigned Names and Numbers, sehr viele neu TLDs registriert, unter anderem auch .local. Das führt dann zu den oben angeführten Problemen mit der Namensauflösung. Als Best Practice wird mittlerweile Empfohlen, eine eigene Domäne zu registrieren und die interne Domäne dann als untergeordnet zu dieser anzulegen.
Die Installation eines eigenen DNS-Servers kann auch auf vielen NAS-Systemen durchgeführt werden. Wird ein DNS-Server für das Heimnetz auf einem NAS installiert, so sollte sichergestellt sein, dass das Gerät immer eingeschaltet bleibt, da ohne funktionierende Namensauflösung auch der Internet-Zugang gestört ist. Im Kapitel Netzwerkfestplatten gehe ich näher auf diese Konstellation ein.
WINS
(Windows Internet Name Service, Port 137 UDP)
WINS ist ein älteres Protokoll zur Namensauflösung in Windows-Netzwerken. Der Name bedeutet zwar Windows Internet Naming Service, allerdings dient das Protokoll nur zur Namensauflösung in internen Netzwerken.
Im Gegensatz zum DNS ist WINS nicht hierarchisch aufgebaut, sondern verwaltet nur einen flachen Namensraum. Die Host-Namen dürfen eine maximale Länge von 16 Zeichen nicht überschreiten. Von diesen 16 Zeichen dürfen nur 15 Zeichen als Hostname verwendet werden, das 16. Zeichen definiert den Resource-Typ des Hosts:
00h – Arbeitsstationsdienst
03h – Nachrichtendienst
20h – Serverdienst
Die Zugehörigkeit zu einem WINS-Namensraum wird über die Mitgliedschaft des Computers zu einer sogenannten Arbeitsgruppe (Workgroup) definiert. Nur die Hosts, die zu der gleichen Arbeitsgruppe gehören, werden im Windows Explorer unter Netzwerk angezeigt.
Die Zuordnung von Computernamen zu IP-Adressen kann mit einer Datei lmhosts konfiguriert werden. Diese entspricht vom Aufbau der hosts-Datei zur Namensauflösung im DNS. Im Verzeichnis c:\Windows\System32\Drivers\etc liegt eine Datei mit dem Namen lmhosts.sam, die als Vorlage genutzt werden kann.
Die Einstellungen zur Arbeitsgruppe sind über die Systemsteuerung > System und Sicherheit > System änderbar.
Wenn kein dedizierter WINS-Server im lokalen Netz installiert ist, erfolgt die Namensauflösung per Broadcast, es wird also im gesamten lokalen Netz nach einem Namen gesucht. Der Host mit dem gesuchten Namen antwortet dann mit seiner IP-Adresse.
Um die Namensauflösung ohne WINS-Server zu beschleunigen, wird im Netzwerk ein Host zum sogenannten Masterbrowser „gewählt“. Die Wahl zum Masterbrowser gewinnt normalerweise der Rechner, der das aktuellste Microsoft-Betriebssystem nutzt. Sollten mehrere Host damit ausgerüstet sein, so wird zusätzlich die aktuelle Laufzeit des Host als Auswahlkriterium gewählt.
Ein Problem dieses Mechanismus ist das dadurch gerade im Heimnetz der Masterbrowser öfter auf einen anderen Host wandert und die WINS-Datenbank neu aufgebaut werden muss. Das Problem kann aber bei der Nutzung einer Netzwerk-Festplatte dadurch gelöst werden, diese zum Masterbrowser im Heimnetz zu erklären.
Bei einem NAS mit dem Betriebssystem OpenMediaVault sehen die Einstellungen zum Beispiel so aus:
Das WINS-Protokoll gilt eigentlich als überholt und veraltet, allerdings habe ich häufiger die Erfahrung gemacht, das alleine die Aktivierung dieses Protokolls in Netzwerken mit Windows-Rechnern zu besserer Performance und Fehlerminimierung führt. Da es auch außer der Aktivierung keine weiteren Konfigurationsoptionen gibt, würde ich diesen Dienst mittlerweile immer aktivieren. Microsoft selber wollte WINS schon oft abschaffen, der Dienst ist allerdings in den neusten Versionen von Windows Server immer noch enthalten.
Mit der Einführung von Windows 10 scheint es öfter Probleme mit WINS zu geben, da auf der Netzwerkkarte nach der Installation „NetBios über TCP/IP deaktivieren“ ausgewählt ist. Die Einstellung muss dann auf „aktivieren“ korrigiert werden.
NTP
(Network Time Protocol, UDP Port 123)
Mit Hilfe des NTP-Protokolls können die Uhren der Hosts in einem Netzwerk miteinander und zu einer Referenzzeitquelle synchronisiert werden. Die meisten Router können als NTP-Client die von einem NTP-Server aus dem Internet bezogene Zeitinformation nutzen und als NTP-Server im Heimnetzwerk weitergeben. Im Internet existiert ein Pool von NTP-Servern, von dem jeder die aktuelle Uhrzeit über das NTP-Protokoll beziehen kann. Im Heimnetzwerk sollte nur ein Host die Zeit per NTP aus dem Internet beziehen und diese dann wieder als Server zur Verfügung stellen.
Bei der Fritz!Box kann der Zeitserver unter Heimnetz > Netzwerk > Netzwerkeinstellungen konfiguriert werden.
