In zwei Jahrzehnten als Vollzeitnerd hat sich der ein oder andere Text angesammelt, mit denen ich unseren Azubis versucht habe, Grundlagen über unseren Job (TCP/IP, aber auch bevorzugt Telefonie) zu erklären.

Das stelle ich hier, wann immer ich so einen Text nochmal irgendwo finde, zusammen. Diese Texte haben nicht den Anspruch, zu 100% exakt zu sein (sondern manches ist des besseres Verständnisses wegen vereinfacht worden). 

Heute:

Damit "das Internet", aber auch die Datenübertragung zwischen z.B. Deinem PC und Deinem Drucker funktioniert, braucht es "TCP/IP". Und darum hat auch jedes Deiner Geräte eine IP-Adresse. Und eine Netzmaske (Subnet mask) und ein Gateway (Default Router).

Nur der Vollständigkeit halber erwähnt: Als ich mit diesem ganzen IT-Kram angefangen hatte, liefen auf den PCs noch andere Protokolle - NetBEUI (Windows), IPX/SPX (Windows an Novell Netware-Server), AppleTalk unter MAC. Und auch über diese Protokolle könnte man heute noch Daten austauschen, Drucker ansteuern etc., die spielen aber insbesondere im Internet keine Rolle.

Das wichtigste Protokoll im Alltag ist "TCP/IP", wobei das der Name einer ganzen Protokoll-Familie ist, die viel größer ist:

• Es gibt das eigentliche Internet Protocol (IPv4) zur Adressierung der PCs, Server, Drucker, ... darauf gehe ich hier ein
• und darauf dann für den eigentlichen Transport das Transmission Control Protocol (TCP) und seiner Schwester User Datagram Protocol (UDP), auf deren Unterschiede gehe ich separat ein 
• Plus ICMP, das Internet Control Message Protocol, das für die Kommunikation, ob eine IP-Adresse erreichbar ist (z.B. bei einem ping, siehe nächter Teil) genutzt wird
• Nicht direkt zur Familie dazu gehörend, aber verwandt (eine OSI-Schicht weiter unten): Das Address Resolution Protocol ARP, das die Beziehung zwischen Netzwerkkarte/MAC-Adresse und IP-Adresse regelt 
• Ebenfalls verwandt, aber weiter oben im OSI-Modell: Dynamic Host Configuration Protocol (DHCP), das IP-Adressen und mehr auf Geräte verteilt, das brauchen wir gleich auch noch, und das Domain Name System (DNS), ein Thema für sich, ohne das TCP/IP im Prinzip im Alltag unbrauchbar wäre.

Und dann gibt es noch die eigentlichen Anwendungsprotokolle (HTTP/HTTPS für Webseiten, SMTP/POP3/IMAP4 für Mailverkehr, SMB/WebDAV für Netzlaufwerke, und natürlich Session Initiation Protocol SIP für IP-Telefonie). Aber Grundlage derer ist jeweils eine funktionierende IP-Verbindung.

Zum Schluss ein Blick in die Zukunft: IP-Adressen sind knapp, weshalb (viel zu langsam) der Wechsel von IPv4 auf IPv6 erfolgt. Die Netzwerkgrundlagen sind ziemlich gleich, darum versuche ich hier, nach und nach die wesentlichen Unterschiede nachzutragen.

Am Anfang schuf Gott die IP-Adresse. Oder so. So ziemlich jeder PC hat eine, meine ist z.B. 192.168.178.10. Die anderen Geräte hier im Haus fangen auch mit 192.168.178. an, mein Router z.B. hat die 192.168.178.1, mein Drucker die 192.168.178.8 usw.

Der Server, auf dem www.vollzeitnerd.de läuft, hat die 80.237.226.3. Die sieht also ganz anders aus.

Wenn mein PC jetzt drucken will, dann kontaktiert er die IP des Druckers:

