Trotz Datenflut bahnen sich Datenpakete zielstrebig ihren Weg durch das weltweite Netz. IP kennt den Weg, TCP sorgt für eine sichere Verbindung.

Obwohl sich die Zahl der Internetnutzer täglich vergrößert, finden die Daten ihren Weg durch das weltweite Netz. Woher weiß ein Paket, wohin es will? Was passiert, wenn sich Pakete überholen? Warum hat Ihr Rechner im Internet eine andere IP-Adresse als im heimischen Netzwerk? All diese Fragen berühren auch das Protokoll, das dem Internet zugrunde liegt: TCP/IP.

Wohin des Weges?

Gewöhnlich steckt in einem Rechner eine Netzwerkkarte mit einer weltweit eindeutigen MAC-Adresse. Diese besteht aus sechs Hexadezimalzahlen, die jeweils ein Doppelpunkt trennt, und lautet zum Beispiel 00:0C:6E:E0:6E:F0. Anhand dieser Hardware-Adresse identifizieren Sie auf der Ethernet-Ebene Sie einen Rechner im lokalen Netz und erlauben so auch nur bestimmten Rechnern den Zugang. Klinkt sich ein Angreifer heimlich mit seinem Laptop in ein Netzwerk ein, weist ihn der Router ab, da er die MAC-Adresse nicht kennt.

Um Rechner im Internet und anderen TCP/IP-Netzwerken eindeutig zu identifizieren, gibt es IP-Adressen. Sie funktionieren unabhängig von der Hardware. Zur Kommunikation schafft die TCP/IP-Implementation von Linux abstrakte Schnittstellen wie eth, fddi und ppp. Diese erhalten nicht nur IP-Adressen, sondern auch weitere Netzwerkinformationen wie eine Gateway-Adresse und eine Netzmaske (siehe Kasten “Subnetze”). Der Befehl /sbin/ifconfig listet alle konfigurierten Schnittstellen eines Rechners auf (Abbildung 1). Ohne Netzwerk besitzt ein Rechner nur die so genannte Loopback-Adresse 127.0.0.1, die auf ihn selbst verweist. Unter Linux offenbart das Kommando /sbin/ifconfig lo die Parameter für diese Schnittstelle.

/sbin/ifconfig listet unter Linux die konfigurierten Netzwerkschnittstellen auf. Er zeigt neben IP- und MAC-Adresse auch die jeweilige Netzmaske.” width=”300″ height=”146″ /> Abbildung 1: Der Befehl /sbin/ifconfig listet unter Linux die konfigurierten Netzwerkschnittstellen auf. Er zeigt neben IP- und MAC-Adresse auch die jeweilige Netzmaske.

Eine IP-Adresse besteht aus vier 8 Bit großen Blöcken, umfasst also insgesamt 32 Bit. Jeder der Blöcke erhält einen Wert zwischen 0 und 255. IP-Adressen meint hier genau genommen IPv4-Adressen. Sie gelten weltweit, ihre Zahl ist begrenzt. Es gibt rein rechnerisch etwas mehr als 4 Milliarden IPv4-Adressen. Die Zahl lässt sich durch Tricks vergrößern: Weil das Internet aber ständig wächst, entsteht seit einigen Jahren parallel ein IPv6-Netzwerk (Kasten “IPv6”), das wesentlich mehr Adressen umfasst. Es kommt allerdings in der Praxis noch recht selten zum Einsatz.

Die Verteilung der Adressen unterliegt einem strengen System, das zwar seit CIDR nicht mehr aktuell ist, in der Praxis aber noch immer zum Einsatz kommt. In diesem Modell gehören sämtliche IP-Adressen Netzklassen (siehe Tabelle “Netzklassen”) an.

Der Unterschied zwischen den Klassen besteht in ihrer Kapazität für Subnetze. IP-Adressen aus Netzklasse A umfassen wesentlich mehr Subnetze als Klasse-C-Adressen (siehe Kasten “Subnetze”). Die Klassen D, E und F sind für spezielle Zwecke reserviert.

Subnetze

