Abbildung 7-1.
Eine IP-Adresse
Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen.
Wünschen Sie mehr Informationen zu der gedruckten Version des Buches "Linux - Wegweiser zur Installation & Konfiguration", dann klicken Sie hier.
Linux unterstützt eine vollständige Implementierung der Netzwerkprotokolle TCP/IP (Transmission Control Protocol/Internet Protocol). TCP/IP hat sich weltweit zur erfolgreichsten Methode der Vernetzung entwickelt. Mit Linux und einer Ethernet-Karte können Sie Ihren Rechner in ein LAN (Local Area Network) einbinden oder, wenn die notwendigen Netzverbindungen vorhanden sind, in das Internet -- das weltumspannende TCP/IP-Netzwerk.
Es ist nicht schwierig, ein kleines lokales Netz von UNIX-Rechnern zusammenzustecken. Sie brauchen lediglich einen Ethernet-Controller in jedem Rechner und die passenden Ethernet-Kabel und andere Hardware. Falls Ihre Firma oder Universität einen Anschluß an das Internet hat, können Sie Ihren Linux-Rechner problemlos in dieses Netzwerk mit einbinden.
Das TCP/IP von Linux hat Höhen und Tiefen erlebt. Schließlich ist die Implementierung eines ganzen Protokollstacks von Grund auf keine Sache, die man aus Spaß an der Freude mal eben am Wochenende erledigt. Andererseits hat der Code für das Linux-TCP/IP ganz enorm von den Horden von Testern und Entwicklern profitiert, die sich mit ihm befaßt haben; im Laufe der Zeit sind viele Fehler und Konfigurationsprobleme beseitigt worden.
Die aktuelle Implementierung von TCP/IP und verwandten Protokollen für Linux läuft unter dem Namen »NET-2«. Das hat mit der sogenannten NET-2-Version des BSD-UNIX nichts zu tun; in diesem Zusammenhang bezeichnet »NET-2« einfach die zweite Implementierung von TCP/IP für Linux. Vor NET-2 gab es (wenig überraschend) NET-1, das ungefähr mit der Kernel-Version 0.99.pl10 ausrangiert wurde. NET-2 unterstützt fast alle Fähigkeiten, die Sie von einer TCP/IP-Implementierung für UNIX erwarten dürfen, ebenso eine Reihe verschiedener Hardware für die Vernetzung.
Das NET-2 von Linux unterstützt auch SLIP -- das Serial Line Internet Protocol. Mit SLIP und einem Modem können Sie sich per Wählzugang in das Internet begeben. Falls Ihre Firma oder Universität den Zugang per SLIP anbietet, können Sie sich über die Telefonleitung in den SLIP-Server einwählen und Ihren Rechner zu einem Bestandteil des Internet machen. Falls Ihr Rechner dagegen schon einen Ethernet-Zugang zum Internet hat, können Sie ihn als SLIP-Server konfigurieren.
Neben dem Linux Network Administrator's Guide enthält das NET-2-HOWTO von Linux eine mehr oder weniger vollständige Beschreibung der Konfiguration von TCP/IP und SLIP unter Linux. Das Ethernet-HOWTO von Linux ist ein ähnliches Dokument, das die Konfiguration einiger Treiber für Ethernet-Karten unter Linux beschreibt.
Interessant ist außerdem das Buch TCP/IP Netzwerk Administration von Craig Hunt. Es enthält alles über die Benutzung und Konfiguration von TCP/IP auf UNIX-Rechnern. Falls Sie vorhaben, ein Netzwerk mit Linux-Rechnern aufzubauen oder sich ernsthaft mit TCP/IP befassen wollen, sollten Sie über das Wissen verfügen, das dieses Buch zum Thema Netzwerkverwaltung darbietet.
Damit Sie die Vielseitigkeit von TCP/IP in vollem Umfang schätzen (und nutzen) können, sollten Sie mit den zugrundeliegenden Konzepten vertraut sein. Transmission Control Protocol/Internet Protocol besteht aus einer Reihe von Protokollen (unser rätselhaftes Schlagwort für dieses Kapitel), die definieren, wie Rechner einerseits über ein Netzwerk miteinander, andererseits intern mit den anderen Schichten der Protokollfamilie kommunizieren sollen.
Die beste Informationsquelle zum theoretischen Hintergrund der Internet-Protokolle ist der erste Band von Douglas Comers Internetworking with TCP/IP .
TCP/IP wurde ursprünglich für das Advanced Research Projects Agency-Netz (ARPAnet) entwickelt, das für militärische und computerwissenschaftliche Forschungszwecke eingerichtet wurde. Aus diesem Grund wird TCP/IP manchmal als »DARPA-Internet-Protokoll« bezeichnet. Seit jenen Tagen sind viele andere TCP/IP-Netze entstanden (etwa das NSFNET der National Science Foundation) ebenso wie Tausende von weiteren lokalen und regionalen Netzen auf der ganzen Welt. Alle diese Netze sind zu einem einzigen Konglomerat verbunden, das man als das Internet bezeichnet.
In einem TCP/IP-Netzwerk bekommt jeder Rechner eine IP-Adresse zugewiesen, die aus einer eindeutigen, 32 Bits langen Zahl besteht. Sie müssen gewisse Kenntnisse der IP-Adressen haben, um Ihr Netzwerk planen und die Rechneradressen vergeben zu können. Die IP-Adresse wird in der Regel als »dotted quad« geschrieben: vier Dezimalzahlen, die durch Punkte getrennt werden. Ein Beispiel: Die (hexadezimale) IP-Adresse 0x80114b14 kann auch als 128.17.75.20 geschrieben werden.
Die IP-Adresse besteht aus zwei Teilen: der Netzwerkadresse und der Rechneradresse. Die Netzwerkadresse besteht aus den höherwertigen Bits der Adresse, die Rechneradresse aus den übrigen Bits. (Im allgemeinen ist jeder Rechner (host) ein eigenständiges System im Netzwerk.) Die Größe dieser beiden Felder hängt vom Typ des betreffenden Netzwerks ab. Ein Beispiel: In einem Klasse-B-Netz (bei dem das erste Byte der IP-Adresse einen Wert zwischen 128 und 191 enthält) indentifizieren die ersten beiden Bytes das Netzwerk und die letzten beiden Bytes den Rechner; siehe auch Abbildung 7--1. In unserer Beispieladresse ist 128.17 die Adresse des Netzwerks, und die Rechneradresse ist 75.20. Andersherum gesagt: Das System mit der IP-Adresse 128.17.75.20 ist der Rechner 75.20 im Netzwerk 128.17.
Abbildung 7-1.
Eine IP-Adresse
Der Rechner-Teil der IP-Adresse kann außerdem weiter unterteilt werden, um Adressen für Subnetze (subnets) zu bilden. Das Einrichten von Subnetzen bedeutet, daß ein großes Netz in kleine Teilnetze aufgeteilt wird, die unabhängig voneinander verwaltet werden können. So könnte eine Organisation beispielsweise ein einzelnes Klasse-B-Netz einrichten, das zwei Bytes für die Rechneradresse freihält -- bis zu 65.534 Rechner in einem Netz. (1)
Innerhalb der Organisation möchte man dann vielleicht die Verantwortung für Teile des Netzes delegieren, so daß jedes Teilnetz von einer anderen Abteilung verwaltet wird. Bei der Einrichtung von Subnetzen kann die Organisation z.B. bestimmen, daß das erste Byte der Rechneradresse (also das dritte Byte der gesamten Adresse) die Subnetzadresse darstellt und das zweite Byte der Rechneradresse das System innerhalb dieses Subnetzes identifiziert; siehe auch Abbildung 7--2. In diesem Fall bezeichnet die IP-Adresse 128.17.75.20 den Rechner 20 im Subnetz 75 des Netzes 128.17.
Abbildung 7-2.
Eine IP-Adresse mit Subnetz
Prozesse (entweder auf demselben oder auf verschiedenen Rechnern), die per TCP/IP kommunizieren möchten, benutzen dazu in der Regel sowohl die IP-Adresse des Zielrechners als auch eine Portadresse . Die IP-Adresse des Zielrechners wird natürlich gebraucht, um Daten von einem Rechner aus ans Ziel zu leiten. Die Portadresse besteht aus einer 16 Bits langen Zahl, die einen bestimmten Dienst oder eine Anwendung auf dem Zielrechner bezeichnet, die die Daten empfangen soll. Man kann die Portnummern mit den Zimmernummern in einem großen Bürogebäude vergleichen -- das Gebäude als Ganzes hat eine einzige IP-Adresse, aber verschiedene Firmen haben ihre eigenen Adressen innerhalb des Gebäudes.
Hier ein Beispiel für die Benutzung von IP-Adressen und Portnummern aus dem richtigen Leben: Das Programm telnet ermöglicht es dem Benutzer eines Rechners, auf einem anderen Rechner eine Login-Sitzung zu starten. Auf dem fremden Rechner läuft der telnet -»Dämon« telnetd , der an einem bestimmten Port auf eingehende Verbindungen wartet (in diesem Fall ist das die Portnummer 23). (2)
Der Benutzer, der telnet aufruft, gibt die Adresse des Zielrechners an, und das Programm telnet versucht, eine Verbindung zum Port 23 des fremden Rechners herzustellen. Wenn das gelingt, können telnet und telnetd miteinander kommunizieren, um dem Benutzer das Einloggen auf dem Zielrechner zu ermöglichen.
Beachten Sie, daß der telnet -Client auf dem lokalen Rechner eine eigene Portadresse benutzt. Diese Adresse wird mit dem Aufruf von telnet dynamisch an den Client vergeben. Der Grund hierfür ist, daß das fremde telnetd die Portnummer eines ankommenden telnet -Clients nicht vorab wissen muß. Wenn der Client die Verbindung aufbaut, wird u.a. auch die eigene Portnummer an telnetd übertragen. Man kann sich telnetd als eine Firma mit allgemein bekannter Postanschrift vorstellen. Jeder Kunde, der mit dem telnetd eines bestimmten Rechners korrespondieren möchte, muß die IP-Adresse des Zielsystems kennen (quasi die Adresse des telnetd -Gebäudes); er muß außerdem wissen, an welchem Port telnetd zu erreichen ist (das richtige Büro innerhalb des Gebäudes). Die Adresse und Portnummer des telnet -Clients dagegen stehen als »Absender« auf dem Briefumschlag.
Die TCP/IP-Familie besteht aus einer Reihe von Protokollen. Das Transmission Control Protocol (TCP) erledigt die zuverlässige, verbindungsorientierte Kommunikation zwischen zwei Prozessen, die auf verschiedenen Rechnern im Netz laufen können. Das User Datagram Protocol (UDP) weist Ähnlichkeiten mit TCP auf, bietet aber einen verbindungslosen, unzuverlässigen Dienst. Prozesse, die UDP benutzen, müssen bei Bedarf ihre eigenen Routinen für Empfangsbestätigung und Synchronisierung bereitstellen.
TCP und UDP senden und empfangen Daten in sogenannten Paketen . Jedes Paket enthält einen Informationsbrocken, der an ein anderes System gehen soll und einen Header (etwa: Kopfzeile), in dem Zieladresse und Portnummer enthalten sind.
Das Internet Protocol (IP) ist in der Protokollhierarchie unterhalb von TCP und UDP angesiedelt; es ist für die Übertragung und das Routing (etwa: Ansteuern des Ziels) von TCP- und UDP-Paketen durch das Netz verantwortlich. Zu diesem Zweck verpackt IP jedes TCP- oder UDP-Paket in ein weiteres Paket (namens IP- Datagramm ), das einen Header mit Routing- und Zielinformationen enthält. Im Header des IP-Datagramms stehen die IP-Adressen des sendenden sowie des empfangenden Rechners.
Beachten Sie, daß IP nichts über die Portadressen weiß; dafür sind TCP und UDP zuständig. Ebenso haben TCP und UDP nichts mit den IP-Adressen zu tun, mit denen sich (wie der Name andeutet) nur IP befaßt. Wie Sie sehen, ist die weiter oben gebrauchte Metapher mit Umschlag und Absender ziemlich treffend; man kann sich jedes Paket als einen Brief in einem Umschlag vorstellen. TCP und UDP verpacken den Brief in einem Umschlag, auf dem die Portnummern von Absender und Empfänger (Büronummern) stehen.
IP fungiert als Poststelle des Bürogebäudes, das den Brief abschickt. Es empfängt den Umschlag und verpackt ihn in einem weiteren Umschlag, auf dem die IP-Adressen (die Adressen der Bürogebäude) von Absender und Empfänger stehen. Die Post AG (die wir noch gar nicht besprochen haben) liefert den Brief im entsprechenden Bürogebäude ab. Dort wird in der Poststelle der äußere Umschlag entfernt und der Brief wird an TCP/UDP übergeben. TCP/UDP liefern den Brief dann im richtigen Büro ab, und benutzen dazu die Portnummer (die auf dem inneren Umschlag steht). Auf jedem Umschlag steht eine Rücksendeadresse (return address), mit deren Hilfe IP und TCP/UDP auf einen Brief antworten können.
Die Rechner im Netz bekommen neben ihrer IP-Adresse oft auch einen Namen zugeteilt, um die Verwaltung der Systeme im Internet etwas humaner zu gestalten. Der Domain Name Service (DNS) besorgt die Umsetzung der Rechnernamen in IP-Adressen und umgekehrt; er ist außerdem dafür zuständig, die für die Umsetzung benutzte Datenbank im ganzen Internet zu verteilen. Die Benutzung von Rechnernamen macht es auch möglich, daß sich die IP-Adresse eines Rechners ändert (beispielsweise wenn der Rechner in ein anderes Netzwerk eingebunden wird), ohne daß man befürchten muß, daß andere Benutzer dieses System nach der Adressenänderung nicht mehr »finden«. Man muß nur den DNS-Eintrag für diesen Rechner mit der neuen IP-Adresse versehen, und alle »namentlichen« Zugriffe auf dieses System werden weiterhin erfolgreich sein.
DNS ist eine riesige, über die ganze Welt verteilte Datenbank. Alle Organisationen pflegen jeweils den Teil dieser Datenbank, in dem die Rechner der Organisation aufgelistet sind. Falls Sie in Ihrer Organisation für die Pflege dieser Liste zuständig sind, finden Sie im Linux Wegweiser für Netzwerker oder in TCP/IP Netzwerk Administration Hilfestellung dazu. Sollte das noch nicht ausreichen, können Sie mit dem Titel DNS and BIND wirklich aus dem vollen schöpfen.
In den meisten Fällen reicht es aus, wenn Sie wissen, daß ein Dämon namens named (etwa: näim-die gesprochen) auf Ihrem System laufen muß. Dieser Dämon ist Ihr Fenster zum DNS.
Wir könnten uns jetzt der Frage zuwenden, wie ein Paket von einem System (Bürogebäude) zu einem anderen gelangt. Dies ist die eigentliche Aufgabe von IP und einigen anderen Protokollen, die IP dabei unterstützen. Neben der Handhabung von IP-Datagrammen (in der Funktion einer Poststelle) erledigt IP auch das Routing von Paketen zwischen den Rechnern.
Bevor wir uns damit befassen, wie das Routing funktioniert, müssen wir das Modell erklären, auf dem TCP/IP-Netzwerke beruhen. Ein Netzwerk ist einfach eine Gruppe von Rechnern, die durch ein physikalisches Medium -- etwa Ethernet oder serielle Leitungen -- miteinander verbunden sind. In der Terminologie von TCP/IP sagt man, daß jedes Netzwerk intern seine eigenen Methoden für das Routing und den Transport von Paketen hat.
Die Netze sind untereinander durch Gateways verbunden. Ein Gateway ist ein Rechner, der direkt mit zwei oder mehr Netzwerken verbunden ist; er ist deshalb in der Lage, Informationen zwischen den Netzen auszutauschen und Pakete aus einem Netz in ein anderes zu transportieren. Ein Gateway könnte beispielsweise aus einer Workstation mit mehr als einer Ethernet-Karte bestehen. Jede Karte gehört dabei zu einem anderen Netzwerk, und das Betriebssystem nutzt diese gemeinsamen Verbindungen so, daß der Rechner als Gateway fungieren kann.
Wir wollen das Thema an einem konkreten Beispiel diskutieren und führen deshalb ein imaginäres Netzwerk ein, das aus den Rechnern eggplant, papaya, apricot und zucchini besteht. Abbildung 7--3. zeigt die Anordnung dieser Systeme im Netzwerk. Beachten Sie, daß papaya in ein zweites Netzwerk eingebunden ist, zu dem außerdem die Systeme pineapple und pear gehören. Diese Rechner haben folgende IP-Adressen:
Rechnername IP-Adresse --------------------------------------- eggplant 128.17.75.20 apricot 128.17.75.12 zucchini 128.17.75.37 papaya 128.17.75.98, 128.17.112.3 pear 128.17.112.21 pineapple 128.17.112.40, 128.17.30.1 ---------------------------------------
Abbildung 7-3.
Ein Netzwerk mit zwei Gateways
Wie Sie sehen, hat papaya zwei IP-Adressen -- je eine in den Subnetzen 128.17.75 und 128.17.112. Auch pineapple hat zwei IP-Adressen -- eine in 128.17.112 und eine in 128.7.30.
IP benutzt den Netzwerk-Teil der IP-Adresse für das Routing der Pakete zwischen den Rechnern. Damit das funktioniert, führt jedes System im Netz eine Routingtabelle (routing table), die eine Liste mit Netzwerken und den Gateways zu diesen Netzwerken enthält. Um ein Paket zu einem bestimmten Rechner zu routen, liest IP den Netzwerk-Teil der Zieladresse. Wenn die Routingtabelle einen Eintrag für dieses Netz enthält, schickt IP das Paket an den entsprechenden Gateway. Im anderen Fall wird das Paket an den »Standard«-Gateway (default gateway) geschickt, der ebenfalls in der Routingtabelle eingetragen ist.
Die Routingtabellen können sowohl Einträge für bestimmte Rechner als auch für Netzwerke enthalten. Zusätzlich hat jeder Rechner in der Routingtabelle einen Eintrag für sich selbst.
Wir wollen uns die Routingtabelle von eggplant anschauen. Mit dem Befehl netstat -rn erhalten wir:
eggplant:$ netstat -rn Kernel routing table Destination net/address Gateway address Flags RefCnt Use Iface 128.17.75.0 128.17.75.20 UN 0 20417 eth0 default 128.17.75.98 UGN 0 20417 eth0 127.0.0.1 127.0.0.1 UH 0 268 lo 128.17.75.20 127.0.0.1 UH 0 268 lo
Die erste Spalte enthält die Zielnetze (und -rechner) dieser Routingtabelle. Der erste Eintrag gilt dem Netzwerk 128.17.75 (bei Netzwerken ist die Rechneradresse gleich null); das ist das Netz, in dem auch eggplant lebt. Alle Pakete, die an dieses Netzwerk geschickt werden sollen, nehmen ihren Weg durch 128.17.75.20, was die IP-Adresse von eggplant ist. Allgemein gesprochen, führt die Route eines Rechners zu seinem Netzwerk immer durch ihn selbst.
Die Spalte Flags der Routingtabelle enthält Informationen über die Zieladresse dieses Eintrags; U steht für »aktiv« (up), N bedeutet, daß das Ziel ein Netzwerk ist usw. Die Spalten RefCnt und Use enthalten statistische Werte zur Benutzung dieser Route, und Iface zeigt, welche Schnittstelle für diese Route benutzt wird. Auf Linux-Systemen heißen die Ethernet-Schnittstellen eth0 , eth1 usw. lo bezeichnet das Loopback-Device, das wir etwas weiter unten besprechen werden.
Der zweite Eintrag in dieser Routingtabelle beschreibt die Standardroute (default route), die für alle Pakete benutzt wird, deren Zielnetz oder -rechner nicht in der Tabelle enthalten ist. In diesem Beispiel führt die Standardroute durch den Rechner papaya, den man deshalb als das Tor zum Rest der Welt betrachten kann. Jedes System im Subnetz 128.17.75 muß papaya benutzen, wenn es mit anderen Rechnern im Netz kommunizieren möchte.
Der dritte Eintrag in der Tabelle gilt der Adresse 127.0.0.1 -- das ist die Loopback -Adresse. Diese Adresse wird benutzt, wenn der Rechner eine TCP/IP-Verbindung mit sich selbst herstellen möchte. Er benutzt dafür das Loopback -Device lo und verhindert damit, daß Loopback -Verbindungen (durch die Schnittstelle eth0 ) das Ethernet benutzen. Auf diese Weise wird keine Netzwerkbandbreite in Anspruch genommen, wenn ein Rechner ein »Selbstgespräch« führen möchte.
Der letzte Eintrag in der Routingtabelle gilt der IP-Adresse 128.17.75.20; das ist die Adresse von eggplant selbst. Wie Sie sehen, benutzt diese Route 127.0.0.1 als Gateway. Auf diese Weise ist sichergestellt, daß eggplant bei jeder TCP/IP-Verbindung mit sich selbst die Loopback-Adresse als Gateway und lo als Schnittstelle benutzt.
Nehmen wir an, daß eggplant ein Paket an zucchini schicken möchte. Im IP-Datagramm wird als Absenderadresse 128.17.75.20 stehen, und als Zieladresse 128.17.75.37. IP stellt fest, daß der Netzwerk-Teil der Zieladresse 28.17.75 ist, und benutzt deshalb den Eintrag für 128.17.75.0 in der Routingtabelle. Das Paket wird direkt an das Netzwerk geschickt, wo zucchini es empfangen und verarbeiten kann.
Was passiert, wenn eggplant Pakete an einen Rechner außerhalb des lokalen Netzwerks schicken möchte, etwa pear? In diesem Fall ist die Zieladresse 128.17.112.21. IP versucht, in der Routingtabelle eine Route zum Netzwerk 128.17.112 zu finden; weil keine solche Route eingetragen ist, wählt es die Standardroute durch papaya hindurch. papaya empfängt das Paket und sucht in seiner eigenen Routingtabelle nach der Zieladresse. Die Routingtabelle von papaya könnte folgendermaßen aussehen:
Destination net/address Gateway address Flags RefCnt Use Iface 128.17.75.0 128.17.75.98 UN 0 20417 eth0 128.17.112.0 128.17.112.3 UN 0 20417 eth1 default 128.17.112.40 UGN 0 20417 eth1 127.0.0.1 127.0.0.1 UH 0 268 lo 128.17.75.98 127.0.0.1 UH 0 268 lo
Wie Sie sehen, ist papaya durch seine Schnittstelle eth0 mit dem Netzwerk 128.17.75 verbunden, und durch eth1 mit dem Netz 128.17.112. Die Standardroute führt durch pineapple, was für papaya auch der Gateway in die unendlichen Tiefen des Weltalls ist.
Sobald papaya ein Paket empfängt, das an pear adressiert ist, stellt es fest, daß die Zieladresse in 128.17.112 liegt und lenkt das Paket in das Netzwerk, das den zweiten Eintrag in der oben gezeigten Routingtabelle benutzt.
In ähnlicher Weise würde eggplant Pakete durch papaya (seinen Gateway) routen, die für Systeme außerhalb der eigenen Organisation bestimmt sind. papaya wiederum würde nach außen adressierte Pakete durch pineapple routen -- und so weiter. Pakete werden solange von einem Gateway zum nächsten weitergereicht, bis Sie das Zielnetz erreichen. Genau dies ist die Struktur, auf der das Internet aufbaut: Eine scheinbar endlose Kette von Netzen, die durch Gateways miteinander verbunden sind.
Sie können das Linux-TCP/IP ohne jegliche Netzhardware benutzen -- im »Loopback«-Modus können Sie mit sich selbst kommunizieren. Für einige Anwendungen und Spiele, die das »Loopback«-Device benutzen, müssen Sie diesen Modus konfigurieren.
Wenn Sie Linux allerdings in einem Ethernet-TCP/IP-Netzwerk benutzen möchten, brauchen Sie eine der folgenden Ethernet-Karten:
Folgende Nachbauten (Clones) sollen auch funktionieren:
Im Ethernet-HOWTO von Linux finden Sie eine ausführlichere Darstellung der brauchbaren Hardware.
Linux unterstützt auch SLIP, mit dem Sie sich per Modem und Telefonleitung in das Internet begeben können. Sie brauchen in diesem Fall ein Modem, das zu Ihrem SLIP-Server kompatibel ist -- viele Server verlangen z.B. ein V.32bis-Modem mit 14.400 bps.
In diesem Abschnitt besprechen wir, wie auf einem Linux-System eine TCP/IP-Verbindung im Ethernet konfiguriert wird. Wahrscheinlich ist ein solches System in ein lokales Netz mit Rechnern eingebunden, auf denen bereits TCP/IP läuft -- in diesem Fall sind Ihr Gateway, Nameserver usw. bereits konfiguriert und lauffähig.
Der folgende Abschnitt bezieht sich in erster Linie auf Ethernet-Verbindungen. Falls Sie vorhaben, SLIP zu benutzen, sollten Sie diesen Abschnitt lesen, um sich mit den Grundlagen vertraut zu machen, und dann mit den SLIP-spezifischen Anweisungen im Abschnitt » Die SLIP-Konfiguration « fortfahren.
Vielleicht haben Sie aber auch vor, ein ganzes LAN mit Linux-Systemen (oder einer Mischung aus Linux- und anderen Systemen) einzurichten. In diesem Fall müssen Sie sich um eine Reihe weiterer Punkte kümmern, die wir hier nicht besprechen. Dazu gehören die Einrichtung eines eigenen Nameservers sowie eines Gateways, wenn Ihr Netzwerk mit anderen Netzen verbunden werden soll. Falls Ihr Netzwerk an das Internet angeschlossen werden soll, werden Sie außerdem von Ihrem Internet-Provider die IP-Adresseen und dazugehörige Informationen besorgen müssen.
Kurz und gut: Was wir hier beschreiben, sollte auf vielen Linux-Systemen funktionieren, die in ein bestehendes LAN eingebunden werden -- aber sicherlich nicht auf allen. Für den Fall, daß Sie weitere Informationen brauchen, verweisen wir auf ein Buch zum Thema »Verwaltung von TCP/IP-Netzwerken« -- beispielsweise eines von denen, die wir am Anfang des Kapitels erwähnt haben.
Wir gehen zunächst einmal davon aus, daß auf Ihrem Linux-System die notwendige TCP/IP-Software installiert ist. Dazu gehören solche wichtigen Clients wie telnet und ftp , Befehle zur Systemverwaltung wie ifconfig und route (meist in /etc oder /sbin zu finden), sowie Konfigurationsdateien für die Vernetzung (z.B. /etc/hosts ). In den Unterlagen zur Vernetzung unter Linux, die wir bereits erwähnt haben, wird beschrieben, wie die Linux-Netzwerk-Software installiert wird -- für den Fall, daß sie bei Ihnen noch nicht installiert ist.
Wir gehen außerdem davon aus, daß Ihr Kernel mit TCP/IP-Unterstützung konfiguriert und kompiliert wurde. Lesen Sie die Informationen zur Kompilierung des Kernels im Abschnitt » Einen neuen Kernel erstellen « in Kapitel 4 . Damit die Vernetzung unterstützt wird, müssen Sie im Schritt make config auf die entsprechenden Fragen mit »yes« antworten, den Kernel neu kompilieren, und mit dem neuen Kernel booten.
Sobald das erledigt ist, müssen Sie noch eine Reihe von Konfigurationsdateien anpassen, die von NET-2 benutzt werden. In der Regel ist dies recht einfach; unglücklicherweise besteht aber zwischen den verschiedenen Linux-Distributionen überhaupt keine Einigkeit darüber, wo die diversen Konfigurationsdateien und Hilfsprogramme für TCP/IP stehen sollen. Häufig sind diese in /etc zu finden, aber man hat sie auch schon in /usr/etc , /usr/etc/inet oder an anderen merkwürdigen Stellen entdeckt. Im schlimmsten Fall müssen Sie mit dem Befehl find herausfinden, wo die Dateien auf Ihrem System stehen. Beachten Sie auch, daß nicht alle Distributionen die NET-2-Konfigurationsdateien und -Programme an einer Stelle zusammenhalten -- manchmal sind sie über mehrere Verzeichnisse verstreut.
Wir setzen in diesem Abschnitt auch voraus, daß Sie in Ihrem System eine Ethernet-Karte benutzen. Es sollte nicht schwierig sein, diese Anweisungen für mehr als eine Netzverbindung anzupassen (wenn Ihr Rechner als Gateway fungiert).
Wir besprechen hier außerdem die Konfiguration von Systemen, die ausschließlich als Loopback-System arbeiten (also ohne Ethernet- oder SLIP-Verbindung). Auch wenn Sie keinen Netzanschluß haben, möchten Sie vielleicht das System für Loopback-TCP/IP konfigurieren, damit Sie mit den entsprechenden Programmen arbeiten können.
Bevor Sie TCP/IP konfigurieren können, müssen Sie noch folgende Informationen zum Aufbau Ihres Netzwerks zusammentragen. In den meisten Fällen kann entweder der Netzverwalter vor Ort oder Ihr Internet-Provider diese Informationen liefern.
Falls Sie den Loopback-Modus konfigurieren (also kein SLIP, kein Ethernet, nur TCP/IP-Verbindungen auf dem eigenen Rechner), ist die IP-Adresse 127.0.0.1.
Die Subnetzmaske bildet ein Bitmuster, das nach einer bitweisen UND-Verknüpfung mit einer IP-Adresse in Ihrem Netzwerk anzeigt, zu welchem Subnetz diese Adresse gehört. Ein Beispiel: Wenn Ihre Subnetzmaske 255.255.255.0 und Ihre IP-Adresse 128.17.75.20 ist, so ist der Subnetz-Teil Ihrer Adresse 128.17.75.
Wir unterscheiden hier zwischen der »Netzwerkadresse« und der »Subnetzadresse«. Erinnern Sie sich, daß in Klasse-B-Adressen die ersten beiden Bytes (in diesem Fall 128.17) das Netzwerk bezeichnen, und die letzten beiden Bytes den Rechner. Mit der Subnetzmaske 255.255.255.0 wird allerdings 128.17.75 als komplette Adresse des Subnetzes betrachtet (also Subnetz 75 im Netz 128.17), und nur die 20 zählt als Rechneradresse.
Ihre Netzverwalter haben die Subnetzmaske festgelegt und können Ihnen diese Information geben.
Dasselbe gilt für das Loopback-Device. Da die Loopback-Adresse immer 127.0.0.1 ist, ist die Netzmaske hierfür immer 255.0.0.0.
Reine Loopback-Systeme haben keine Subnetzadresse.
Beachten Sie, daß manche Systeme die Subnetzadresse selbst als Broadcast-Adresse benutzen. Fragen Sie bei den Netzverwaltern nach, falls Sie im Zweifel sind.
Reine Loopback-Systeme haben keine Broadcast-Adresse.
Ihre Netzverwalter können Ihnen die IP-Adressen aller Gateways in Ihrem Netzwerk mitteilen sowie die Adressen der Netze, mit denen diese Gateways verbunden sind. Später werden Sie diese Informationen zusammen mit dem Befehl route nutzen, um in der Routingtabelle die Einträge für die einzelnen Gateways zu erstellen.
Reine Loopback-Systeme haben keine Gateway-Adresse; dies gilt auch für Netzwerke ohne Verbindung nach außen.
Vielleicht planen Sie, Ihren eigenen Nameserver zu betreiben (indem Sie named konfigurieren und starten). Allerdings sollten Sie die Adresse des Nameservers benutzen, die Ihre Netzverwalter Ihnen mitteilen, solange Sie nicht unbedingt darauf angewiesen sind, einen eigenen Nameserver einzurichten (beispielsweise weil in Ihrem lokalen Netzwerk kein anderer Nameserver vorhanden ist). Auf jeden Fall enthalten die meisten Bücher über die Konfiguration von TCP/IP auch Informationen zum named .
Natürlich haben reine Loopback-Systeme keine Adresse für einen Nameserver.
Die rc -Dateien sind Skripts, die zur Konfiguration einiger systemweiter Ressourcen beim Booten von init aufgerufen werden. Die Netzwerkparameter werden mit Hilfe der fest zum System gehörenden Systemdämonen (wie z.B. sendmail , crond usw.) konfiguriert. Sie finden die rc -Dateien meist im Verzeichnis /etc , aber andere Systeme halten sie in /etc/rc.d .
Wir werden hier die rc -Dateien besprechen, die TCP/IP konfgurieren: rc.inet1 und rc.inet2 . rc.inet1 wird für die Konfiguration der grundlegenden Netzwerkparameter benutzt (etwa IP-Adressen und Routing-Informationen), und rc.inet2 startet die TCP/IP-Dämonen ( telnetd , ftpd usw.
Manche Systeme benutzen statt dieser beiden Dateien nur eine, die üblicherweise rc.inet oder rc.net heißt. Es spielt keine Rolle, welche Dateinamen benutzt werden, solange die Dateien die notwendige Konfiguration des Netzes vornehmen und während des Bootens von init aufgerufen werden.
init liest die Datei /etc/inittab um herauszufinden, welche Prozesse beim Booten gestartet werden sollen. Damit die Dateien /etc/rc.d/rc.inet1 und /etc/rc.d/rc.inet2 von init aufgerufen werden, könnten in Ihrer Datei /etc/inittab etwa folgende Einträge stehen:
n1:123456:wait:/etc/rc.d/rc.inet1 n2:123456:wait:/etc/rc.d/rc.inet2
Wir beschreiben die Datei inittab im Abschnitt » init und inittab « in Kapitel 4 . Das erste Feld enthält einen eindeutigen, zweistelligen Bezeichner für jeden Eintrag. Das zweite Feld führt die Runlevel auf, auf denen die Skripts aufgerufen werden; in diesem Beispiel initialisieren wir das Netzwerk bei den Runlevels 1 bis 6. Das Wort wait im dritten Feld weist init an zu warten, bis das Skript beendet ist, bevor init weitermacht. Das letzte Feld enthält den Namen des Skripts, das ausgeführt werden soll.
Auf vielen Systemen wird ein einziges rc -Skript auf mehreren Runlevels ausgeführt. inittab könnte dann z.B. folgenden Eintrag enthalten:
rc:123456:wait:/etc/rc.d/rc.M
/etc/rc.d/rc.M würde dann nacheinander rc.inet1 und rc.inet2 aufrufen.
Vielleicht ist es eine gute Idee, während der Konfiguration des Netzes rc.inet1 und rc.inet2 von Hand aufzurufen (als root), um eventuelle Probleme zu beheben. Später können Sie diese Dateien dann von einer anderen rc -Datei oder von /etc/inittab aus aufrufen.
Wir haben bereits erwähnt, daß rc.inet1 die grundlegende Konfiguration der Netzschnittstelle übernimmt. Dazu gehören die IP- und Netzwerkadresse sowie die Informationen in der Routingtabelle Ihres Systems. Es sind zwei Programme, die diese Parameter konfigurieren: ifconfig und route ; beide stehen in der Regel in /etc .
Mit ifconfig wird die Schnittstelle zum Netzwerk mit bestimmten Parametern konfiguriert -- etwa mit der IP-Adresse, Subnetzmaske, Broadcast-Adresse usw. Mit route werden Einträge in der Routingtabelle erzeugt und angepaßt.
Für die meisten Konfigurationen sollte eine
rc.inet1
-Datei funktionieren, die etwa so aussieht wie die folgende. Sie werden die
Datei natürlich an Ihr eigenes System anpassen müssen. Benutzen Sie
nicht
die IP- und Netzwerkadressen aus unserem Beispiel; es könnte sich um
einen tatsächlich im Internet vorhandenen Rechner handeln.
Wie Sie sehen, hat der Befehl
ifconfig
das Format:
Zwei Beispiele:
weist der IP-Adresse 127.0.0.1 das
lo
-Device (Loopback) zu, und:
weist der Adresse 127.17.75.20 das
eth0
-Device zu (erste Ethernet-Karte).
Neben der Adresse brauchen Ethernet-Schnittstellen normalerweise auch die
Subnetzmaske (mit der Option
netmask
zu setzen) und die Broadcast-Adresse (mit
broadcast
gesetzt).
Der Befehl
route
, wie wir ihn hier benutzen, hat das Format:
Mit dem Befehl
route
fügen wir Einträge in die Routingtabelle ein. Sie sollten eine Route
für das Loopback-Device definieren (wie wir das weiter oben gezeigt
haben), eine für das lokale Netzwerk, und eine für den
Standardgateway. Ein Beispiel: Falls Ihr Standardgateway 128.17.75.98 ist,
würden Sie folgenden Befehl einfügen:
route
kennt verschiedene Optionen. Ein
-net
oder
-host
vor dem
Ziel
zeigt
route
an, daß das Ziel ein Netzwerk bzw. ein bestimmter Rechner ist. (In den
meisten Fällen weisen Routen auf Netzwerke hin, aber in einigen
Fällen brauchen Sie vielleicht eine eigene Route zu einem allein
stehenden Rechner. In diesem Fall würden Sie
-host
für den Eintrag in der Routingtabelle benutzen.)
Mit der Option
Metrik
vergeben wir einen
Metrikwert
für diese Route. Die Metrikwerte werden benutzt, wenn es mehr als eine
Route zu einem bestimmten Ziel gibt und das System entscheiden muß,
welche davon es benutzen soll. Die Routen mit niedrigen Metrikwerten erhalten
Vorrang. In unserem Beispiel setzen wir den Metrikwert für unsere
Standardroute auf 1 und sorgen auf diese Weise dafür, daß diese
Route Vorrang vor allen anderen hat.
Wie soll das möglich sein, daß es mehr als eine Route zu einem
bestimmten Ziel gibt? Zunächst einmal können Sie in
rc.inet1
mehrere
route
-Befehle für ein Ziel eintragen -- beispielsweise, wenn Ihnen mehr als
ein Gateway zu einem bestimmten Netzwerk zur Verfügung steht. Es kann
aber auch vorkommen, daß in Ihre Routingtabellen dynamisch neue
Einträge gemacht werden, wenn Sie
routed
starten (wir kommen weiter unten noch darauf zu sprechen). Wenn Sie
routed
aufrufen, können andere Systeme Routinginformationen an Rechner im Netz
übertragen, die dazu führen, daß auf Ihrem Rechner weitere
Einträge in der Routingtabelle erzeugt werden. Wenn Sie den
Metrik
-Wert für Ihre Standardroute auf 1 setzen, stellen Sie damit sicher,
daß kein neuer Eintrag in der Routingtabelle Ihrem Standardgateway den
Vorrang nimmt.
Sie sollten die Manual-Pages zu
ifconfig
und
route
lesen, in denen die Syntax dieser Befehle im Detail beschrieben wird. Es kann
sein, daß weitere Optionen für Ihre Konfiguration relevant sind.
Lassen Sie uns weitermachen. In
rc.inet2
werden einige Dämonen gestartet, die von den TCP/IP-Programmen benutzt
werden. Sie brauchen diese Dämonen nicht für die Kommunikation Ihres
Rechners mit dem Netzwerk -- deshalb stehen sie in einer eigenen
rc
-Datei. In der Regel sollten Sie versuchen,
rc.inet1
zu konfigurieren und sich vergewissern, daß Ihr Rechner mit dem Netzwerk
Datenpakete austauschen kann, bevor Sie mit der Konfiguration von
rc.inet2
beginnen.
Zu den Dämonen, die von
rc.inet2
gestartet werden, gehören
inetd
,
syslogd
und
routed
. Falls die Version von
rc.inet2
auf Ihrem System derzeit noch einige andere Server startet, sollten Sie diese
auskommentieren, solange Sie Ihre Netzwerkkonfiguration debuggen.
Der wichtigste dieser Server ist
inetd
, der als eine Art »Vermittlungsstelle« für andere
Systemdämonen dient.
inetd
wartet im Hintergrund darauf, daß an bestimmten Netzwerkports
Verbindungen ankommen. Wenn eine Verbindung zustandekommt, startet
inetd
eine Kopie des passenden Dämons für diesen Port. Ein Beispiel: Wenn
eine eingehende
telnet
-Verbindung zustandekommt, wird
inetd
den Dämon
in.telnetd
starten, der anschließend die
telnet
-Verbindung bedient. Das ist einfacher und effizienter, als eine Kopie von
jedem einzelnen Dämon aufzurufen; auf diese Weise werden
Netzwerkdämonen nur bei Bedarf gestartet.
syslogd
ist der Dämon, der die Systemaktivitäten protokolliert -- er sammelt
Protokollnotizen (log messages) von verschiedenen Anwendungen und legt sie in
Dateien ab; die Informationen in der Datei
/etc/syslog.conf
bestimmen, welche Protokollmeldungen wo abgelegt werden.
routed
ist ein Server, der die dynamischen Routinginformationen verwaltet. Es kann
passieren, daß Ihr System weitere Informationen für die
Routingtabelle braucht, wenn es Pakete an ein anderes Netzwerk schicken
möchte.
routed
verwaltet die Routingtabelle, ohne daß der Benutzer eingreifen
muß.
Wir zeigen Ihnen hier ein Beispiel für eine
rc.inet2
, in der die Dämonen
syslogd<,inetd
und
routed
gestartet werden:
Zu den anderen Servern, die Sie vielleicht aus
rc.inet2
heraus starten möchten, gehört
named
.
named
ist ein Nameserver -- er übersetzt die (lokalen) IP-Adressen in Namen und
umgekehrt. Falls es an anderer Stelle in Ihrem Netzwerk keinen Nameserver
gibt, oder wenn Sie die Namen der lokalen Rechner an andere Systeme in Ihrer
Domain weitergeben möchten, müssen Sie eventuell
named
starten.
Die Konfiguration von
named
ist ziemlich schwierig und muß geplant werden; wir verweisen
interessierte Leser auf
DNS and BIND
.
Die Datei
/etc/hosts
enthält eine Liste von IP-Adressen mit den dazugehörigen
Rechnernamen. Im allgemeinen finden Sie hier nur Einträge für den
eigenen Rechner und vielleicht so »wichtige« Systeme wie Ihren
Nameserver oder Ihren Gateway. Der lokale Nameserver wird die Zuordnung von
Adressen zu den Namen anderer Rechner im Netz für Sie transparent
erledigen.
Wenn Ihr Rechner beispielsweise eggplant.veggie.com mit der IP-Adresse
128.17.75.20 ist, sieht Ihre
/etc/hosts
so aus:
Wenn Sie den Rechner nur im Loopback-Modus betreiben, sollte
/etc/hosts
nur eine Zeile für die Adresse 127.0.0.1 enthalten.
Die Datei
/etc/networks
enthält die Namen und Adressen des eigenen sowie anderer Netzwerke. Sie
wird vom Befehl
route
benutzt und ermöglicht es, ein Netzwerk mit seinem Namen statt seiner
Adresse zu bezeichnen.
Jedes Netzwerk, zu dem Sie mit dem Befehl
route
eine Route eintragen möchten,
muß
in
/etc/networks
eingetragen sein. (
route
wird normalerweise in
rc.inet1
aufgerufen -- siehe oben.)
Ein Beispiel:
Jetzt können wir statt:
eingeben:
Egal, ob Sie mit
route
den Namen benutzen möchten oder nicht, es muß auf jeden Fall
für jede Netzwerkroute ein Eintrag in
/etc/networks
vorhanden sein.
Die Datei
/etc/hosts
bestimmt darüber, wie Ihr System Rechnernamen auflöst (in
IP-Adressen wandelt). Sie sollte die beiden Zeilen:
enthalten. Diese Zeilen weisen die Auflösungsbibliotheken an,
umzuwandelnde Namen zuerst in
/etc/hosts
nachzuschlagen und dann den Nameserver (falls vorhanden) zu befragen. Der
Eintrag multi bewirkt, daß Sie zu einem bestimmten Rechnernamen in
/etc/hosts
mehrere IP-Adressen angeben können.
Diese Datei konfiguriert den Name Resolver (etwa: Namenauflöser), und
enthält zu diesem Zweck die Adresse Ihres Nameservers (falls vorhanden)
und Ihren DNS-Domainnamen. Ihr Domainname ist der Fully Qualified Domain Name
(vollständiger Domainname), jedoch ohne den Namen des Rechners (dies gilt
z.B. für Systeme, die im Internet registriert sind). Wenn Ihr
vollständiger Rechnername also loomer.vpizza.com lautet, ist der
Domainname einfach vpizza.com. Falls Sie sich nicht sicher sind, können
Sie den Domainnamen bei Ihren Netzverwaltern erfragen.
Das System eggplant.veggie.com mit dem Nameserver unter der Adresse
128.17.75.55 hätte beispielsweise folgende Einträge in
/etc/resolv.conf
:
Sie können mehr als einen Nameserver eintragen, aber jeder einzelne
muß in
resolv.conf
seine eigene nameserver-Zeile haben.
Sie sollten den Rechnernamen Ihres Systems mit dem Befehl
hostname
festlegen. Dieser Befehl wird in der Regel von
/etc/rc
oder
/etc/rc.local
aus aufgerufen; durchsuchen Sie die
rc
-Dateien Ihres Systems um festzustellen, wo der
hostname
-Aufruf erfolgt. Ein Beispiel: Wenn Ihr (vollständiger) Rechnername
eggplant.veggie.com lautet, lassen Sie in der entsprechenden
rc
-Datei folgenden Befehl ausführen:
Beachten Sie, daß die ausführbare Datei
hostname
auf Ihrem System in einem anderen Verzeichnis als
/bin
stehen könnte.
Sobald die verschiedenen Konfigurationsdateien für das Netz an Ihr System
angepaßt sind, sollten Sie in der Lage sein, neu zu booten (mit einem
TCP/IP-fähigen Kernel) und die Konfiguration zu testen.
Vielleicht sollten Sie beim ersten Booten des Systems den automatischen Aufruf
von
rc.inet1
und
rc.inet2
unterdrücken und diese beiden Skripts von Hand starten, nachdem das
System hochgefahren ist. Das gibt Ihnen die Chance, alle Fehlermeldungen
mitzulesen, die Skripts zu ändern und es noch einmal zu versuchen. Sobald
alles korrekt abläuft, können Sie die Skripts von
/etc/inittab
aus aufrufen.
Eine gute Methode, die Verbindungen zum Netzwerk zu testen, ist ein
telnet
an einen anderen Rechner. Versuchen Sie zunächst, eine Verbindung zu
einem Rechner im lokalen Netzwerk herzustellen; wenn das funktioniert,
versuchen Sie es mit Rechnern in anderen Netzen. Mit dem ersten Schritt testen
Sie die Verbindung zwischen Ihrem Rechner und dem lokalen Netzwerk; mit dem
zweiten Schritt stellen Sie fest, ob Ihnen durch Ihr Gateway hindurch der Rest
der Welt offensteht.
Falls Sie in der Lage sind, mit weit entfernten Rechnern (remote) zu
kommunizieren, aber nicht mit Systemen im selben Subnetz, deutet das auf ein
Problem entweder mit der Subnetzmaske oder mit dem Routingtabelleneintrag
für das lokale Netz hin.
Wenn Sie versuchen, einen anderen Rechner zu erreichen, sollten Sie das zuerst
mit der IP-Adresse des fremden Rechners testen. Falls das funktioniert, aber
mit dem Rechnernamen keine Verbindung zustandekommt, kann das Problem entweder
in der Konfiguration des Nameservers liegen (z.B. in
/etc/resolv.conf
oder
/etc/host.conf
), oder die Route zum Nameserver ist nicht korrekt.
Die häufigsten Ursachen für Probleme im Netzwerk sind Fehler in der
Routingtabelle. Mit dem Befehl:
lassen Sie die Routingtabelle anzeigen; wir haben das Format der Anzeige mit
diesem Befehl im vorhergehenden Abschnitt beschrieben. Die Manual-Page zu
netstat
enthält weitere Details. Wenn Sie
netstat
ohne die Option
-n
aufrufen, erhalten Sie eine Anzeige mit den Namen der Rechner und Netze statt
der IP-Adressen.
Sie können die Routingtabelle debuggen, indem Sie entweder die Datei
rc.inet1
editieren und neu booten, oder Sie geben den Befehl
route
von Hand ein, um Einträge hinzuzufügen oder zu löschen. In der
Manual-Page zu
route
finden Sie eine vollständige Beschreibung der Befehlssyntax. Beachten
Sie, daß allein das Editieren von
rc.inet1
mit erneutem Aufruf von
route
die alten Einträge nicht aus der Routingtabelle entfernt; Sie müssen
entweder neu booten oder mit
route del
die Einträge von Hand löschen.
Wenn Sie überhaupt keine Verbindung zustande bekommen, liegt das Problem
eventuell in der Konfiguration der Ethernet-Schnittstelle. Vergewissern Sie
sich zunächst, daß die Ethernet-Karte beim Booten an der richtigen
Adresse und mit dem richtigen IRQ gefunden wurde. Sie finden diese
Informationen in den Boot-Meldungen des Kernels; wenn Sie
syslogd
benutzen, werden diese Meldungen auch in einer Datei wie z.B.
/var/adm/messages
gespeichert.
Falls Ihre Ethernet-Karte nicht richtig gefunden wird, müssen Sie
eventuell einige Kernel-Parameter anpassen, um das Problem zu beheben. Im
Ethernet-HOWTO von Linux finden Sie ausführliche Informationen zum
Debuggen der Ethernet-Konfiguration. Oft braucht man zur Behebung des Problems
nur am LILO-Boot-Prompt die korrekten Werte für IRQ und Portadresse
anzugeben. Wenn Sie beispielsweise via LILO mit dem Befehl:
booten, werden für die Schnittstelle
eth0
die Werte: IRQ 9, Basisadresse 0x300 und der externe Transceiver (durch die 1
im vierten Feld) eingestellt. Wenn Sie den internen Transceiver benutzen
möchten, machen Sie im vierten Feld aus der 1 eine 0.
Denken Sie auch an die Möglichkeit, daß die Ethernet-Karte defekt
oder nicht richtig mit Ihrem Rechner oder dem Netz verbunden sein kann.
Defekte Ethernet-Karten und -Kabel können unendlich viele Probleme
verursachen -- u.a. gelegentliche Netzausfälle, Systemabstürze usw.
Wenn Sie bei Ihren Bemühungen das Ende der Fahnenstange erreicht haben,
sollten Sie vielleicht Ethernet-Karte oder -Kabel austauschen um
festzustellen, ob hier die Ursache des Problems zu finden ist.
(3)
Wenn Ihre Ethernet-Karte gefunden wird, aber das System trotzdem nicht mit dem
Netzwerk kommunizieren kann, ist eventuell die Konfiguration der
Schnittstellen mit
ifconfig
nicht in Ordnung. Vergewissern Sie sich, daß Sie für Ihren Rechner
die richtige IP-Adresse, Broadcast-Adresse und Subnetzmaske eingetragen haben.
Wenn Sie
ifconfig
ohne Argumente aufrufen, erhalten Sie Informationen über Ihre
Ethernet-Konfiguration.
Das Serial Line Internet Protocol (SLIP) gestattet die Benutzung von TCP/IP
über eine serielle Leitung -- sei es eine Telefonleitung (unter Einsatz
eines Modems) oder irgendeine Art von asynchroner Standleitung. Wenn Sie SLIP
benutzen möchten, brauchen Sie einen SLIP-Server in Ihrer Nähe, in
den Sie sich einwählen können. Viele Universitäten und Firmen
bieten SLIP-Zugänge zu geringen Kosten an.
SLIP ist grundsätzlich anders als Ethernet, weil das »Netzwerk«
lediglich aus zwei Rechnern besteht -- dem SLIP-Client (das sind Sie) und dem
SLIP-Server. Aus diesem Grund bezeichnet man SLIP oft als
»Punkt-zu-Punkt«-Verbindung. Ein anderes Protokoll, das diese Idee
verwirklicht, das Point-to-Point-Protocol (PPP), ist ebenfalls unter Linux
verfügbar. Die Konfiguration von PPP wird im
Linux Network Administrator's Guide
beschrieben.
Es gibt zwei wichtige Programme im Zusammenhang mit SLIP --
dip
und
slattach
. Beide werden gebraucht, um eine SLIP-Verbindung über eine serielle
Leitung herzustellen. Sie müssen eines dieser Programme benutzen, um mit
SLIP arbeiten zu können -- es reicht nicht aus, den SLIP-Server
anzuwählen (mit einem Kommunikationsprogramm wie z.B.
Kermit
) und dann
ifconfig
- und
route
-Befehle zu erteilen. Das liegt daran, daß
dip
und
slattach
einen bestimmten
ioctl( )
-Systemaufruf absetzen, um die Kontrolle über die serielle Schnittstelle
zu übernehmen, die als SLIP-Interface benutzt wird.
Sie können
dip
benutzen, um in einen SLIP-Server einzuwählen, dort einzuloggen (nachdem
z.B. Ihr Benutzername und das Paßwort übergeben wurden) und
schließlich über die offene serielle Leitung eine SLIP-Verbindung
aufzubauen.
slattach
tut dagegen nicht viel mehr, als die serielle Schnittstelle für SLIP zu
öffnen; es ist dann nützlich, wenn Sie eine Standleitung zu Ihrem
SLIP-Server haben und weder das Einwählen noch die Übergabe von
Informationen notwendig sind, um eine Verbindung herzustellen.
Sie können
dip
auch benutzen, um Ihr Linux-System als SLIP-Server zu konfigurieren, in den
andere Rechner einwählen können, um durch eine zweite
Ethernet-Schnittstelle in Ihrem System eine Verbindung zum Netz zu finden.
Dokumentation und Manual-Page zu
dip
beschreiben diesen Vorgang im Detail.
Wenn Sie eine Verbindung zu einem SLIP-Server herstellen, wird dieser Ihnen
(normalerweise) mittels einer von zwei Methoden eine IP-Adresse zuweisen.
Manche SLIP-Server vergeben »statische« IP-Adressen; in diesem Fall
ist Ihre Adresse bei allen Verbindungen mit dem Server gleich. Andere
SLIP-Server dagegen vergeben die IP-Adressen »dynamisch«; dann
bekommen Sie bei jeder Verbindung eine andere Adresse. Bei dieser
Konstellation zeigt der Server normalerweise beim Zustandekommen der
Verbindung die IP- und Gateway-Adresse an.
dip
ist in der Lage, diese Werte aus den Login-Meldungen des Servers zu
extrahieren und damit die SLIP-Schnittstelle zu konfigurieren.
Im Prinzip geschieht die Konfiguration einer SLIP-Verbindung auf die gleiche
Weise wie für eine Loopback- oder Ethernet-Verbindung. Wir besprechen die
wichtigsten Unterschiede etwas weiter unten. Lesen Sie den vorhergehenden
Abschnitt zur Konfiguration der wichtigsten TCP/IP-Dateien und beachten Sie
dann die Änderungen, die wir hier besprechen.
Wenn Sie einen SLIP-Server benutzen, der statische IP-Adressen vergibt,
sollten Sie in
/etc/hosts
Einträge für Ihre IP-Adresse und Ihren Rechnernamen einfügen.
(Ihre Netzverwalter können Ihnen die IP-Adresse und den offiziellen
Rechnernamen mitteilen.) Sie sollten außerdem die Dateien
rc.inet2
,
host.conf
und
resolv.conf
konfigurieren, wie wir das im Abschnitt
»
TCP/IP und Ethernet konfigurieren
«
beschrieben haben.
Sie werden auch die Datei
rc.inet1
konfigurieren müssen; allerdings brauchen Sie die Befehle
ifconfig
und
route
nur für das Loopback-Device einzufügen. Wenn Sie mit
dip
eine Verbindung zu einem SLIP-Server herstellen, wird
dip
auch mit den entsprechenden
ifconfig
- und
route
-Befehlen die SLIP-Schnittstelle konfigurieren. (Wenn Sie aber
slattach
benutzen,
müssen
Sie die Befehle
ifconfig
und
route
für die SLIP-Schnittstelle in
rc.inet1
einfügen (siehe unten).
dip
sollte Ihre Routingtabelle beim Zustandekommen einer Verbindung in geeigneter
Weise konfigurieren. Es kann allerdings vorkommen, daß
dip
dies für Ihre Konfiguration nicht korrekt erledigt; dann müssen Sie
die Befehle
ifconfig
oder
route
von Hand aufrufen, nachdem die Verbindung zum Server hergestellt wurde. Das
läßt sich am einfachsten in einem Shell-Skript erledigen, das
zuerst
dip
und gleich anschließend die notwendigen Konfigurationsbefehle aufruft.
Mit diesem Shell-Skript können Sie dann Ihre SLIP-Verbindung aufbauen.
In den meisten Fällen ist der Gateway für Ihr System identisch mit
der IP-Adresse des SLIP-Servers. Entweder Sie kennen die Gateways-Adresse
bereits, oder der Server zeigt sie beim Verbindungsaufbau an. Im letzteren
Fall kann das Chat-Skript (etwa: Plauder-Skript; Chat ist die
»Unterhaltung« der beiden Rechner beim Verbindungsaufbau) von
dip
(siehe unten) diese Informationen beim SLIP-Server abfragen.
Sie müssen mit
ifconfig
eventuell das Argument
pointopoint
angeben, wenn
dip
die Schnittstelle nicht korrekt konfiguriert. Ein Beispiel: Wenn die Adresse
Ihres SLIP-Servers 128.17.75.98 lautet und Ihre IP-Adresse 128.17.75.2 ist,
müssen Sie vielleicht als root folgenden Befehl aufrufen:
nachdem Sie mit
dip
die Verbindung hergestellt haben. Hier hilft die Manual-Page zu
ifconfig
weiter.
Beachten Sie, daß die SLIP-Schnittstellen bei den Befehlen
ifconfig
und
route
mit
sl0
,
sl1
usw. bezeichnet werden; die Ethernet-Schnittstellen dagegen heißen
eth0
,
eth1
usw.
Im Abschnitt
»
dip benutzen
«
weiter unten erklären wir, wie Sie
dip
für die Verbindung zum SLIP-Server konfigurieren.
Falls Sie eine Standleitung oder direkte Kabelverbindung zu Ihrem SLIP-Server
haben, brauchen Sie kein
dip
, um eine Verbindung herzustellen. Benutzen Sie statt dessen
slattach
, um die SLIP-Schnittstelle zu konfigurieren.
Für diesen Fall sollte Ihre Datei
/etc/rc.inet1
etwa so aussehen:
slattach
weist der bezeichneten seriellen Leitung das erste freie SLIP-Device (
sl0
,
sl1
usw.) zu.
Beachten Sie, daß der erste Parameter zu
slattach
das SLIP-Protokoll bezeichnet, das benutzt werden soll. Zur Zeit gibt es die
beiden gültigen Werte slip und cslip. slip ist, wie Sie sicherlich
erwartet haben, das reguläre SLIP, und cslip bezeichnet das SLIP mit
Komprimierung der Datagramm-Header. In den meisten Fällen sollten Sie
cslip benutzen; falls Sie damit allerdings auf Probleme stoßen,
müssen Sie vielleicht auf slip zurückgreifen.
Wenn Ihr SLIP-Server die IP-Adresse dynamisch zuweist, können Sie Ihre
Adresse natürlich nicht im voraus wissen -- und deshalb können Sie
auch keinen Eintrag dafür in
/etc/hosts
machen. (Sie sollten trotzdem einen Eintrag für Ihren Rechner mit der
Loopback-Adresse 127.0.0.1 haben.)
Viele SLIP-Server zeigen die IP-Adresse (und die Adresse des Servers) beim
Verbindungsaufbau an. Ein bestimmter Server gibt beispielsweise folgende
Meldung aus:
dip
ist in der Lage, diese Adressen aus der Ausgabe des Servers zu extrahieren und
damit die SLIP-Schnittstelle zu konfigurieren.
Im vorhergehenden Abschnitt finden Sie Informationen zur Konfiguration der
verschiedenen TCP/IP-Dateien für den Einsatz mit SLIP.
Wenn Sie
dip
benutzen möchten, brauchen Sie ein »Chat-Skript«, in dem
Befehle enthalten sind, die während des Logins für die Kommunikation
mit dem SLIP-Server benötigt werden. Mit diesen Befehlen können Sie
automatisch Ihren Benutzernamen und Ihr Paßwort an den Server
übermitteln sowie Ihre IP-Adresse vom Server in Erfahrung bringen.
Beispiel 7--1.
ist ein Beispiel für ein
dip
-Chat-Skript, das Sie mit einem dynamischen Server verbindet. Bei statischen
Servern müssen Sie am Anfang des Skripts die Variablen $local und $remote
mit Ihrer IP-Adresse bzw. der IP-Adresse des Servers belegen. Die Kommentare
in unserem Beispielskript erklären, was Sie zu tun haben.
Beispiel 7-1. Beispiel für ein Chat-Skript
dip
führt die Befehle
ifconfig
und
route
automatisch aus, und benutzt dabei die Werte der Variablen $local und $remote.
In diesem Beispiel werden die Variablen mit Hilfe des Befehls
get...remote
belegt, der die Antworten des SLIP-Servers liest und sie den Variablen
zuweist.
Falls die Befehle
ifconfig
und
route
, die
dip
benutzt, nicht zum Erfolg führen, können Sie entweder in einem
Shell-Skript nach dem Aufruf von
dip
die korrekten Befehle ausführen, oder den Quellcode von
dip
selbst anpassen. Wenn Sie
dip
mit der Option
-v
aufrufen, erhalten Sie während des Verbindungsaufbaus
Debugging-Meldungen, die beim Auffinden eventueller Schwachstellen helfen
sollten.
Wenn Sie anschließend
dip
aufrufen und eine SLIP-Verbindung herstellen wollen, können Sie etwa
folgenden Befehl eingeben:
Wir setzen voraus, daß die verschiedenen
dip
-Dateien und das Chat-Skript (
mychat.dip
) in
/etc/dip
stehen.
Wenn
dip
eine Verbindung hergestellt hat, bleibt es als Hintergrundprozeß aktiv.
Sie sollten in der Lage sein, über diese SLIP-Verbindung
telnet
,
ftp
usw. zu benutzen.
Zum Beenden der SLIP-Verbindung »killen« Sie einfach den
dip
-Prozeß. Einige Versionen von
dip
werten verschiedene Signale aus, so daß Sie eventuell kill -9 eingeben
müssen, um die Verbindung beenden zu können.
Mit dem Material, was wir bis hierher vorgestellt haben, sollten Sie einer
»Unterhaltung« mit Ihrem Netzwerk schon recht nahe kommen -- sei es
im Ethernet oder via SLIP. Wir möchten Ihnen noch einmal empfehlen, ein
Buch zum Thema »Konfiguration von TCP/IP-Netzwerken« zu
konsultieren; dies gilt insbesondere dann, wenn Ihr Netzwerk in irgendeiner
Weise vom Standard abweicht. Fragen Sie im Zweifelsfall Ihre Netzverwalter --
die Konfiguration von TCP/IP ist unter Linux nicht anders als unter anderen
UNIX-Versionen.
#!/bin/sh
# Dies ist /etc/rc.d/rc.inet1 - konfiguriere die TCP/IP-Interfaces
# Zuerst das Loopback-Device konfigurieren
HOSTNAME=`hostname`
/etc/ifconfig lo 127.0.0.1 # Standardnetzmaske 255.0.0.0
/etc/route add 127.0.0.1 # eine Route zum Loopback-Device
# Als nächstes Ethernet konfigurieren. Wenn Sie nur Loopback oder SlIP
# benutzen, kommentieren Sie die restlichen Zeilen aus.
# An Ihr System anpassen.
IPADDR="128.17.75.20" # IHRE IP-Adresse eintragen
NETMASK="255.255.255.0" # IHRE Subnetzmaske eintragen
NETWORK="128.17.75.0" # IHRE Netzwerkadresse eintragen
BROADCAST="128.17.75.255" # IHRE Broadcast-Adresse eintragen
GATEWAY="128.17.75.98" # IHRE Standardgateway-Adresse eintragen
# Konfiguriere eth0 mit den o.a. Informationen
/etc/ifconfig eth0 ${IPADDR} netmask ${NETMASK} broadcast ${BROADCAST}
# Ein Router für das eigene Netzwerk
/etc/route add ${NETWORK}
# Eine Route zum Standard-Gateway
/etc/route add default gw ${GATEWAY} metric 1
# Ende der Ethernet-Konfiguration
ifconfig interface device optionen ...
ifconfig lo 127.0.0.1
ifconfig eth0 127.17.75.20
route add [ -netz | -rechner ] ziel [ gw gateway ]
[ metric metrik ] optionen
Dabei bezeichnet das
Ziel
die Zieladresse für diese Route (oder hier steht das Schlüsselwort
default für die Standardroute); der
Gateway
ist die IP-Adresse des Gateways für diese Route; und die
Metrik
gibt den Metrikwert für diese Route an (wir kommen weiter unten darauf
zurück).
route add default gw 128.17.75.98
#! /bin/sh
# Beispiel für /etc/rc.d/rc.inet2
# Starte syslogd
if [ -f /etc/syslogd ]
then
/etc/syslogd
fi
# Starte inetd
if [ -f /etc/inetd ]
then
/etc/inetd
fi
# Starte routed
if [ -f /etc/routed ]
then
/etc/routed -q
fi
[49]
/etc/hosts
127.0.0.1 localhost
128.17.75.20 eggplant.veggie.com eggplant
/etc/networks
default 0.0.0.0 # Standardroute - obligatorisch
loopnet 127.0.0.0 # Loopback-Netz - obligatorisch
veggie-net 128.17.75.0 # IHRE Netzwerkadresse eintragen
route add 128.17.75.20
route add veggie-net
/etc/host.conf
order hosts,bind
multi on
/etc/resolv.conf
domain veggie.com
nameserver 128.17.75.55
Den Rechnernamen festlegen
/bin/hostname eggplant.veggie.com
Der erste Versuch
netstat -rn
lilo: linux ether=9,0x300,0,1,eth0
Die SLIP-Konfiguration
SLIP-Verbindungen mit statischen IP-Adressen und dip
ifconfig sl0 128.17.75.2 pointopoint 128.17.75.98
SLIP-Verbindungen mit statischen IP-Adressen und slattach
#!/bin/sh
IPADDR="128.17.75.2" # IHRE IP-Adresse eintragen
REMADDR="128.17.75.98" # Die IP-Adresse IHRES SLIP-Servers eintragen
# Passen Sie die folgenden Zeile an die serielle Schnittstelle
# für die SLIP-Verbindung an
slattach -p cslip -s 19200 /dev/ttyS0
/etc/ifconfig sl0 $IPADDR pointopoint $REMADDR up
/etc/route add default gw $REMADDR
SLIP-Verbindungen mit dynamischen IP-Adressen und dip
Your IP address is 128.253.154.44.
Server address is 128.253.154.2.
dip benutzen
main:
# Maximum Transfer Unit (MTU) einstellen. Das ist die maximale Anzahl
# an Paketen, die durch die SLIP-Schnittstelle gehen. Viele SLIP-Server
# benutzen entweder 1500 oder 1006; fragen Sie im Zweifelsfall Ihre
# Netzverwalter.
get $mtu 1500
# Adressen Ihres Rechners ($local) und des Servers ($remote) angeben.
# Bei dynamischen SLIP-Servern werden diese Zeilen auskommentiert.
# get $local eggplant.veggie.com
# get $remote slipserver.veggie.com
# SLIP-Route zur Standardroute des Systems machen.
default
# Den seriellen Port und die Geschwindigkeit bestimmen.
port cua03
speed 38400
# Modem und Leitung initialisieren. Falls dabei Probleme
# auftauchen, kommentieren Sie diese Zeile aus.
reset
# Vorbereitung zum Wählen. Fügen Sie hier die Initialisierung
# für Ihr Modem ein.
send ATT&C1&D2N3&Q5%M3%C1N1W1L1S48=7\r
wait OK 2
if $errlvl != 0 goto error
# SLIP-Server anwählen.
dial 5551234
if $errlvl != 0 goto error
wait CONNECT 60
if $errlvl != 0 goto error
# Die Verbindung steht. Loggen Sie ein.
login:
sleep 3
send \r\n\r\n
# Warten auf den Login-Prompt.
wait login: 10
if $errlvl != 0 goto error
# Benutzernamen übertragen.
send USERNAME\n
# Warten auf den Paßwort-Prompt.
wait ord: 5
if $errlvl != 0 goto error
# Paßwort übertragen.
send PASSWORD\n
# Warten, bis der SLIP-Server OK meldet.
wait annex: 30
if $errlvl != 0 goto error
# Befehle zur Initialisierung der Verbindung an SLIP-Server senden.
send slip\n
wait Annex 30
# Fremde IP-Adresse vom SLIP-Server erfragen. Der `get...remote'-
# Befehl liest Text im Format xxx.xxx.xxx.xxx und weist ihn der
# Variablen zu, die als erstes Argument angeführt ist (hier: $remote).
# Kommentieren Sie die folgenden Zeilen aus, wenn Sie einen statischen
# SLIP-Server benutzen.
get $remote remote
if $errlvl != 0 goto error
wait Your 30
# Lokale IP-Adresse erfragen und der Variablen $local zuweisen.
get $local remote
if $errlvl != 0 goto error
# SLIP-Verbindung starten.
done:
print CONNECTED to $remote at $rmtip
print GATEWAY address $rmtip
print LOCAL address $local
# SLIP mit komprimierten Headern benutzen. Ändern Sie dies auf
# "mode SLIP", wenn Ihr Server kein CSLIP unterstützt.
mode CSLIP
goto exit
error:
print SLIP to $remote failed.
exit:
# Done.
/etc/dip/dip -v /etc/dip/mychat 2>&1
Fußnoten
Vorherige
Abschnitt 
Nächste Abschnitt