• Weil wir erstmal im OSI-Schichtenmodell eine Etage nach unten (Layer 2, Netzwerkebene) müssen, benutzt er ein Hilfsprotokoll zur Zuordnung, nämlich das "Address Resolution Protocol (ARP)". Und er brüllt (sog. Broadcast an alle) dann auf Layer 2 einfach folgende Nachricht, ein sog. ARP-Request ins Kabel: "Who has 192.168.178.8? Tell 192.168.178.10". Dieses Request trägt als Absender die MAC-Adresse (Media Access Control Address) meiner Netzwerkkarte, das ist sozusagen die eindeutige Seriennummer, auf die die Netzwerkkarte hört. 
• Der Drucker hängt im gleichen Kabel (oder im gleichen WLAN, der Ablauf ist exakt der gleiche), erkennt seine IP-Adresse und antwortet gezielt meinem PC: "192.168.178.8 is at 12:34:56:78:9a:bc", wobei er seine MAC-Adresse dann hinten angibt. 
• Jetzt wissen beide, wer der jeweils andere ist, und merken sich die Verbindung zwischen IP und MAC-Adresse in ihrem sog. ARP-Cache. Die Netzwerkkomponenten dazwischen (Switch oder WLAN-AccessPoint) merken sich das ggf. übrigens auch, damit sie zukünftig die Daten gezielter an den richtige Netzwerkport (ins richtige Kabel) schicken können, um so das Netzwerk zu entlasten.

Okay, nachdem die beiden sich jetzt kennen, können sie miteinander kommunizieren. Jetzt kommen dann die Protokolle aus den höheren OSI-Ebenen zum Einsatz, z.B. JetDirect auf TCP-Port 9100 für einen Druckaufrag oder auch http auf Port 80, wenn ich auf das Webinteface des Druckers gehe.

Anders sieht es aus, wenn ich www.vollzeitnerd.de aufrufe, also mein PC per http auf Port 80 mit 80.237.226.3 kommunzieren muss. Das ist aber ein anderes Thema, nämlich das IP-Routing.

Vorher noch zu den IP-Adressen:

Die IP-Adressen der anderen bekommt man per "arp" rausfinden. Aber wie kommt die eigene IP in den PC rein? Man kann sie manuell konfigurieren: Die IP-Adresse, die Subnet mask und das Default Gateway (wofür die sind, dazu kommen wir im Routing-Kapitel) und den/die Nameserver (auch das ist ein anderes Kapitel). 

Für Server ist manuelle Konfiguration sinnvoll. Oder als ITler, "wenn man was testen will". Aber im Alltag ist die Einstellung "IP-Adresse automatisch beziehen" die bessere Wahl.

In diesem Fall kommt "DHCP", das Dynamic Host Configuration Protocol zum Einsatz:

• Der PC startet erstmal noch ohne IP-Adresse (0.0.0.0) und macht ein Broadcast (also eine Durchsage ins Netz an alle, die ihn hören), dass er DHCP-Server sucht ("DHCPDISCOVER")
• Der (oder die, s.u.) DHCP-Server antwortet mit einem Kommando "DHCPOFFER" und bietet eine freie IP an
• Der Client bestätigt dieses Angebot (oder eines der Angebote) mit DHCPREQUEST. Alle anderen Angebote, falls es mehrere gab, gelten damit als abgelehnt
• Der DHCP-Server merkt sich nun, dass die IP auch wirklich genutzt wurde und bestätigt das mit DHCPACK und weiteren Konfigurationsdaten.

Die beiden großen Vorteile sind:

• Der Administrator kann die Geräte in seinem Netzwerk zentral (über den DHCP-Server) mit Konfigurationsdaten ausstatten. Ändert sich z.B. das eigene Netz oder der DNS-Server, braucht er das nicht auf allen PCs ändern, sondern beim nächsten Neustart bekommen die Geräte vom DHCP-Server einfach die aktuellen Einstellungen
• Der User kann insbesondere mobile Geräte in verschiedenen Netzwerken benutzen (Büro, daheim, Hotel-WLAN, ...) und muss die Konfiguration nicht manuell ändern, sondern das Notebook holt sich vom jeweiligen DHCP-Server (daheim meist im DSL-Router eingebaut) einfach die für diesen Standort passende Konfiguration.