Gibt es in einer Firma mehrere Abteilungen, unterteilen Admins das Firmennetz gern in Subnetze mit eigenen Domainnamen und Gateways (Abbildung 2). Alle Rechner mit der IP-Adresse 172.16.0.nnn gehören zu einem Subnetz. Der Admin ersetzt nnn jeweils durch Werte von 1 bis 254. In diesem Netzwerk kann es also 254 Maschinen geben; die “0” bezeichnet die Netzadresse, bei “255” handelt es sich um die Broadcast-Adresse für Rundsendungen an das gesamte Netz.

Die Netzmaske bestimmt, welcher Teil einer IP-Adresse das Netzwerk beschreibt und welcher den speziellen Host in dem Netzwerk. Ein gesetztes Bit markiert die Zuständigkeit für das Netzwerk, eine 0 die für den Host. Die Netzmaske 255.255.255.0 sagt also aus, dass die ersten 24 Bit der zugehörigen IP-Adresse das Netzwerk identifizieren, die letzten 8 Bit den Host in diesem Netzwerk.

Abbildung 2: Subnetze in einer Firma: Gateways vermitteln zwischen den Netzwerken.

Innerhalb der Klassen gibt es zudem jeweils einen Bereich von Adressen, die Sie nur in privaten Netzwerken einsetzen dürfen (siehe Tabelle “Private IP-Adressen”). Da Sie mit einer privaten IP-Adresse nicht ins Internet gelangen, nutzen Sie einen Router mit zwei und mehr Netzwerkschnittstellen als Gateway.

Routing und Gateways

Grundsätzlich gibt es zwei Arten, eine IP-Adresse zu erlangen: Entweder teilen Sie der Netzwerkschnittstelle manuell eine IP-Adresse zu oder konfigurieren die Netzwerkkarte so, dass sie sich per DHCP selbst eine IP-Adresse holt – meist von einem Router. Die heutigen Geräte für den Hausgebrauch betreiben of zugleich NAT, einen DHCP-Server und womöglich noch einen DNS-Server.

DHCP kommt auch zum Zug, wenn Sie sich mit einem DSL- oder analogen Modem bei Ihrem Provider einwählen. Das Modem authentifiziert sich beim entfernten Server, der versorgt es im Gegenzug mit einer öffentlichen IP-Adresse. Weist Ihnen der Provider jedes Mal dieselbe Adresse zu, handelt es sich um eine statische IP-Adresse. Erhalten Sie stets eine neue IP, vergibt er die Adressen dynamisch.

Gelangt Ihr Rechner trotz privater IP ins Internet, nutzt er vermutlich einen Router als Gateway. In vielen Haushalten gibt es mehrere Rechner: Der vom Provider gelieferte Router bündelt sie zu einem Netzwerk. Authentifiziert sich der Router bei einem Provider, erhält er per DHCP eine zusätzliche IP-Adresse, die im Internet gilt, und lernt zudem die Adresse eines DNS-Server kennen. Als Gateway im Netzwerk verfügt der Router aber bereits über eine IP-Adresse aus dem privaten Bereich – also besitzt er nun zwei IP-Adressen.

Schalten Sie Ihren Privatrechner ein, sucht dieser zunächst nach seiner IP-Adresse. Findet er keine, setzt er die eigene Adresse auf 0.0.0.0 und sendet über die Broadcast-Adresse 255.255.255.255 eine DHCP-Suchanfrage an alle Rechner im Heimnetz. Der DHCP-Server des Routers antwortet auf den Ruf und weist dem Rechner eine IP-Adresse zu. Zusätzlich übermittelt er seine eigene private IP-Adresse – etwa 192.168.0.1 – als Gateway-Adresse und erklärt sich damit zum zuständigen Gateway für Ihren Computer. Das bedeutet: Alle Pakete, die an ein unbekanntes Netzwerk gehen, schickt der PC erst einmal zum Gateway. Zuvor durchläuft eine HTTP-Anfrage aber auf dem Rechner selbst ein paar Stationen, bis sie zum Gateway gelangt.

DNS – kein Schall und Rauch

Zunächst einmal löst ein DNS-Server den Seitennamen auf. Kennen Sie die IP-Adresse von http://www.linuxuser.de? Vermutlich nicht, Ihr Rechner genauso wenig. DNS sorgt dafür, dass Sie in Ihrem Browser diesen Namen statt einer IP-Adresse angeben und die richtige Site erscheint.

