Suche im Katalog
Linux Netzwerker-Handbuch

Linux Netzwerker-Handbuch


Tony Bautts, Terry Dawson & Gregor N. Purdy
3. Auflage Juli 2005
ISBN 3-89721-414-8
382 Seiten
Weitere Informationen zur gedruckten Version des Buches finden Sie unter:
www.oreilly.de/catalog/linag3ger/

Zur Übersicht aller OpenBooks


TOC PREV NEXT INDEX

Kapitel 2

Aspekte der Netzwerkarbeit mit TCP/IP

In diesem Kapitel wenden wir uns den Entscheidungen zu, die Sie bei der Konfiguration einer Linux-Maschine treffen müssen, wenn Sie diese an ein TCP/IP-Netzwerk anschließen wollen. Dazu gehören unter anderem der Umgang mit IP-Adressen, Hostnamen und Routing-Angelegenheiten. Sie erhalten hier alle nötigen Hintergrundinformationen, um die Anforderungen Ihres Systems zu verstehen. Die nächsten Kapitel behandeln die Werkzeuge, die Sie dabei verwenden werden.

Wenn Sie mehr über TCP/IP und dessen Hintergründe erfahren wollen, sollten Sie sich das aus drei Bänden bestehende Internetworking with TCP/IP von Douglas R. Comer (Prentice Hall) ansehen. Eine etwas detailliertere Anleitung zur Verwaltung eines TCP/IP-Netzwerks finden Sie in TCP/IP-Netzwerk-Administration (O'Reilly) von Craig Hunt.

Netzwerkschnittstellen

Um den Anwender nicht mit den vielfältigen technischen Details der Ausrüstung zu belasten, die in einem Netzwerk eingesetzt werden kann, definiert TCP/IP eine abstrakte Schnittstelle, über die auf die Hardware zugegriffen wird. Diese Schnittstelle bietet eine Reihe von Operationen an, die für jede Hardware gleich sind und sich im Wesentlichen mit dem Senden und Empfangen von Paketen beschäftigen.

Für jedes periphere Gerät, das Sie für das Netzwerk verwenden wollen, muss eine entsprechende Schnittstelle im Kernel präsent sein. Zum Beispiel werden Ethernet-Schnittstellen unter Linux eth0 und eth1 genannt. Die Schnittstellen für PPP (siehe Kapitel 6) haben die Bezeichnungen ppp0 und ppp1, während FDDI-Schnittstellen mit fddi0 und fddi1 angesprochen werden. Die Namen dieser Schnittstellen werden zu Konfigurationszwecken verwendet, wenn Sie eine bestimmte physische Einheit für den Kernel benennen wollen. Darüber hinaus haben sie keine besondere Bedeutung.

Um in einem TCP/IP-Netzwerk eingesetzt werden zu können, muss der Schnittstelle eine IP-Adresse zugewiesen werden, die als Identifizierung dient, wenn mit dem Rest der Welt kommuniziert wird. Diese Adresse ist nicht mit dem oben erwähnten Schnittstellennamen identisch. Vergleicht man eine solche Schnittstelle mit einer Tür, dann entspricht die Adresse dem an ihr befestigten Namensschild.

Natürlich können noch weitere Parameter des Geräts eingestellt werden. Einer dieser Parameter ist die maximale Größe der Datagramme, die von der Hardware verarbeitet werden können. Diese Größe wird auch als Maximum Transfer Unit oder MTU bezeichnet. Andere Attribute werden später eingeführt. Zum Glück haben die meisten Attribute sinnvolle Vorgabewerte.

IP-Adressen

Wie bereits in Kapitel 1 erwähnt, bestehen die vom IP-Netzwerkprotokoll verstandenen Adressen aus 32-Bit-Zahlen. Jeder Maschine muss eine für die Netzwerkumgebung eindeutige Adresse zugewiesen werden. Wenn Sie ein lokales Netzwerk betreiben, das keine Verbindung zu anderen Netzwerken unterhält, können Sie diese Adressen nach Ihren Wünschen frei vergeben. Einige IP-Adressen sind nur für private Netzwerke reserviert. Die entsprechenden Nummern sind in Tabelle 2-1 angegeben. Für Sites im Internet werden die Nummern dagegen von einer zentralen Stelle, dem Network Information Center (NIC), vergeben.

Zur einfacheren Lesbarkeit werden IP-Adressen in vier 8-Bit-Zahlen aufgeteilt, die man Oktette nennt. Beispielsweise hat quark.physics.groucho.edu die IP-Adresse 0x954C0C04, was als 149.76.12.4 geschrieben wird. Diese Schreibweise wird häufig als Dotted-Quad-Notation bezeichnet.

Ein weiterer Grund für diese Notation besteht darin, dass sich IP-Adressen aus einer Netzwerknummer in den führenden Oktetten und einer Hostnummer dahinter zusammensetzen. Wenn Sie beim NIC IP-Adressen beantragen, wird Ihnen nicht einfach eine bestimmte Adresse für jeden einzelnen Host zugewiesen, den Sie einbinden wollen, sondern Sie erhalten eine Netzwerknummer und dürfen innerhalb dieser Grenzen jede gültige IP-Adresse verwenden.

Die Länge des Hostanteils hängt von der Größe des Netzwerks ab. Um unterschiedlichen Bedürfnissen entgegenzukommen, gibt es unterschiedliche Netzwerkklassen, die unterschiedliche Aufteilungen von IP-Adressen definieren. Die Netzwerkklassen werden im Folgenden beschrieben:

Klasse A
Klasse A umfasst Netzwerke von 1.0.0.0 bis 127.0.0.0. Die Netzwerknummer ist im ersten Oktett enthalten. Es steht also ein 24 Bit langer Host-Anteil zur Verfügung, der für etwa 16 Millionen Hosts ausreicht.
Klasse B
Klasse B umfasst die Netzwerke 128.0.0.0 bis 191.255.0.0. Die Netzwerknummer ist in den ersten beiden Oktetten enthalten. Das erlaubt 16.320 Netzwerke mit jeweils 65.024 Hosts.
Klasse C
Klasse C umfasst die Netzwerke 192.0.0.0 bis 223.255.255.0. Die Netzwerknummer ist in den ersten drei Oktetten enthalten. Das gestattet mehr als 2 Millionen Netzwerke mit bis zu 254 Hosts.
Klassen D, E und F
Adressen, die im Bereich von 224.0.0.0 bis 254.0.0.0 liegen, sind entweder experimenteller Natur oder für zukünftige Verwendungen reserviert und spezifizieren kein Netzwerk. In diesen Bereich fällt IP-Multicast, ein Dienst, der es erlaubt, Informationen an mehrere Stellen gleichzeitig zu übertragen.

Wenn Sie zu unserem Beispiel aus Kapitel 1 zurückkehren, sehen Sie, dass 149.76.12.4, die Adresse von quark, auf den Hostrechner 12.4 im Klasse-B-Netzwerk 149.76.0.0 verweist.

Sie werden vielleicht bemerkt haben, dass in der obigen Liste nicht alle möglichen Werte für jedes Oktett des Hostanteils verwendet werden dürfen. Der Grund dafür liegt darin, dass die Oktette 0 und 255 für besondere Aufgaben reserviert sind. Eine Adresse, bei der der Hostanteil nur aus Nullen besteht, steht für das Netzwerk. Sind alle Bits des Hostanteils auf 1 gesetzt, spricht man von einer Broadcast-Adresse. Daten, die an diese Adresse geschickt werden, werden gleichzeitig von allen Hosts in dem angegebenen Netzwerk empfangen. 149.76.255.255 ist also keine gültige Hostadresse, sondern steht für alle Hosts im Netzwerk 149.76.0.0.

Manche Netzwerkadressen sind für besondere Zwecke reserviert, zum Beispiel 0.0.0.0 und 127.0.0.0. Die erste Adresse ist die so genannte Default- oder Standard-Route, die zweite die Loopback-Adresse. Die Standard-Route bildet einen Platzhalter für den Router, der in Ihrem lokalen Netzwerk dafür verwendet wird, um die Außenwelt zu erreichen.

Das Netzwerk 127.0.0.0 ist für den IP-Verkehr reserviert, der lokal auf Ihrem Host stattfindet. Üblicherweise wird die Adresse 127.0.0.1 einer speziellen Schnittstelle auf Ihrem Host, der Loopback-Schnittstelle, zugewiesen, die wie ein geschlossener Kreis funktioniert. Jedes von TCP oder UDP dorthin übergebene Paket wird direkt von dort zurückgegeben, als wäre es gerade von einem anderen Netzwerk angekommen. Auf diese Weise können Sie Netzwerksoftware entwickeln und testen, ohne jemals ein »echtes« Netzwerk verwenden zu müssen. Das Loopback-Netzwerk erlaubt Ihnen außerdem, Netzwerksoftware auf einem nicht vernetzten Host zu benutzen. Das ist nicht so ungewöhnlich, wie es auf den ersten Blick erscheinen mag. Beispielsweise können Dienste wie MySQL, die nur von anderen Anwendungen auf demselben Server verwendet werden, an die lokale Hostschnittstelle gebunden werden, um zusätzliche Sicherheit zu erreichen.

Einige Adressbereiche jeder Netzwerkklasse gelten als »reserviert« oder »privat«. Diese Adressen, die manchmal als RFC-1918-Adressen bezeichnet werden, sind für die Anwendung in privaten Netzwerken bestimmt und werden im Internet nicht geroutet. In der Regel werden sie von Einrichtungen benutzt, die ihr eigenes Intranet aufbauen. Aber sie werden häufig auch für kleinere Netzwerke verwendet. Die reservierten Netzwerkadressen können Tabelle 2-1 entnommen werden.

Tabelle 2-1
IP-Adressbereiche, die für private Zwecke reserviert sind
Klasse
Netzwerke
A
10.0.0.0 bis 10.255.255.255
B
172.16.0.0 bis 172.31.0.0
C
192.168.0.0 bis 192.168.255.0

Classless Inter-Domain Routing

Classless Inter-Domain Routing (CIDR), das in Kapitel 4 näher beschrieben wird, ist eine neuere und effizientere Methode zum Zuweisen von IP-Adressen. Mit CIDR können Netzwerkadministratoren Netzwerke zuweisen, die lediglich zwei IP-Adressen enthalten, und müssen nicht wie bei der früheren Methode alle 254 Adressen mit einem Klasse-C-Block zuweisen. Es gab mehrere Gründe für die Entwicklung von CIDR, die Hauptgründe waren jedoch die rasante Abnahme von IP-Adressen und verschiedene Kapazitätsprobleme mit den globalen Routing-Tabellen.

CIDR-Adressen werden mit einer neuen Notation geschrieben, die - Überraschung! - als CIDR-Block-Notation bezeichnet wird. Ein Beispiel ist 172.16.0.0/24. Diese Adresse repräsentiert den Adressbereich von 172.16.0.0 bis 172.16.0.255. Die 24 in der Notation bedeutet, dass 24 Adressbits gesetzt sind, wodurch 8 Bits der 32-Bit-Adresse übrig bleiben. Um die Anzahl der Adressen in diesem Bereich zu verringern, könnten wir die Anzahl der Adressbits um drei erhöhen. Wir erhielten die Netzwerkadresse 172.16.0.0/27. Jetzt wären nur noch fünf Bits für den Hostanteil übrig, das heißt, es könnten insgesamt noch 32 Adressen belegt werden. CIDR-Adressen können auch verwendet werden, um Bereiche zu erzeugen, die größer sind als eine Klasse C. Wenn Sie beispielsweise zwei Bits aus dem oben gezeigten 24-Bit-Netzwerkbeispiel entfernen, erhalten Sie 172.16.0.0/22. Das bietet einen Netzwerkbereich von 1.024 Adressen, also viermal größer als ein traditioneller Klasse-C-Raum. Einige gebräuchliche CIDR-Konfigurationen können Sie in Tabelle 2-2 sehen.

Tabelle 2-2
Gebräuchliche CIDR-Block-Notationen 
CIDR-Block-Präfix
Host-Bits
Anzahl der Adressen
/29
3 Bits
8
/28
4 Bits
16
/27
5 Bits
32
/25
6 Bits
128
/24
8 Bits
256
/22
10 Bits
1024

Auflösung von Adressen

Nachdem Sie nun gesehen haben, wie IP-Adressen aufgebaut sind, werden Sie sich vielleicht fragen, wie diese Adressen in einem Ethernet- oder Token Ring-Netzwerk benutzt werden, um unterschiedliche Hosts anzusprechen. Schließlich verwenden diese Protokolle ja ihre eigenen Adressen, um Hosts zu identifizieren, die absolut nichts mit einer IP-Adresse gemein haben, nicht wahr? Richtig!

Darum benötigen wir auch einen Mechanismus, der IP-Adressen auf die Adressen des zugrunde liegenden Netzwerks abbildet. Der eingesetzte Mechanismus heißt Address Resolution Protocol (ARP). Tatsächlich ist ARP nicht allein auf Ethernet oder Token Ring beschränkt, sondern wird auch bei anderen Netzwerkarten wie dem Amateurfunk-AX.25-Protokoll (kurz Ham-Radio) verwendet. Die ARP zugrunde liegende Idee entspricht genau dem, was die meisten Leute tun, wenn sie einen ihnen unbekannten Menschen, nennen wir ihn einfach Mister X, aus einer Gruppe von 150 Menschen herausfinden müssen: Sie gehen herum und rufen laut den Namen, in der Hoffnung, dass er sich meldet.

Wenn ARP die Ethernet-Adresse ermitteln möchte, die zu einer IP-Adresse gehört, verwendet es eine Ethernet-Eigenschaft, die als Broadcasting bekannt ist. Dabei wird ein Datagramm gleichzeitig an alle Stationen im Netzwerk geschickt. Das von ARP gesendete Broadcast-Datagramm enthält eine Anfrage zur IP-Adresse. Jeder empfangende Host überprüft daraufhin seine eigene Adresse. Stimmt diese mit der empfangenen Adresse überein, wird eine ARP-Antwort an den anfragenden Host zurückgeschickt. Der empfangende Host kann nun aus dieser Antwort die Ethernet-Adresse des Senders extrahieren. Ein nützliches Programm, das Ihnen hilft, ARP-Adressen in Ihrem Netzwerk zu ermitteln, ist arp. Wenn dieser Befehl ohne Optionen aufgerufen wird, dann liefert er folgende Ausgabe zurück:

vbrew root # arp
Address HWtype HWaddress Flags Mask Iface
172.16.0.155 ether 00:11:2F:53:4D:EF C eth0
172.16.0.65 ether 00:90:4B:C1:4A:E5 C eth0
vlager.vbrew.com ether 00:10:67:00:C3:7B C eth1
172.16.0.207 ether 00:0B:DB:53:E7:D4 C eth0

Es ist auch möglich, bestimmte ARP-Adressen von Hosts aus Ihrem Netzwerk anzufordern. Sollte das erforderlich sein, können die Netzwerkadministratoren ARP-Einträge modifizieren, hinzufügen oder aus dem lokalen Cache entfernen.

Lassen Sie uns aber zuvor noch etwas mehr über ARP reden. Hat ein Host erst einmal eine Ethernet-Adresse herausgefunden, speichert er diese im ARP-Cache. Auf diese Weise muss keine erneute Anfrage gestartet werden, wenn beim nächsten Mal ein Datagramm an den fraglichen Host geschickt werden soll. Nun wäre es aber nicht besonders klug, diese Informationen für immer zu speichern. Zum Beispiel könnte die Ethernet-Karte des anderen Hosts aufgrund technischer Probleme ausgetauscht werden müssen, und somit wäre der ARP-Eintrag ungültig. Darum werden die Einträge im ARP-Cache nach einiger Zeit gelöscht, um eine erneute Anfrage nach der IP-Adresse zu erzwingen.

Manchmal ist es auch notwendig, die IP-Adresse zu einer bestimmten Ethernet-Adresse zu ermitteln. Das passiert beispielsweise, wenn ein plattenloser Rechner von einem Server über das Netzwerk gebootet werden soll - eine sehr häufig auftretende Situation in lokalen Netzwerken. Ein solcher Client verfügt über nahezu keine Informationen über sich selbst - mit Ausnahme seiner Ethernet-Adresse! Also sendet er eine Broadcast-Nachricht mit der Bitte an alle Boot-Server, ihm seine IP-Adresse mitzuteilen. Dazu existiert ein weiteres Protokoll namens Reverse Address Resolution Protocol (RARP). Zusammen mit dem BOOTP-Protokoll dient es zum Booten von Clients ohne Festplatte über das Netzwerk.

IP-Routing

Wir greifen nun noch einmal die Frage auf, wie anhand der IP-Adresse der Host ermittelt wird, an den Pakete geschickt werden sollen. Verschiedene Teile der Adresse werden auf unterschiedliche Weise gehandhabt. Es ist Ihre Aufgabe, entsprechende Dateien einzurichten, die angeben, wie die unterschiedlichen Teile zu verarbeiten sind.

IP-Netzwerke

Wenn Sie jemandem einen Brief schreiben, versehen Sie den Briefumschlag üblicherweise mit der kompletten Adresse (Land, Postleitzahl, Straße usw.). Dann werfen Sie ihn in den Briefkasten und die Post liefert ihn ans Ziel, das heißt, er wird in das angegebene Land geschickt, wo die nationale Post ihn an die angegebene Adresse zustellt. Der Vorteil dieses hierarchischen Schemas ist offensichtlich: An welchem Ort auch immer Sie den Brief aufgeben, der lokale Postangestellte weiß ungefähr, in welche Richtung er den Brief weiterleiten soll, muss sich aber nicht darum kümmern, welchen Weg der Brief nimmt, wenn dieser erst einmal das Zielland erreicht hat.

IP-Netzwerke sind ähnlich strukturiert. Das gesamte Internet besteht aus einer Reihe von Netzwerken, die als autonome Systeme bezeichnet werden. Jedes System führt das Routing zwischen den teilnehmenden Hosts intern durch, das heißt, die Aufgabe der Auslieferung eines Datagramms wird auf die Suche nach einem Pfad zum Netzwerk des Zielhosts reduziert. Sobald ein Datagramm an einen beliebigen Host innerhalb eines Netzwerks übergeben ist, wird die weitere Verarbeitung ausschließlich von diesem Netz übernommen.

Subnetze

Diese Struktur spiegelt sich darin wider, dass IP-Adressen, wie oben erwähnt, in einen Host- und einen Netzwerkteil aufgeteilt werden. Per Voreinstellung wird das Zielnetzwerk aus dem Netzwerkteil der IP-Adresse gewonnen. Hosts mit identischen Netzwerknummern sollten deshalb innerhalb desselben Netzwerks zu finden sein.1

Es ist sinnvoll, innerhalb des Netzwerks dasselbe Schema zu verwenden, weil es selbst wieder aus Hunderten kleinerer Netzwerke bestehen kann, bei denen die kleinsten Einheiten physische Netzwerke wie Ethernets sind. Aus diesem Grund erlaubt IP die Unterteilung eines IP-Netzwerks in mehrere Subnetze.

Ein Subnetz übernimmt die Verantwortung für die Übertragung von Datagrammen innerhalb eines bestimmten Bereichs von IP-Adressen. Es handelt sich dabei um eine Erweiterung des Konzepts zur Aufspaltung von Bitfeldern wie bei den Klassen A, B und C. Allerdings wird der Netzwerkanteil etwas erweitert und enthält nun einige Bits aus dem Hostanteil. Die Anzahl der Bits, die als Subnetznummer interpretiert werden, wird durch die so genannte Subnetzmaske oder kurz Netzmaske bestimmt. Diese ist ebenfalls eine 32-Bit-Zahl, die die Bitmaske für den Netzwerkteil der IP-Adresse festlegt.

Das Netzwerk an der Groucho-Marx-Universität (GMU) ist ein Beispiel für ein solches Netzwerk. Es verwendet die Klasse-B-Netzwerknummer 149.76.0.0, und die Netzmaske lautet somit 255.255.0.0.

Intern besteht das Universitätsnetz aus verschiedenen kleineren Netzwerken, wie beispielsweise den LANs der verschiedenen Institute. Also werden die IP-Adressen noch einmal in 254 Subnetze von 149.76.1.0 bis 149.76.254.0 unterteilt. Dem Institut für theoretische Physik wurde beispielsweise die Nummer 149.76.12.0 zugeteilt. Das Universitäts-Backbone ist ein eigenständiges Netzwerk und hat die Nummer 149.76.1.0. Diese Subnetze verwenden dieselbe IP-Netzwerknummer, während gleichzeitig das dritte Oktett verwendet wird, um sie unterscheiden zu können. Sie verwenden also die Subnetzmaske 255.255.255.0.

Abbildung 2-1 zeigt, wie 149.76.12.4, die Adresse von quark, verschieden interpretiert wird, wenn ein normales Klasse-B-Netzwerk vorliegt bzw. wenn Subnetze verwendet werden.
Abbildung 2-1
Subnetz bei einem Klasse-B-Netzwerk

Es ist wichtig zu erwähnen, dass die Unterteilung in Subnetze (gern auch als Subnetting bezeichnet) nur eine interne Aufteilung des Netzwerks ist. Subnetze werden vom Besitzer (oder Administrator) des Netzwerks aufgebaut. Häufig werden Subnetze gebildet, um bestehende Grenzen widerzuspiegeln. Diese Grenzen können physischer (zwei Ethernet-Netzwerke), administrativer (zwei Institute) oder geografischer Natur sein. Die Verantwortung für ein Subnetz wird an eine Kontaktperson delegiert. Diese Struktur wirkt sich allerdings nur auf das interne Verhalten des Netzwerks aus und ist nach außen völlig unsichtbar.

Gateways

Das Anlegen von Subnetzen ist nicht nur organisatorisch von Vorteil, es ist häufig auch die natürliche Konsequenz aus bestehenden Hardwaregrenzen. Die Sichtweise eines Hosts in einem bestehenden Netzwerk, beispielsweise einem Ethernet, ist sehr eingeschränkt: Die einzigen Hosts, mit denen er sich unterhalten kann, sind die Hosts, die sich in dem gleichen Netz befinden wie er selbst. Alle anderen Hosts können nur über so genannte Gateways erreicht werden. Ein Gateway ist ein Host, der an zwei oder mehr physische Netzwerke gleichzeitig angeschlossen ist. Er ist so konfiguriert, dass er Pakete zwischen diesen Netzwerken übertragen kann.

Abbildung 2-2 zeigt einen Ausschnitt der Netzwerk-Topologie an der GMU. Hosts, die in beiden Subnetzen zur gleichen Zeit präsent sind, werden mit beiden Adressen aufgeführt.
Abbildung 2-2
Ausschnitt der Netzwerk-Topologie an der Groucho-Marx-Universität

Damit IP feststellen kann, ob ein Host in einem lokalen Netzwerk präsent ist, müssen verschiedene physische Netzwerke verschiedenen IP-Netzwerken angehören. Beispielsweise ist die Netzwerknummer 149.76.4.0 für die Hosts im lokalen Netzwerk des mathematischen Instituts reserviert. Wird ein Datagramm an quark geschickt, erkennt die Netzwerksoftware auf erdos sofort anhand der IP-Adresse 149.76.12.4, dass sich der Zielhost in einem anderen physischen Netzwerk befindet und daher nur durch ein Gateway erreicht werden kann (per Voreinstellung ist das sophus).

sophus selbst ist mit zwei verschiedenen Subnetzen verbunden: mit dem des mathematischen Instituts und dem des Universitäts-Backbones. Jedes wird über eine eigene Schnittstelle (eth0 bzw. fddi0) erreicht. Nun, welche IP-Adresse sollen wir ihm zuweisen? Sollen wir ihm eine im Subnetz 149.76.1.0 oder eine im Subnetz 149.76.4.0 geben?

Die Antwort lautet: in beiden. sophus wurde die Adresse 149.76.1.1 für das Netzwerk 149.76.1.0 und die Adresse 149.76.4.1 für das Netzwerk 149.76.4.0 zugewiesen. Einem Gateway wird also für jedes Netzwerk, dem es angehört, eine IP-Adresse zugewiesen. Diese Adressen - zusammen mit der entsprechenden Netzmaske - ergeben gemeinsam die Schnittstelle, über die auf das Subnetz zugegriffen wird. Die Abbildung von Schnittstellen auf Adressen für sophus wäre also so, wie in Tabelle 2-3 gezeigt.

Tabelle 2-3
 Beispielschnittstellen und -adressen
Schnittstelle
Adresse
Netzmaske
eth0
149.76.4.1
255.255.255.0
fddi0
149.76.1.1
255.255.255.0
lo
127.0.0.1
255.0.0.0

Der letzte Eintrag beschreibt die Loopback-Schnittstelle lo, die wir bereits vorgestellt haben.

Im Allgemeinen können Sie den feinen Unterschied zwischen der Zuweisung einer Adresse an einen Host oder an seine Schnittstelle ignorieren. Bei Hosts wie erdos, die nur zu einem Netzwerk gehören, spricht man eigentlich immer nur von dem Host mit dieser oder jener IP-Adresse, obwohl es genau genommen die Ethernet-Schnittstelle ist, der diese IP-Adresse zugewiesen wurde. Diese Unterscheidung ist jedoch nur bei Gateways wirklich von Bedeutung.

Die Routing-Tabelle

Wir richten nun unsere Aufmerksamkeit darauf, wie IP ein Gateway auswählt, wenn es ein Datagramm an ein entferntes Netzwerk ausliefert.

Wir haben bereits gesehen, dass erdos bei einem Datagramm für quark die Zieladresse überprüft und entdeckt, dass sich diese nicht im lokalen Netz befindet. Aus diesem Grund sendet erdos das Datagramm an das Standard-Gateway sophus, das sich nun vor die gleiche Aufgabe gestellt sieht. sophus erkennt, dass sich quark nicht in einem der Netzwerke befindet, mit denen es direkt verbunden ist. Es muss also ein weiteres Gateway finden, an das es das Datagramm weiterleiten kann. Die richtige Wahl wäre niels, das Gateway des physikalischen Instituts. Daher benötigt sophus einige Informationen, um zu wissen, welche Ziele über welche Gateways zu erreichen sind.

Die Routing-Informationen, die IP dabei verwendet, befinden sich in einer Tabelle, die Netzwerke mit Gateways verbindet, über die sie zu erreichen sind. Ein so genannter Catch-All-Eintrag (die Standard-Route) muss ebenfalls vorhanden sein. Dieses Gateway wird mit dem Netzwerk 0.0.0.0 assoziiert. Alle möglichen Zieladressen stimmen mit diesem Adressmuster überein, da keines der 32 Bit passen muss. Deshalb werden alle Pakete, die an ein unbekanntes Netzwerk gehen, über die Standard-Route verschickt. Auf sophus würde die Routing-Tabelle also aussehen wie in Tabelle 2-4.

Tabelle 2-4
 Beispiel für eine Routing-Tabelle
Netzwerk
Netzmaske
Gateway
Schnittstelle
149.76.1.0
255.255.255.0
-
eth1
149.76.2.0
255.255.255.0
149.76.1.2
eth1
149.76.3.0
255.255.255.0
149.76.1.3
eth1
149.76.4.0
255.255.255.0
-
eth0
149.76.5.0
255.255.255.0
149.76.1.5
eth1
0.0.0.0
0.0.0.0
149.76.1.2
eth1

Routen zu einem Netzwerk, mit dem sophus direkt verbunden ist, benötigen kein Gateway. In der Gateway-Spalte steht an dieser Stelle ein Bindestrich.

Es ist möglich, der Routing-Tabelle diese Informationen zu entnehmen. Dazu verwenden Sie den Befehl route und die Option -n. Als Ausgabe erhalten Sie anstelle der DNS-Namen die IP-Adressen.

Der Test, ob eine bestimmte Zieladresse zu einer gegebenen Route passt, ist eine mathematische Operation. Der Vorgang ist zwar relativ einfach, erfordert jedoch Grundkenntnisse in binärer Arithmetik und Logik. Zunächst wird aus der Netzwerkadresse und der Netzmaske eine logische UND-Verknüpfung gebildet. Auf dieselbe Weise wird dann eine logische UND-Verknüpfung der Zieladresse mit der Netzmaske vollzogen. Die Route passt genau dann zur Zieladresse, wenn beide Resultate identisch sind.

Mit anderen Worten: Die Route passt, wenn diejenigen Bits der Netzwerkadresse, die durch die Netzmaske angegeben werden (beginnend mit dem am weitesten links stehenden Bit, also dem höchstwertigen Bit im ersten Byte der Adresse), mit den gleichen Bits in der Zieladresse übereinstimmen.

Wenn die IP-Implementierung nach der besten Route zu einem Ziel sucht, kann es vorkommen, dass sie mehrere passende Routen findet. Wir wissen z.B., dass die Standard-Route zu jeder Zieladresse passt, während die Adressen von Datagrammen für Netzwerke, an die der Host direkt angeschlossen ist, auch auf lokale Routing-Einträge passen. Wie stellt IP nun fest, welche Route verwendet werden soll? Hier spielt die Netzmaske eine wichtige Rolle. Zwar passen beide Routen zur Zieladresse, aber die eine Route hat eine größere Netzmaske als die andere. Wir hatten bereits erwähnt, dass die Netzmaske dazu dient, unseren Adressraum in kleinere Netzwerke aufzuspalten. Je größer eine Netzmaske ist, desto genauer wird die Zieladresse durch sie bestimmt. Werden Datagramme geroutet, sollte immer die Route mit der größten Netzmaske gewählt werden. Die Netzmaske der Standard-Route besteht immer aus Null-Bits, während die lokalen Netzwerke in der oben präsentierten Konfiguration eine 24-Bit-Netzmaske haben. Ein Datagramm, das sowohl zu einem lokalen Netzwerk als auch zur Standard-Route passt, wird immer bevorzugt an das zuständige lokale Gerät weitergeleitet, da eine lokale Netzwerk-Route immer eine größere Netzmaske hat als die Standard-Route. Die Datagramme, die über die Standard-Route weitergeleitet werden, sind immer diejenigen, die nicht zu den anderen Routen passen.

Routing-Tabellen können auf unterschiedliche Weise aufgebaut werden. Bei kleineren LANs ist es wahrscheinlich am effektivsten, die Tabelle von Hand zu erstellen und sie dann während der Boot-Phase mit Hilfe des Befehls route an IP zu übergeben (siehe Kapitel 4). Bei größeren Netzwerken werden sie zur Laufzeit von so genannten Routing-Dämonen erzeugt und eingerichtet. Diese Dämonen laufen auf zentralen Hosts des Netzwerks und tauschen untereinander Routing-Informationen aus, um die »optimalen« Routen zwischen den teilnehmenden Netzwerken zu errechnen.

Abhängig von der Größe des Netzwerks werden verschiedene Routing-Protokolle verwendet. Für das Routing innerhalb autonomer Systeme (wie der Groucho-Marx-Universität) werden die internen Routing-Protokolle benutzt. Das bekannteste dieser Protokolle ist RIP oder Routing Information Protocol, das im BSD-routed-Dämon implementiert ist. Das Routing zwischen autonomen Systemen muss über externe Routing-Protokolle wie EGP (External Gateway Protocol) oder BGP (Border Gateway Protocol) erfolgen. Diese Protokolle wurden ebenso wie RIP im gated-Dämon der University of Cornell implementiert.

Metrik

Beim dynamischen Routing wird der beste Weg zu einem Zielhost oder -Netzwerk anhand der Anzahl der Hops ermittelt. Hops bezeichnen die Anzahl der Gateways, die ein Datagramm passieren muss, bevor es sein Ziel erreicht hat. Je kürzer die Route ist, umso besser wird sie von RIP bewertet. Sehr lange Routen von 16 oder mehr Hops werden als unbrauchbar betrachtet und verworfen.

Soll RIP verwendet werden, um die für Ihr lokales Netzwerk anfallenden Routing-Informationen zu verwalten, muss auf allen Hosts gated laufen. Während des Bootens prüft gated alle aktiven Netzwerkschnittstellen. Existiert mehr als eine aktive Schnittstelle (die Loopback-Schnittstelle wird nicht mitgezählt), nimmt es an, dass der Host als Gateway fungiert, und verteilt aktiv Routing-Informationen. Ansonsten verhält es sich passiv und empfängt nur eingehende RIP-Updates, um die lokale Routing-Tabelle zu aktualisieren.

Wenn gated die Daten aus der lokalen Routing-Tabelle verteilt, berechnet es die Länge der Route anhand einer so genannten Metrik, die Teil des Eintrags in der Routing-Tabelle ist. Dieser Wert wird vom Systemadministrator während der Konfiguration der Route eingetragen und sollte die Kosten bezüglich der Verwendung dieser Route widerspiegeln.2 Die Metrik der Route zu einem Subnetz, an das der Host direkt angeschlossen ist, muss daher immer null sein, während eine Route, die durch zwei Gateways verläuft, eine Metrik von zwei hat. Sie müssen sich nicht um die Metrik kümmern, wenn Sie RIP oder gated nicht verwenden.

Das Internet Control Message Protocol

IP hat noch ein verwandtes Protokoll, über das wir bisher nicht gesprochen haben. Dieses Internet Control Message Protocol (ICMP) wird vom Netzwerkcode des Kernels verwendet, um Fehlermeldungen und Ähnliches an andere Hosts weiterzugeben. Nehmen wir beispielsweise an, dass Sie einmal wieder vor erdos sitzen und über telnet auf Port 12345 auf quark zugreifen wollen. Leider existiert dort kein Prozess, der an diesem Port horcht. Wenn das erste TCP-Paket für diesen Port bei quark ankommt, erkennt die Netzwerkschicht das sofort und sendet umgehend eine ICMP-Nachricht an erdos zurück, um ihm mitzuteilen, dass der Port nicht erreichbar ist (»Port Unreachable«).

ICMP stellt verschiedene Nachrichten zur Verfügung, von denen viele Fehlerbedingungen behandeln. Darunter befindet sich auch eine sehr interessante Nachricht namens »Redirect«. Diese wird vom Routing-Modul erzeugt, wenn es erkennt, dass es von einem anderen Host als Gateway verwendet wird, obwohl es einen wesentlich kürzeren Weg gibt. Beispielsweise könnte die Routing-Tabelle von sophus nach dem Booten unvollständig sein. Die Tabelle könnte die Routen zum Mathe-Netzwerk, zum FDDI-Backbone und die Standard-Route enthalten, die auf das Gateway gcc1 des Universitäts-Rechenzentrums weist. Alle Pakete, die für quark bestimmt sind, würden also an gcc1 geschickt werden und nicht an niels, das Gateway des physikalischen Instituts. Wenn es ein solches Datagramm empfängt, erkennt gcc1, dass dies eine ungünstige Route ist, und leitet das Paket an niels weiter, während gleichzeitig eine ICMP-Redirect-Nachricht an sophus gesandt wird, die dem Rechner die bessere Route mitteilt.

Nun sieht das vielleicht nach einer sehr schlauen Methode aus, mit der Sie es vermeiden können, alle außer die grundlegenden Routen von Hand einzutragen. Seien Sie aber gewarnt, dass es nicht immer eine gute Idee ist, sich auf dynamische Routing-Schemata zu verlassen - egal ob RIP oder ICMP-Redirects. ICMP-Redirect und RIP bieten Ihnen gar keine oder nur unzureichende Möglichkeiten, die Authentizität der empfangenen Routing-Informationen zu überprüfen. Auf diese Weise könnten bösartige Taugenichtse Ihr gesamtes Netzwerk lahm legen oder noch Schlimmeres tun. Aus diesem Grund behandelt der Netzwerkcode des Linux-Kernels Redirect-Messages für Netzwerkrouten so, als wären es nur Redirects für Hostrouten. Das verringert die Zerstörungsgefahr bei einem Angriff, indem es ihn auf einen einzigen Host beschränkt und dadurch der Rest des Netzwerks verschont bleibt. Andererseits bedeutet dies aber, dass durch die Sicherheitsüberprüfung, die jeden Host zur Erzeugung eines ICMP-Redirects veranlasst, der Netzwerkverkehr umfangreicher wird. In Anbetracht der heutigen Datenflut ist es daher nicht ratsam, für jeden denkbaren Anwendungsfall ICMP-Redirects einzusetzen.

Auflösung von Hostnamen

Wie bereits beschrieben, dreht sich bei der Adressierung von TCP/IP-Netzwerken - zumindest bei Version 4 - alles um 32-Bit-Zahlen. Es wird Ihnen aber wahrscheinlich schwer fallen, sich mehr als ein paar dieser Nummern zu merken. Aus diesem Grund sind Hosts im Allgemeinen unter einem »normalen« Namen wie gauss oder strange bekannt. Es gehört zu den Aufgaben der Anwendung, die zu diesem Namen gehörende IP-Adresse zu ermitteln. Dieser Vorgang wird als Auflösung des Hostnamens bezeichnet. Muss ein Programm die IP-Adresse eines bestimmten Hosts ermitteln, ist es auf die Bibliotheksfunktionen gethostbyname(3) und gethostbyaddr(3) angewiesen. Diese und eine Reihe verwandter Funktionen werden traditionell in einer separaten Bibliothek (der so genannten resolverlibrary) gespeichert; unter Linux sind sie allerdings Teil der Standard-libc. Im allgemeinen Sprachgebrauch wird diese Sammlung von Funktionen »der Resolver« genannt. Ihre Konfiguration wird in Kapitel 5 näher beschrieben.

Nun ist es bei einem kleinen Netzwerk wie einem Ethernet, ja selbst bei einem Cluster solcher Netze, nicht besonders schwer, die Tabellen zu verwalten, mit denen die Hostnamen auf Adressen abgebildet werden. Diese Informationen werden normalerweise in einer Datei namens /etc/hosts gespeichert. Wenn Sie einen Host hinzufügen oder entfernen, müssen Sie nur die hosts-Dateien auf allen Hosts entsprechend korrigieren. Das wird natürlich sehr mühsam in Netzwerken, die sich aus mehr als einer Hand voll Rechner zusammensetzen.

Auch im Internet wurden zu Beginn alle Adress-Informationen in einer einzigen Datenbank namens HOSTS.TXT gespeichert. Diese Datei wurde vom Network Information Center (NIC) verwaltet und musste von allen teilnehmenden Sites heruntergeladen und installiert werden. Als das Netz wuchs, machten sich die Nachteile dieses Schemas bemerkbar. Neben dem administrativen Aufwand, der mit der regelmäßigen Installation von HOSTS.TXT verbunden war, wurde die Last auf den diese Datei verteilenden Servern zu hoch. Noch schwerwiegender war das Problem, dass alle Namen beim NIC registriert werden mussten, um sicherzustellen, dass Namen nicht doppelt verwendet wurden.

Aus diesen Gründen wurde im Jahre 1984 ein neues Schema für die Auflösung von Adressnamen eingeführt: das Domain Name System. Das DNS wurde von Paul Mockapetris entwickelt und geht beide Probleme zur gleichen Zeit an. Wir werden auf das Domain Name System in Kapitel 5 näher eingehen.

Fussnoten

1Autonome Systeme sind noch etwas allgemeiner. Sie können mehr als ein IP-Netzwerk umfassen.
2Im einfachsten Fall ergeben sich die Kosten beispielsweise aus der Anzahl der Hops, die bis zum Ziel übersprungen werden müssen. Eine gründliche Kostenanalyse in komplexen Netzwerkarchitekturen ist dagegen schon eine Wissenschaft für sich.

TOC PREV NEXT INDEX


O'Reilly Home | O'Reilly-Partnerbuchhandlungen | Bestellinformationen
Kontakt | Über O'Reilly | Datenschutz

© 2005, O'Reilly Verlag GmbH & Co. KG