Per DHCP kommen IP-Adresse samt Netzmaske und Gateway auf den Client genauso wie Einstellungen wie NTP-Server (Uhrzeit), Proxy-Konfiguration (Web-Firewall). Man kann aber auch "eigene" Einstellungen setzen, z.B. könnten in einem Schulungsraum die PCs alle ohne Festplatte ausgestattet sein, holen sich per DHCP einen PXE-Server (Betriebssystem über Netzwerk beziehen) und bekommen von dem dann eine virtuelle DVD zum Start geliefert. Oder Unify-IP-Tischtelefone z.B. können per DHCP-Flag den Namen ihres DLS-Server (Autoprovisioning) mitgegeben bekommen - man packt das Telefon aus, steckt es ein und es findet selbständig den Weg zur Telefonanlage (wo es sich dann die Konfiguration abholt). Oder oder oder.

Wie schon angedeutet könnte man auch mehrere DHCP-Server in einem Netzwerk betreiben. Das sollte aber die Ausnahme sein, weil es, unsauber konfiguriert, auch ganz viel Ärger bereiten kann. Je ein sinnvoller und ein gefährlicher Anwendungszweck:

• In einem Netzwerk gibt es einen "normalen" DHCP-Server für die PCs, und einen speziell in der Telefoanlage (der gezielte Einstellungen an die Telefone ausrollt). Damit der erste nicht, und der zweite nur reagiert, wenn ein IP-Telefon eingesteckt wird, haben beide eine Black- bzw. Whitelist auf den ersten Teil der MAC-Adresse (die ersten Zeichen geben ja den Hersteller des Gerätes an)
• In einem Netzwerk wird böswillig ein DHCP-Server gestartet, der eine abweichende Konfiguration (manipulierter DNS, manipulierte Proxy-Einstellungen) verteilt und so Netzwerkverkehr für einen Man-in-the-middle-Angriff umlenken kann.

Ein Internet-Server (z.B. der, auf dem diese Webseite liegt) hat eine öffentliche IP-Adresse - die braucht er, damit er von außen erreichbar ist. Verwaltet und auf die Provider verteit werden diese IP-Netze in Europa z.B. vom www.ripe.net.

Jede öffentliche IP-Adresse darf es nur einmal geben. Nur einmal innerhalb eines Netzes, ansonsten würden sich die beiden gegenseitig stören. Und nur einmal weltweit, denn jedes IP-Netzwerk gibt es weltweit nur einmal (wie sollte man es sonst adressieren).

Ein PC daheim braucht in der Regel keine öffentliche IP-Adresse. Sie würde nicht schaden (bei IPv6 wird er auch eine bekommen können), aber zum einen ist eine direkte Erreichbarkeit aus dem Internet heraus unter Sicherheitsaspekten eher ein Nachteil. Und zum anderen gibt es einfach viel zu wenig IPv4-Adressen, um jedem Gerät eine geben zu können.

Darum arbeitet man mit NAT (Network Address Translation), was insbesondere bei IP-Telefonie oftmals stört, doch dazu später mehr. NAT funktioniert vereinfacht gesagt so, dass der z.B. DSL-Router (in seiner Aufgabe als NAT-Router)

• einerseits eine öffentliche IP-Adresse vom DSL-Provider bekommt 
• und andererseits ein sog. privates Netz (z.B. 192.168.irgendwas) daheim hat
• und dann die Anfragen übersetzt. Also stellt der PC mit der 192.168.178.10 eine Verbindung ins Internet her, dann schreibt der NAT-Router sie auf sich um (leitet sie also weiter, aber als Absender nimmt er seine öffentliche IP)
• und wenn vom Internet-Server die Antwort kommt, landet die beim NAT-Router und jetzt verhält er sich genau andersrum, ändert den Empfänger ab (nicht mehr sich selbst, sondern meinen PC) und leitet sie an meinen PC weiter.

Und damit das funktioniert, sind die privaten IP-Adressen festgelegt, es sind:

• 192.168.0.0 bis 192.168.255.255
• 172.16.0.0 bis 172.31.255.255
• 10.0.0.0 bis 10.255.255.255

Die kann man gefahrlos hinter einem NAT-Router benutzen, denn dafür sind sie da. Die dürfen nicht öffentlich benutzt werden, es kann also keine Überschneidung irgendwo geben.

Weiter zum Kapitel Routing