DNS ordnet IP-Adressen Namen zu, um sie für Menschen leichter handhabbar zu machen, und funktioniert wie ein Telefonbuch. Ursprünglich standen sämtliche IP-Adressen und die dazugehörigen Hostnamen in einer Datei. Als das Internet wuchs, hierarchisierte man das System und verteilte die Datenbank auf tausende Server weltweit. Weiß ein DNS-Server nicht, welche IP-Adresse sich hinter linuxuser.de versteckt, leitet er die Anfrage an einen hierarchisch höher gestellten DNS-Server weiter.

Ein voll qualifizierter Domainname setzt sich aus Host- und Domainnamen zusammen. Der Domainname funktioniert netzwerkübergreifend und unabhängig von IP-Adressen. Angenommen Ihr Netz zu Hause heißt home und Ihr Rechner sonne, dann lautet der volle Domainname des Rechners sonne.home. Auch linuxuser.de ist nur ein Domainname. Zu dieser Domain können mehrere Rechner mit unterschiedlichen Hostnamen gehören, zum Beispiel mond.linuxuser.de oder erde.linuxuser.de.

Protokoll privat

Was passiert aber genau, wenn Sie mit Ihrem privaten Rechner sonne.home auf die Domain www.linuxuser.de zugreifen?

Die Daten wandern zunächst durch die Schichten des TCP/IP-Protokolls, das sie in IP-Pakete verwandelt. Das TCP/IP-Protokoll basiert auf dem OSI-Modell und besteht aus vier Schichten: einer Anwendungsschicht, einer Transportschicht, einer Internetschicht und einer Netzzugangsschicht (Abbildung 3).

Abbildung 3: Das Schichtenmodell von TCP/IP orientiert sich am OSI-Modell. Die Daten wandern von der Anwendungsschicht zur Netzzugangsschicht.

Auf der Anwendungsschicht (OSI-Schichten 5 bis 7) schickt Firefox über das HTTP-Protokoll eine Anfrage an http://www.linuxuser.de. Zunächst verwandelt der DNS-Server die URL wie oben beschrieben in eine IP-Adresse. Die Daten der HTTP-Anfrage schreibt der Browser dann in einen Puffer. Die TCP-Software auf der Transportschicht (OSI-Schicht 4) verwandelt sie in TCP-Segmente von höchstens 1500 Bytes. Ein TCP-Segment besteht jeweils aus zwei Teilen – einem TCP-Header und den Daten (Nutzlast).

Der Header besteht aus diversen Feldern, die Informationen zum Paket enthalten. Sie beschreiben unter anderem, welche Ports die Daten nutzen, und beinhalten eine Checksumme, um die Integrität der Daten zu prüfen. Zudem enthält der Header Sequenznummern, über die der Empfänger die Reihenfolge der Pakete rekonstruiert, da diese sich mitunter gegenseitig überholen. Auf der Transportschicht tummeln sich übrigens auch noch die Protokolle UDP und ICMP.

Das Internet Protocol (IP) verwandelt die TCP-Segmente auf der Internetschicht (OSI-Schicht 3) in Datenpakete. Sie erhalten einen IP-Header, der Quell- und Zielort des Pakets kennt. Er enthält aber nicht nur die IP-Adressen von Sender und Empfänger, sondern auch die IP-Version (IPv4 oder IPv6) sowie ein TTL-Feld, das verrät, nach wie vielen Hops das Paket verfällt.

Auf der Netzzugangsschicht (OSI-Schicht 1 und 2) stattet schließlich Ethernet die TCP/IP-Pakete mit einem Header und einem Tail aus. Es versieht sie mit der MAC-Adresse und verschickt sie in Form handlicher Nullen und Einsen. Gilt die Zieladresse nur im internen Netzwerk, schickt der Rechner selbst die Daten an den Rechner. Soll das Paket aber ins Internet, braucht es eine öffentliche Senderadresse.

In diesem Fall geht das Paket an das Gateway – etwa den Router mit der Adresse 192.168.0.1. Nun kommt NAT ins Spiel (Abbildung 4). Der Router ersetzt einfach in den IP-Headern sämtliche lokale IP-Adressen des Senders durch seine eigene öffentliche IP-Adresse und ändert zudem die Ausgangsports, um später die eingehenden Pakete voneinander zu unterscheiden. Dann leitet er die modifizierten Pakete an das Gateway des Providers weiter.

Der empfangende Server – etwa mond.linuxuser.de – glaubt, die Anfrage stamme vom Router selbst. Also schickt er eine Bestätigungsnachricht an den Router als Empfänger zurück. Der identifiziert anhand einer internen Tabelle, der Sender-IP und des Ports den ursprünglichen Sender, ändert Zieladresse und Port erneut und stellt das Paket dem passenden Rechner zu.

Abbildung 4: Viele Router arbeiten auch als NAT-Gateway: Sie besitzen zwei Netzwerkkarten, übersetzen private in öffentliche IP-Adressen und umgekehrt.

TCP vs. UDP

Statt TCP-Segmente kann IP auch UDP-Segmente befördern, allerdings gibt es zwischen beiden erhebliche Unterschiede.

TCP baut daher zur Datensicherung eine permanente, bidirektionale Verbindung zwischen den Kommunikationspartner auf. Es spürt verlorene Pakete auf und sorgt dafür, dass der Sender sie erneut verschickt. Über die Checksumme und die Sequenznummern prüft das Protokoll gegebenenfalls die Integrität und Konsistenz der Daten.

UDP sendet hingegen einfach Pakete nach dem Motto “Fire & Forget” und prüft nicht, ob sie ankommen. Die Integrität der Daten sichert – wenn überhaupt – die Software auf der Anwendungsschicht. Der Vorteil: UDP erwartet keine Reaktion von der anderen Seite und baut keine Verbindung auf. Dadurch entsteht etwa ein Drittel weniger Overhead im Netzwerk.

Port Forwarding

Zwar tauscht NAT fleißig die Quell- und Zieladressen der ein- und ausgehenden Pakete – das genügt aber nicht immer. Vor allem dann nicht, wenn der entfernte Rechner als Client eine Verbindung initiiert, um auf einen lokalen Server zuzugreifen. Das ist bei Spielen der Fall, aber auch P2P-Anwendungen wie Amule und Azureus verlangen nach Port Forwarding. Der Begriff hat sich bei den Herstellern der Router eingebürgert, eigentlich handelt es sich aber um so genanntes Destination NAT.

Angenommen, der Server läuft auf sonne.home und horcht auf Port 6666. Der Router verwirft die Anfrage, weil er nicht weiß, dass Port 6666 auf sonne.home auf eingehende Verbindungen wartet. Über Port Forwarding teilen Sie ihm mit, er soll die Daten, die auf diesem Port ankommen und zu einer bestimmten Anwendung gehören, an sonne.home weiterleiten. Um den Router entsprechend zu konfigurieren, geben Sie dessen Gateway-Adresse im Browser ein. Es erscheint in der Regel ein grafisches Benutzer-Interface, über das Sie den Router verwalten. Mit ein paar Mausklicks leiten Sie den Port weiter und prüfen dann, ob Ihre Anwendung korrekt arbeitet.

Tiefer einsteigen

Dieser Schnelleinstieg in TCP/IP hat die wichtigsten Begriffe gestreift und deren Bedeutung erläutert – auf vier Druckseiten lässt sich kaum mehr leisten. Weitere Informationen zum Thema finden Sie beispielsweise bei Wikipedia unter dem Schlagwort “Internetprotokollfamilie” [1] sowie den dort verlinkten Artikeln.

Möchten Sie tiefer in das Thema einsteigen, empfiehlt sich der Erwerb entsprechender Lektüre in Buchform. Ein beliebtes Standardwerk zum Thema mit zahlreichen Beispielen aus Unix-Sicht ist “TCP/IP-Netzwerkadministration” von Craig Hunt [2].

Zu TCP/IP gibt es nicht nur zahlreiche dicke Bücher: Über Programme wie Iptraf [3] oder Wiretraf [4] verfolgen Sie live am Rechner, welchen Weg Ihre TCP/IP-Pakete nehmen und welche Ladung Sie tragen.