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 6

Das Point-to-Point-Protokoll

Das Point-to-Point-Protokoll (PPP) ist ein Protokoll, mit dem Sie Datagramme über eine serielle Leitung übertragen können. In diesem Kapitel behandeln wir die grundlegenden Bausteine von PPP. Wir gehen auch auf PPP over Ethernet (PPPoE) ein, das inzwischen von vielen Telekommunikationsunternehmen verwendet wird, um DSL-Verbindungen herzustellen.

Die Basis von PPP bildet das High-Level Data Link Control-Protokoll (HDLC). Dieses Protokoll definiert die Begrenzung der einzelnen PPP-Frames und liefert eine 16-Bit-Prüfsumme.1 Ein PPP-Frame ist in der Lage, auch Pakete anderer Protokolle als IP zu transportieren, etwa Novells IPX oder AppleTalk. PPP erreicht dies, indem es ein Protokollfeld in den HDLC-Frame aufnimmt, das den Typ des Pakets bestimmt, das sich in diesem Frame befindet.

LCP, das Link Control Protocol, setzt auf HDLC auf und dient dazu, die Konfiguration der Leitung zwischen den beiden Partnern auszuhandeln. Dazu gehört beispielsweise die Maximum Receive Unit (MRU), mit der die maximale Datagrammgröße bestimmt wird, die ein Host zu empfangen bereit ist.

Ein wichtiger Schritt am Anfang der Konfiguration einer PPP-Verbindung ist die Client-Authentifizierung. Obwohl sie nicht vorgeschrieben ist, ist sie für Wählverbindungen dennoch unbedingt zu empfehlen, um potenzielle Eindringlinge fernzuhalten. Üblicherweise fordert der angerufene Host (der Server) den Client auf, sich auszuweisen, indem er beweist, dass er einen geheimen Schlüssel kennt. Wenn der Anrufer nicht mit der richtigen Antwort aufwarten kann, wird die Verbindung unterbrochen. Bei PPP funktioniert die Authentifizierung in beiden Richtungen, d.h., der Anrufer kann auch den Server auffordern, sich auszuweisen. Diese Authentifizierungs-Prozeduren laufen völlig unabhängig voneinander ab. Es gibt zwei Protokolle für unterschiedliche Arten der Authentifizierung, die wir weiter unten noch besprechen werden: Password Authentication Protocol (PAP) und Challenge Handshake Authentication Protocol (CHAP).

Jedes Netzwerkprotokoll wie IP und AppleTalk, das über die Datenverbindung geroutet wird, wird mit Hilfe eines entsprechenden Network Control Protocol (NCP) dynamisch konfiguriert. Sollen zum Beispiel IP-Datagramme über eine Verbindung geschickt werden, müssen beide Kommunikationspartner zuerst aushandeln, welche IP-Adresse von der jeweils anderen Seite verwendet wird. Das dafür verwendete Protokoll ist IPCP, das Internet Protocol Control Protocol.

Neben der Übertragung normaler IP-Datagramme unterstützt PPP auch die Header-Komprimierung von IP-Datagrammen nach Van Jacobson. Dabei werden Header von TCP-Paketen auf eine Größe von bis zu drei Bytes reduziert. Sie wird allgemein als VJ-Header-Komprimierung bezeichnet. Die Verwendung der Komprimierung kann ebenfalls während des Starts über IPCP vereinbart werden.

PPP auf Linux

Bei Linux ist die PPP-Funktionalität in zwei Teile untergliedert: in eine Kernel-Komponente, die die Low-Level-Protokolle verwaltet (HDLC, IPCP, IPXCP usw.), und einen Dämon (pppd), der die verschiedenen höheren Protokolle wie PAP und CHAP behandelt. Die aktuelle Version von PPP für Linux besteht aus dem PPP-Dämon pppd und einem Programm namens chat, das die Einwahl in den entfernten Rechner automatisiert.

Der PPP-Kernel-Treiber wurde von Michael Callahan geschrieben und von Paul Mackerras überarbeitet. pppd stammt von einer freien PPP-Implementierung für Sun- und 386BSD-Maschinen ab, die von Drew Perkins und anderen geschrieben wurde und von Paul Mackerras gepflegt wird. Auf Linux wurde sie von Al Longyear portiert. chat wurde von Karl Fox geschrieben.

PPP wird über einen speziellen tty-Modus (line discipline) implementiert. Um eine serielle Leitung als PPP-Verbindung zu verwenden, bauen Sie die Verbindung wie gewohnt über Ihr Modem auf und schalten Sie danach in den PPP-Modus. In diesem Modus werden alle eingehenden Daten an den PPP-Treiber weitergeleitet, der die eingehenden HDLC-Frames auf Gültigkeit prüft (jeder HDLC-Frame enthält eine 16-Bit-Prüfsumme), sie auspackt und verteilt. Im Moment kann PPP sowohl das IP-Protokoll (optional mit Van-Jacobson-Komprimierung) als auch das IPX-Protokoll transportieren.

Der Kernel-Treiber wird von pppd unterstützt, das die gesamte Initialisierungs- und Authentifizierungsphase übernimmt, die notwendig ist, bevor die eigentlichen Daten über die Leitung geschickt werden können. Feineinstellungen am Verhalten von pppd können über eine Reihe von Optionen vorgenommen werden. Da PPP ziemlich komplex ist, ist es unmöglich, sie alle in einem einzigen Kapitel zu behandeln. Deshalb kann dieses Buch nicht alle Aspekte von pppd behandeln, sondern nur eine Einführung bieten. Für weitere Informationen seien Sie auf die Manpages von pppd oder die READMEs in der pppd-Quelldistribution verwiesen. Dort sollten Sie Antworten auf die meisten Fragen finden, die in diesem Kapitel nicht behandelt werden konnten. Das PPP-HOWTO kann ebenfalls von Nutzen sein.

Die womöglich beste Hilfe zur Konfiguration von PPP erhalten Sie von Leuten, die dieselbe Linux-Distribution wie Sie benutzen. Konfigurationsfragen zu PPP gibt es häufig; daher sollten Sie auch in Mailinglisten lokaler Benutzergruppen hineinschauen oder die Leute im IRC Linux Channel fragen. Wenn Sie nach dem Lesen der Dokumentation immer noch Probleme haben, wenden Sie sich an die Newsgroup comp.protocols.ppp. In dieser Newsgroup finden Sie viele von den Leuten, die an der Entwicklung von pppd beteiligt waren.

Arbeiten mit pppd

Wenn Sie sich über eine PPP-Verbindung an das Internet anschließen wollen, müssen Sie die grundlegenden Netzwerkfunktionen wie das Loopback-Gerät und den Resolver eingerichtet haben. Wie das funktioniert, wurde in den Kapiteln 4 und 5 besprochen. Den Nameserver Ihres Internet Service Providers könnten Sie einfach in die Datei /etc/resolv.conf eintragen, aber das würde bedeuten, dass jede DNS-Anfrage über Ihre serielle Leitung laufen müsste. Das ist natürlich keine optimale Lösung, denn je näher Sie Ihrem Nameserver sind, desto schneller werden DNS-Anfragen beantwortet. Eine alternative Lösung besteht darin, auf einem Host in Ihrem Netzwerk einen Caching-Only-Nameserver einzurichten. In der Praxis würde dies dazu führen, dass nur die jeweils erste DNS-Anfrage nach einem bestimmten Host über die serielle Leitung übertragen werden müsste, jede folgende würde dann von Ihrem lokalen Nameserver beantwortet werden, und das erheblich schneller. Diese Konfiguration wird in Kapitel 5 beschrieben.

Um sich zur Einleitung vor Augen zu führen, wie eine PPP-Verbindung mit pppd aufgebaut wird, stellen Sie sich vor, dass Sie wieder an vlager sitzen. Sie haben bereits den PPP-Server c3po angewählt und sich in den Zugang ppp eingeloggt. c3po hat seinen PPP-Treiber schon gestartet. Nachdem Sie das Kommunikationsprogramm beendet haben, mit dem Sie die Verbindung hergestellt hatten, führen Sie den folgenden Befehl aus, wobei Sie die hier angegebene Schnittstelle ttyS3 gegebenenfalls entsprechend ändern:

# pppd /dev/ttyS3 38400 crtscts defaultroute

Mit diesem Befehl schalten Sie die serielle Leitung ttyS3 in den PPP-Modus und bauen eine IP-Verbindung zu c3po auf. Die Übertragungsgeschwindigkeit des seriellen Ports liegt bei 38.400 bps. Die Option crtscts aktiviert den Hardware-Handshake für diesen Port, was bei Geschwindigkeiten über 9.600 bps ein absolutes Muss ist.

Nachdem pppd gestartet wurde, vereinbart es zuerst mit Hilfe von LCP verschiedene Verbindungseigenschaften mit der Gegenstelle. Normalerweise funktionieren die Standardoptionen, die pppd auszuhandeln versucht, auf Anhieb, weshalb wir an dieser Stelle nicht weiter darauf eingehen. Sie müssen allerdings damit rechnen, dass beim Verbindungsaufbau nach den IP-Adressen der beteiligten Seiten gefragt wird.

Im Moment gehen wir davon aus, dass c3po von uns keine Authentifizierung erwartet, so dass die Konfigurationsphase an dieser Stelle erfolgreich abgeschlossen ist.

pppd vereinbart dann mit Hilfe von IPCP, dem IP-Kontrollprotokoll, die IP-Parameter mit seinem Gegenüber. Weil wir auf der Kommandozeile keine bestimmte IP-Adresse an pppd übergeben haben, wird es versuchen, die Adresse zu verwenden, die der Resolver für den lokalen Hostnamen ermittelt hat. Beide geben sich dann ihre Adressen gegenseitig bekannt.

Normalerweise gibt es mit diesen Voreinstellungen keine Schwierigkeiten. Selbst wenn Ihr Rechner an einem Ethernet hängt, können Sie dieselbe IP-Adresse sowohl für das Ethernet als auch für die PPP-Schnittstelle benutzen. Trotzdem ermöglicht Ihnen pppd, eine andere Adresse zu benutzen. Sie können sogar die Gegenstelle auffordern, eine bestimmte Adresse zu verwenden. Diese Optionen werden alle im Abschnitt »IP-Adressen auswählen« behandelt.

Nachdem pppd die IPCP-Setup-Phase hinter sich gebracht hat, bereitet es die Netzwerkschicht Ihres Hosts für die Verwendung der PPP-Verbindung vor. Zuerst konfiguriert es die PPP-Netzwerkschnittstelle als Point-to-Point-Verbindung. Dabei verwendet es ppp0 für die erste aktive PPP-Verbindung, ppp1 für die zweite und so weiter. Danach richtet es einen Eintrag in der Routing-Tabelle ein, der auf den Host am anderen Ende der Verbindung zeigt. In unserem obigen Beispiel lässt pppd die Standard-Netzwerk-Route auf c3po zeigen, weil wir die Option defaultroute verwendet haben.2 Die Standard-Route vereinfacht Ihr Routing, indem alle IP-Datagramme, die nicht an lokale Hosts gerichtet sind, an c3po gesendet werden. Dieses Vorgehen ist sinnvoll, da es der einzige Weg ist, über den externe Hosts erreicht werden können. pppd unterstützt eine Reihe unterschiedlicher Routing-Schemata, auf die wir später in diesem Kapitel noch eingehen werden.

Arbeiten mit Optionsdateien

Bevor pppd seine Kommandozeilenargumente bearbeitet, durchsucht es verschiedene Dateien nach Standardoptionen. Diese Dateien dürfen beliebige gültige Kommandozeilenargumente enthalten, die auch über mehrere Zeilen verteilt sein können. Kommentare werden dabei durch Hash-Zeichen (#) eingeleitet.

Die erste Optionsdatei ist /etc/ppp/options, die immer durchsucht wird, während pppd startet. Sie sollten diese Datei für allgemeine Standardeinstellungen verwenden, weil Sie auf diese Weise verhindern, dass Benutzer verschiedene Dinge tun, die sich negativ auf die Systemsicherheit auswirken. Damit pppd beispielsweise irgendeine Form der Authentifizierung (PAP oder CHAP) von der Gegenseite erwartet, könnten Sie die Option auth in diese Datei aufnehmen. Diese Option kann von einem Benutzer nicht überschrieben werden, d. h., PPP kann keine Verbindung zu einem System aufbauen, das nicht in Ihrer Authentifizierungsdatei steht. Beachten Sie, dass einige andere Optionen durchaus überschrieben werden können; die Option connect ist dafür ein gutes Beispiel.

Nach /etc/ppp/options wird die Optionsdatei .ppprc im Home-Verzeichnis des Benutzers gelesen. Sie ermöglicht jedem Benutzer die individuelle Einstellung von Standardoptionen.

Die Datei /etc/ppp/options könnte beispielsweise folgendermaßen aussehen:

# Globale Optionen für pppd auf vlager.vbrew.com
lock # verwende UUCP-konforme Sperrung von Gerätedateien
auth # Authentifizierung notwendig
usehostname # verwende lokalen Hostnamen für CHAP
domain vbrew.com # unser Domainname

Wegen des Schlüsselworts lock verwendet pppd die UUCP-Standardmethode zum Sperren der Gerätedateien. Nach dieser Konvention erzeugt jeder Prozess, der auf eine serielle Schnittstelle, beispielsweise /dev/ttyS3, zugreift, eine Sperrdatei namens LCK..ttyS3 in einem speziellen Verzeichnis, um zu signalisieren, dass dieses Gerät gerade benutzt wird. Ein solches Vorgehen ist notwendig, um sicherzustellen, dass andere Programme wie minicom oder uucico nicht auf das Gerät zugreifen, solange es von PPP verwendet wird.

Die nächsten drei Optionen betreffen die Authentifizierung und damit die Systemsicherheit. Die Authentifizierungsoptionen werden am besten in der globalen Konfigurationsdatei festgelegt, da sie »privilegiert« sind und nicht von den Optionen in der Benutzerdatei ~/.ppprc überschrieben werden können.

Anwählen mit chat

Eine Sache, die Sie in unserem obigen Beispiel vielleicht als unbequem betrachten könnten, ist, dass Sie die Verbindung zuerst manuell aufbauen müssen, bevor Sie pppd starten können. pppd ist von einem externen Programm oder Shell-Skript abhängig, das diese Aufgabe übernimmt. Der entsprechende Befehl kann pppd mit der Kommandozeilenoption connect übergeben werden. pppd leitet die Standardein- und -ausgabe des Befehls dann an die serielle Leitung um.

Das Softwarepaket von pppd enthält ein sehr einfaches Programm namens chat, mit dem Sie einfache Login-Sequenzen auf die eben beschriebene Weise automatisieren können. Damit beschäftigen wir uns später noch etwas ausführlicher.

Wenn Ihre Login-Sequenz komplex ist, brauchen Sie etwas Besseres als chat. Eine sehr interessante Alternative ist expect, das von Don Libes geschrieben wurde. Es hat eine sehr mächtige Tcl-basierte Programmiersprache und wurde genau für diese Zwecke entworfen. All diejenigen unter Ihnen, deren Login-Vorgang z. B. eine Frage/Antwort-(Challenge/Response-)Authentifizierung erfordert, bei der rechenintensive Schlüsselgeneratoren zum Einsatz kommen, werden feststellen, dass expect dieser Aufgabe gewachsen ist. Nun gibt es aber dabei so viele verschiedene Varianten, dass wir in diesem Buch nicht darauf eingehen, wie man so ein Skript schreibt. Eigentlich brauchen Sie nur zu wissen, wie man ein expect-Skript startet, nämlich durch Angabe seines Namens zusammen mit der connect-Option von pppd. Sie sollten dabei beachten, dass die Standardeingabe und -ausgabe auf das Modem umgelenkt werden, solange das Skript läuft, und nicht etwa auf das Terminal, auf dem der pppd-Dämon gestartet wurde. Wenn Sie in dieser Zeit Benutzeraktivitäten gestatten wollen, müssen Sie auf ein freies virtuelles Terminal umschalten oder andere Möglichkeiten bereitstellen.

Mit dem Befehl chat können Sie chat-Skripten ausführen. Grundsätzlich besteht ein chat-Skript aus einer abwechselnden Folge von Strings, die wir vom entfernten System erwarten, sowie den Antworten, die auf diese Strings übertragen werden sollen. Wir nennen sie expect-Strings (die zu erwartenden Strings) und send-Strings (die zu sendenden Strings). Nachfolgend ein typischer Ausschnitt aus einem chat-Skript:

ogin: b1ff ssword: s3|<r1t

Dieses Skript weist chat an, darauf zu warten, bis die andere Seite den Login-Prompt gesendet hat, und dann den Login-Namen b1ff zurückzuschicken. Wir warten nur auf ogin:, so dass es keine Rolle spielt, ob der Login-Prompt mit einem großen oder kleinen »l« oder sonstwas beginnt. Der folgende String ist eine weitere Zeichenfolge, auf die chat warten soll. Sobald sie eingeht, wird unser Kennwort als Antwort übertragen.

Das ist im Grunde schon alles, was es zu chat-Skripten zu sagen gibt. Ein vollständiges Skript, mit dem Sie einen PPP-Server anwählen würden, müsste natürlich auch die entsprechenden Modembefehle enthalten. Nehmen wir einmal an, Ihr Modem versteht den Hayes-Befehlssatz und die Telefonnummer des Servers lautet 318714. Die vollständige Befehlszeile, mit der chat die Verbindung zu c3po aufbaut, wäre dann:

$ chat -v '' ATZ OK ATDT318714 CONNECT '' ogin: ppp word: GaGariN

Per Definition wird zuerst ein Expect-String erwartet, aber weil das Modem nichts sagen würde, wenn wir nicht ein wenig nachhelfen würden, veranlassen wir chat, den ersten Expect-String zu überspringen, indem wir einen leeren String angeben. Wir machen weiter und senden ATZ, den Reset-Befehl für Hayes-kompatible Modems, und warten auf die entsprechende Antwort (OK). Der nächste String sendet den Wählbefehl zusammen mit der gewünschten Telefonnummer an chat und erwartet die Nachricht CONNECT als Antwort. Dem folgt wieder ein leerer String, weil wir nun nichts mehr senden wollen, sondern nur noch auf den Login-Prompt warten. Der Rest des Skripts arbeitet, wie oben beschrieben. Diese Beschreibung ist vielleicht ein wenig verwirrend, wir werden aber in Kürze sehen, dass es einen Weg gibt, chat-Skripten leichter verständlich zu gestalten.

Mit der Option -v weisen Sie chat an, alle Aktivitäten über den local2-Kanal des syslog-Dämons zu protokollieren.3

Die Angabe des chat-Skripts auf der Kommandozeile birgt ein gewisses Risiko, weil Benutzer sich die Kommandozeilen laufender Prozesse mit dem ps-Befehl ansehen können. Sie können dieses Risiko vermeiden, indem Sie das Skript in einer Datei, z. B. dial-c3po, speichern. Mit der Option -f (gefolgt vom Dateinamen) können Sie chat dann anweisen, das Skript aus dieser Datei zu lesen. Dieses Verfahren hat zudem den Vorteil, dass es unsere chat-Expect-Sequenzen leichter verständlich macht. Auf unser Beispiel übertragen, würde unsere dial-c3po-Datei so aussehen:

'' ATZ
OK ATDT318714
CONNECT ''
ogin: ppp
word: GaGariN

In einem solchen chat-Skript stehen alle erwarteten Texte links und die darauf zu sendenden Antworten rechts davon. Es ist offensichtlich, dass chat-Skripten in dieser Form erheblich leichter zu verstehen sind.

Die vollständige pppd-Anweisung würde nun folgendermaßen aussehen:

# pppd connect "chat -f dial-c3po" /dev/ttyS3 38400 -detach \
crtscts modem defaultroute

Neben der Option connect, mit der das Skript bestimmt wird, haben wir noch zwei weitere Optionen in die Kommandozeile aufgenommen: zum einen -detach, mit der pppd angewiesen wird, sich nicht von der Konsole zu trennen und ein Hintergrundprozess zu werden, zum anderen modem, wodurch modemspezifische Aktionen auf dem seriellen Gerät durchgeführt werden, beispielsweise die Unterbrechung der Leitung vor und nach jedem Anruf. Wenn Sie diese Option nicht verwenden, überwacht pppd nicht die DCD-Leitung des Ports und kann dann nicht erkennen, wenn das Gegenüber unvermittelt die Verbindung unterbricht.

Die obigen Beispiele waren ziemlich einfach; mit chat können Sie jedoch auch wesentlich kompliziertere Skripten erstellen. Mit chat kann man beispielsweise einen String angeben, bei dem mit einer Fehlermeldung abgebrochen wird. Typische Strings sind Meldungen wie BUSY oder NO CARRIER, die normalerweise von Ihrem Modem erzeugt werden, wenn die gewählte Nummer besetzt ist oder nicht antwortet. Damit chat diese Nachrichten erkennt und nicht erst auf den Timeout wartet, können Sie sie zusammen mit dem Schlüsselwort ABORT an den Anfang Ihres Skripts stellen:

$ chat -v ABORT BUSY ABORT 'NO CARRIER' '' ATZ OK ...

Auf ähnliche Weise können Sie den Timeout-Wert für Teile des chat-Skripts ändern, indem Sie entsprechende TIMEOUT-Optionen einfügen.

Manchmal sollen auch Teile des Skripts nur ausgeführt werden, wenn eine bestimmte Bedingung erfüllt ist. Wenn Sie zum Beispiel den Login-Prompt vom anderen Ende nicht empfangen können, wollen Sie möglicherweise ein BREAK oder einen Wagenrücklauf übertragen, indem Sie ein Subskript an einen Expect-String anhängen. Dieses besteht - genau wie ein normales Skript - auch aus einer Reihe von Send- und Expect-Strings, die durch Bindestriche voneinander getrennt sind. Das Subskript wird immer dann ausgeführt, wenn der erwartete String, dem es anhängt, nicht innerhalb der vereinbarten Zeit eintrifft. Im obigen Beispiel würden Sie das Skript folgendermaßen modifizieren:

ogin:-BREAK-ogin: ppp ssword: GaGariN

Wenn chat nun vom entfernten System keinen Login-Prompt empfängt, wird das Subskript ausgeführt. Dabei wird zuerst ein BREAK übertragen, und danach wird erneut auf den Login-Prompt gewartet. Erscheint der Prompt jetzt, läuft das Skript weiter, als wäre nichts gewesen; ansonsten wird es mit einem Fehler abgebrochen.

IP-Konfigurationsoptionen

IPCP wird verwendet, um eine Reihe von IP-Parametern während der Verbindungsaufbauphase zu vereinbaren. Normalerweise sendet jede Seite ein Paket mit einer IPCP-Konfigurationsanforderung, die beschreibt, welche Werte von den Vorgaben abweichen und auf welchen Wert sie gesetzt werden sollen. Nach dem Empfang prüft jede Seite die entsprechenden Optionen und stimmt entweder zu oder weist sie zurück.

pppd gibt Ihnen die Kontrolle darüber, welche IPCP-Optionen es auszuhandeln versucht und welche nicht. Sie können das über verschiedene Kommandozeilenoptionen einstellen, die wir nachfolgend vorstellen.

IP-Adressen auswählen

Jede IP-Schnittstelle benötigt eine ihr zugewiesene IP-Adresse; auch ein PPP-Gerät hat somit eine IP-Adresse. Die diversen PPP-Protokolle bieten einen Mechanismus, der die automatische Zuweisung von IP-Adressen an PPP-Schnittstellen gestattet. Ein PPP-Programm an einem Ende einer Punkt-zu-Punkt-Verbindung kann der Gegenstelle eine IP-Adresse zuweisen, oder jede Seite kann ihre eigene IP-Adresse verwenden.

Einige PPP-Server, die viele Client-Sites verwalten müssen, weisen Adressen dynamisch zu. Adressen werden nur an Systeme vergeben, wenn ein Anruf erfolgt. Sobald die Verbindung wieder unterbrochen wird, werden die Adressen zurückverlangt. Dieses Verfahren limitiert die Anzahl der notwendigen IP-Adressen auf die Anzahl der Einwählleitungen. Während diese Begrenzung den Verwaltern der PPP-Einwähl-Server sehr entgegenkommt, ist das für die Anwender, die sich einwählen, häufig nicht der Fall. Wir hatten uns bereits in Kapitel 5 damit beschäftigt, wie unter Verwendung einer Datenbank Hostnamen an IP-Adressen zugeordnet werden. Damit jemand eine Verbindung zu Ihrem Rechner herstellen kann, muss er entweder Ihre IP-Adresse oder den entsprechenden Hostnamen kennen. Wenn Sie Benutzer eines PPP-Dienstes sind, der Ihnen eine IP-Adresse dynamisch zuweist, wird Ihnen die Kenntnis dieser Adresse kaum nützen, wenn es kein Mittel gibt, die DNS-Daten zu aktualisieren, nachdem Sie eine IP-Adresse zugewiesen bekommen haben. Zwar existieren Systeme, die das können, jedoch gehen wir hier nicht näher darauf ein. Stattdessen betrachten wir ein zu bevorzugendes Verfahren, bei dem Sie ein und dieselbe IP-Adresse beim Verbindungsaufbau immer wieder verwenden können.4

Im obigen Beispiel haben wir pppd das System c3po anwählen lassen und eine IP-Verbindung eingerichtet. Dabei wurden keinerlei Vorkehrungen getroffen, welche IP-Adressen an beiden Enden verwendet werden sollen. Stattdessen haben wir pppd seine vorgegebene Aktion ausführen lassen. Es versucht, den lokalen Hostnamen, in unserem Beispiel vlager, in eine IP-Adresse aufzulösen, die es dann auf der lokalen Seite verwendet. Die Maschine auf der Gegenseite, c3po, bringt ihre eigene IP-Adresse mit. PPP unterstützt mehrere Alternativen zu dieser Vorgehensweise.

Um bestimmte Adressen anzufordern, müssen Sie pppd mit folgender Option aufrufen:

local_addr:remote_addr

local_addr und remote_addr können dabei entweder in Dotted-Quad-Notation oder als Hostnamen angegeben werden.5 Diese Option bewirkt, dass pppd versucht, die erste angegebene IP-Adresse für die eigene Seite zu verwenden, während die zweite dem Gegenüber zugewiesen wird. Wenn die Gegenseite eine der Adressen während der IPCP-Vereinbarungsphase ablehnt, wird keine IP-Verbindung aufgebaut.6

Wenn Sie einen Server anwählen und erwarten, dass Sie von ihm eine dynamische IP-Adresse erhalten, müssen Sie darauf achten, dass Ihr pppd-Dämon keinen Versuch unternimmt, eine IP-Adresse für sich auszuhandeln. Dazu verwenden Sie die Option noipdefault und lassen local_addr leer. Die Option noipdefault verhindert, dass pppd versucht, die zum lokalen Hostnamen gehörende IP-Adresse zu verwenden.

Falls Sie nur die lokale Adresse verwenden wollen, aber bereit sind, die Remote-Adresse von der Gegenseite zu akzeptieren, lassen Sie einfach den remote_addr-Teil leer. Um zum Beispiel vlager dazu zu bringen, die Adresse 130.83.4.27 anstelle seiner eigenen zu benutzen, fügen Sie der Kommandozeile die Option 130.83.4.27: hinzu. Für den umgekehrten Weg, nämlich die Remote-Adresse fest vorzugeben und die lokale Adresse dynamisch auszuhandeln, lassen Sie das Feld local_addr leer. pppd benutzt dann standardmäßig die IP-Adresse Ihres Hostnamens.

Routen über eine PPP-Verbindung

Nachdem die Netzwerkschnittstelle eingerichtet ist, setzt pppd nur eine Hostroute zur Gegenseite. Wenn sich der entfernte Host in einem LAN befindet, wollen Sie möglicherweise auch in der Lage sein, mit Hosts »hinter« diesem Punkt zu kommunizieren. In diesem Fall muss eine Netzwerkroute eingerichtet werden.

Sie haben bereits gesehen, dass Sie pppd mit der Option defaultroute anweisen können, die Standard-Route einzurichten. Diese Option ist sehr nützlich, wenn der von Ihnen angewählte PPP-Server als Internet-Gateway fungiert.

Der entgegengesetzte Fall, bei dem Ihr System als Gateway für einen einzelnen Host fungiert, ist relativ einfach herzustellen. Nehmen wir zum Beispiel einen Angestellten der virtuellen Brauerei, dessen zu Hause stehende Maschine oneshot heißt. Nehmen wir weiterhin an, dass wir vlager als PPP-Einwählknoten konfiguriert haben. Wenn wir vlager dabei so eingerichtet haben, dass er dynamisch eine IP-Adresse des Brauerei-Subnetzes vergibt, können wir pppd mit der Option proxyarp aufrufen, was einen so genannten Proxy-ARP-Eintrag für oneshot installiert (Proxy bedeutet so viel wie Vollmacht). Auf diese Weise wird oneshot automatisch für alle Hosts in der Brauerei und Weinkellerei zugänglich gemacht.

Leider sind die Dinge nicht immer so einfach. So wird zum Beispiel bei der Verbindung zweier lokaler Netzwerke zusätzlich eine bestimmte Netzwerk-Route benötigt, weil beide Netzwerke ihre eigenen Standard-Routen haben könnten. Würden beide Seiten die PPP-Verbindung als Standard-Route verwenden, würde das außerdem eine Schleife erzeugen, bei der Pakete mit unbekanntem Ziel so lange hin und her transportiert werden, bis deren Time-to-live überschritten wäre.

Nehmen wir einmal an, dass die virtuelle Brauerei eine Zweigstelle in einer anderen Stadt eröffnet. Dort wird ein eigenes Ethernet mit der IP-Netzwerknummer 172.16.3.0 betrieben, das als Subnetz 3 im Klasse-B-Netzwerk der Brauerei geführt wird. Die Filiale möchte sich über PPP an das Hauptnetz der Brauerei anschließen, um Kundendaten zu aktualisieren usw. Erneut dient vlager als Gateway für das Brauerei-Netzwerk und bietet PPP-Dienste. Seine Gegenstelle im neuen Zweig verwendet den Namen vbourbon und hat die IP-Adresse 172.16.3.1.

Sobald vbourbon die Verbindung zu vlager herstellt, legt es wie gewöhnlich eine Standard-Route an, die auf vlager zeigt. Auf vlager haben wir jedoch nur die Punkt-zu-Punkt-Route zu vbourbon und müssen daher eine gesonderte Netzwerkroute für Subnetz 3 einrichten, die vbourbon als Gateway benutzt. Das könnten wir von Hand mit dem Befehl route erledigen, wenn die PPP-Verbindung aufgebaut ist. Allerdings ist das keine besonders praktische Lösung. Zum Glück können wir aber die Route automatisch konfigurieren, indem wir auf eine Funktion von pppd zurückgreifen, die wir bisher noch nicht besprochen haben - den ip-up-Befehl. Dabei handelt es sich um ein Shell-Skript oder Programm im Verzeichnis /etc/ppp, das von pppd ausgeführt wird, nachdem die PPP-Schnittstelle konfiguriert wurde. Falls vorhanden, wird es mit den folgenden Parametern aufgerufen:

ip-up iface device speed local_addr remote_addr

Tabelle 6-1 enthält eine Übersicht über die Bedeutung der Argumente.

Tabelle 6-1
 ip-up-Argumente
Name
Zweck
iface
Die verwendete Netzwerkschnittstelle, z. B. ppp0
device
Der Pfadname der Gerätedatei des verwendeten seriellen Geräts (/dev/tty, wenn stdin/stdout benutzt wird)
speed
Die Übertragungsgeschwindigkeit des seriellen Geräts in Bits pro Sekunde
local_addr
Die IP-Adresse der lokalen Seite der Verbindung in Dotted-Quad-Notation
remote_addr
Die IP-Adresse der Gegenstelle der Verbindung in Dotted-Quad-Notation

In unserem Fall kann das ip-up-Skript folgendes Codefragment enthalten:7

#!/bin/sh
case $5 in
172.16.3.1) # this is vbourbon
route add -net 172.16.3.0 gw 172.16.3.1;;
...
esac
exit 0

Ähnlich wird /etc/ppp/ip-down dazu verwendet, um alle Aktionen von ip-up wieder rückgängig zu machen, nachdem die PPP-Verbindung wieder unterbrochen wurde. Dafür könnten wir in unserem /etc/ppp/ip-down-Skript einen route-Befehl angeben, der die Route, die wir im /etc/ppp/ip-up-Skript erzeugt haben, wieder entfernt.

Das Routing-Schema ist jedoch noch nicht vollständig. Wir haben zwar Einträge in die Routing-Tabellen der beiden Hosts aufgenommen, aber bis jetzt wissen die Hosts in beiden Netzwerken noch nichts über die PPP-Verbindung. Das ist kein Problem, wenn alle Hosts in der Zweigstelle die Standard-Route auf vbourbon zeigen lassen und alle Hosts der Brauerei standardmäßig auf vlager routen.

Link-Kontrolloptionen

LCP, das Link Control Protocol, haben wir ja bereits vorgestellt. Es wird benutzt, um die Charakteristika einer Verbindung zu vereinbaren und die Verbindung zu testen.

Die beiden wichtigsten von LCP zu vereinbarenden Optionen sind die Asynchronous Control Character Map und die Maximum Receive Unit. Es gibt noch eine ganze Reihe weiterer LCP-Konfigurationsoptionen, die aber bei weitem zu speziell sind, als dass wir sie hier besprechen könnten.

Die Asynchronous Control Character Map, allgemein Async-Map genannt, wird bei asynchronen Verbindungen wie beispielsweise Telefonleitungen verwendet, um Steuerzeichen zu erkennen, die durch eine Zwei-Zeichen-Sequenz (Escape-Sequenz) ersetzt werden müssen. Dadurch wird verhindert, dass die für den Verbindungsaufbau zuständigen Geräte die Steuerzeichen fälschlicherweise selbst interpretieren. Beispielsweise möchten Sie die beim Software-Handshake verwendeten Zeichen XON und XOFF umgehen, weil einige fehlerhaft konfigurierte Modems sich beim Empfang von XOFF verabschieden. Ein weiterer Kandidat ist Strg-] (das telnet-Escape-Zeichen). PPP ermöglicht Ihnen, solche Zeichen mit den ASCII-Codes 0 bis 31 besonders zu kennzeichnen, indem Sie sie in die Async-Map aufnehmen.

Die Async-Map ist eine 32 Bit breite, hexadezimal geschriebene Bitmap, bei der das niederwertigste Bit dem ASCII-Zeichen NULL und das höchstwertige Bit dem ASCII-Wert 31 entspricht. Diese 32 ASCII-Zeichen sind die Steuerzeichen. Ist ein Bit in der Bitmap gesetzt, bedeutet dies, dass das entsprechende Zeichen erst umgewandelt werden muss, bevor es über die Verbindung transportiert werden kann.

Um Ihrer Seite mitzuteilen, dass nicht alle, sondern nur wenige Steuerzeichen umgewandelt werden müssen, können Sie pppd mit der Option asyncmap eine neue Async-Map übergeben. Wenn beispielsweise nur die Steuerzeichen ^S und ^Q (ASCII 17 und 19 werden häufig als XON und XOFF verwendet) umgewandelt werden müssen, können Sie die folgende Option benutzen:

asyncmap 0x000A0000

Die Konvertierung ist einfach, solange Sie binäre in hexadezimale Werte umwandeln können. Stellen Sie sich eine beliebige 32-Bit-Kette vor. Das Bit ganz rechts entspricht ASCII 00 (NULL), das Bit ganz links dem ASCII-Dezimalwert 32. Setzen Sie einfach diejenigen Bits auf eins, die den ASCII-Zeichen entsprechen, die Sie konvertieren wollen, und alle anderen Bits auf null. Um diese Bit-Kette dem Befehl pppd in Form einer Hexadezimalzahl zu übergeben, bilden Sie einfach Vierergruppen der 32-Bit-Zahl und konvertieren Sie diese jeweils in eine Hexadezimalziffer. Sie erhalten schließlich eine Folge aus acht Hexadezimalzeichen. Schreiben Sie sie hintereinander auf, und stellen Sie dieser Zahl ein »0x« voran. Das war's.

Am Anfang ist die Async-Map auf 0xffffffff gesetzt, so dass alle Steuerzeichen durch Escape-Sequenzen ersetzt werden. Das ist eine sichere Grundeinstellung, aber viel mehr, als Sie vielleicht wollen. Jedes Zeichen, das in der Async-Map vorkommt, wird als Folge von zwei Zeichen über die Verbindung übertragen. Das geht natürlich zu Lasten der Leistung, weshalb sich eine geringere Performance ergibt.

Für die meisten Anwendungsfälle reicht eine Async-Map von 0x0 völlig aus. Es werden dann überhaupt keine Escape-Sequenzen erzeugt.

Mit der Maximum Receive Unit (MRU) signalisieren wir die maximale Größe eines HDLC-Frames, den wir zu empfangen bereit sind. Obwohl Sie das an den MTU-Wert (Maximum Transfer Unit) erinnern könnte, haben diese beiden doch sehr wenig gemeinsam. Die MTU ist ein Parameter der Kernel-Netzwerkeinheit und beschreibt die maximale Größe, die die Schnittstelle verarbeiten kann. Die MRU ist eher eine Empfehlung an die andere Seite, keine Frames zu generieren, die länger als die MRU sind. Die Schnittstelle muss aber dennoch in der Lage sein, Frames mit einer Größe von bis zu 1.500 Byte zu empfangen.

Die Wahl einer MRU ist daher also nicht so sehr eine Frage dessen, was eine Verbindung zu übertragen in der Lage ist, sondern eher, wie der beste Durchsatz erzielt werden kann. Wenn Sie mit interaktiven Anwendungen arbeiten wollen, sollten Sie die MRU auf einen so niedrigen Wert wie 296 setzen, damit gelegentliche größere Pakete (sagen wir von einer FTP-Sitzung) Ihren Cursor nicht zum »Ruckeln« bringen. Sie weisen pppd an, eine MRU von 296 zu verwenden, indem Sie die Option mru 296 auf der Kommandozeile übergeben. Kleine MRUs sind jedoch nur sinnvoll, wenn die VJ-Header-Komprimierung zur Verfügung steht (sie ist per Standardeinstellung aktiviert), da Sie ansonsten viel Bandbreite darauf verschwenden, nur um die IP-Header aller Datagramme zu übertragen.

pppd versteht auch eine ganze Reihe von LCP-Optionen, mit denen Sie das gesamte Verhalten der Verhandlungsphase konfigurieren können, wozu beispielsweise die maximale Anzahl von Konfigurationsanforderungen gehört, die ausgetauscht werden können, bevor die Verbindung beendet wird. Solange Sie nicht genau wissen, was Sie da tun, sollten Sie aber die Finger von diesen Optionen lassen.

Schließlich gibt es noch zwei Optionen, die sich mit LCP-Echo-Nachrichten beschäftigen. PPP definiert zwei besondere Nachrichten: Echo Request und Echo Response. pppd verwendet sie, um zu prüfen, ob die Verbindung noch funktioniert. Sie aktivieren diese Optionen durch lcp-echo-interval und die Angabe einer Zeit in Sekunden. Werden vom entfernten Host innerhalb dieser Zeitspanne keine Frames empfangen, erzeugt pppd einen Echo Request und erwartet, dass die Gegenseite mit einer Echo Response antwortet. Kommt von der Gegenstelle keine Antwort, wird die Verbindung nach einer bestimmten Anzahl von Versuchen unterbrochen. Diese Anzahl können Sie mit der Option lcp-echo-failure bestimmen. Per Voreinstellung ist diese Funktion deaktiviert.

Allgemeine Sicherheitsaspekte

Ein fehlerhaft konfigurierter PPP-Dämon kann eine vernichtende Sicherheitslücke darstellen. Im schlimmsten Fall sieht es so aus, dass sich jeder direkt an Ihr Ethernet anschließen kann (und das ist sehr schlecht). In diesem Abschnitt wollen wir einige Maßnahmen erläutern, die Ihre PPP-Konfiguration sicher machen sollen.


Zur Konfiguration der Netzwerkschnittstelle und der Routing-Tabelle sind Root-Berechtigungen erforderlich. Normalerweise lösen Sie dieses Problem, indem Sie pppd mit setuid root ausführen. Allerdings erlaubt pppd Benutzern, verschiedene sicherheitsrelevante Optionen zu setzen.

Um sich vor Angriffen zu schützen, die ein Benutzer durch Manipulation von pppd-Optionen starten könnte, wird empfohlen, eine Reihe von Voreinstellungen in der globalen Datei /etc/ppp/options einzutragen. Ein Beispiel dafür finden Sie im Abschnitt »Arbeiten mit Optionsdateien« in diesem Kapitel. Einige dieser Optionen, wie die zur Authentifizierung, können dann vom Benutzer nicht überschrieben werden, was eine vernünftige Sicherung gegen Manipulationen darstellt. Eine wichtige Schutzoption ist connect. Falls Sie beabsichtigen, Nicht-Root-Benutzern die Ausführung von pppd zu gestatten, um eine Internetverbindung zu etablieren, sollten Sie immer die Optionen connect und noauth in der globalen Datei /etc/ppp/options eintragen. Wenn Sie das nicht machen, können die Anwender beliebige Befehle mit root-Privilegien ausführen, indem sie sie als connect-Befehl in der pppd-Zeile oder in ihrer persönlichen Optionsdatei angeben.

Sie sollten auch den Kreis der Benutzer, die pppd ausführen dürfen, einschränken. Dazu erzeugen Sie in /etc/group eine neue Gruppe und tragen darin nur diejenigen Benutzer ein, denen Sie die Ausführung des PPP-Dämons gestatten wollen. Sie sollten dann die Eigentumsrechte des pppd-Dämons auf diese Gruppe einstellen und die Ausführungsrechte für die ganze Welt entfernen. Angenommen, Ihre Gruppe heißt dialout, dann könnten Sie folgendermaßen vorgehen:

# chown root /usr/sbin/pppd
# chgrp dialout /usr/sbin/pppd
# chmod 4750 /usr/sbin/pppd

Natürlich müssen Sie sich auch selbst vor den Systemen schützen, mit denen Sie über PPP kommunizieren. Um zu verhindern, dass sich Hosts als jemand anderes ausgeben, sollten Sie immer irgendeine Form der Authentifizierung von der Gegenseite verlangen. Darüber hinaus sollten Sie es fremden Hosts nicht erlauben, eine beliebige, von ihnen gewählte IP-Adresse zu verwenden, sondern sie auf ein paar wenige beschränken. Der folgende Abschnitt befasst sich ausführlich mit diesen Themen.

Authentifizierung mit PPP

Mit PPP kann jedes System seine Gegenseite auffordern, sich zu authentifizieren. Dazu kann eines von zwei Authentifizierungsprotokollen verwendet werden. Das ist zum einen das Password Authentication Protocol (PAP) und zum anderen das Challenge Handshake Authentication Protocol (CHAP). Sobald eine Verbindung steht, kann jede Seite die andere auffordern, sich zu authentifizieren, gleichgültig, ob sie die rufende oder die angerufene Seite ist. Im Folgenden reden wir von »Client« und »Server«, um zwischen dem sich authentifizierenden System und dem Authentifizierer zu unterscheiden. Ein PPP-Dämon kann von seinem Gegenüber die Authentifizierung anfordern, indem er einfach eine weitere LCP-Konfigurationsanforderung sendet, die das gewünschte Authentifizierungsprotokoll angibt.

Vergleich von PAP und CHAP

Das von vielen Internet-Service-Providern angebotene PAP arbeitet grundsätzlich auf dieselbe Weise wie die normale Login-Prozedur. Der Client authentifiziert sich, indem er einen Benutzernamen und ein (optional verschlüsseltes) Kennwort an den Server schickt, die der Server dann beide mit seiner Secrets-Datenbank vergleicht. Diese Technik ist anfällig für Lauscher, die an der seriellen Leitung horchen. Auch Angriffe nach dem Trial-and-Error-Verfahren sind hier möglich.

CHAP weist diese Defizite nicht auf. Bei CHAP sendet der Authentifizierer (d. h. der Server) einen zufällig erzeugten »Anforderungsstring« (eine »Challenge«) zusammen mit seinem Hostnamen an den Client. Der Client verwendet den Hostnamen, um das entsprechende »Secret« nachzusehen, kombiniert es mit der Anforderung und verschlüsselt den String mit Hilfe einer Einweg-Hash-Funktion. Das Ergebnis wird zusammen mit dem Hostnamen des Client an den Server zurückgeschickt. Der Server führt nun dieselbe Berechnung durch und akzeptiert den Client, wenn er zu demselben Ergebnis kommt.

Eine weitere Eigenschaft von CHAP besteht darin, dass es die Authentifizierung durch den Client nicht nur beim Start abfragt, sondern solche Anforderungen in regelmäßigen Zeitabständen sendet, um sicherzustellen, dass der Client nicht durch einen Eindringling ersetzt wurde, der beispielsweise nur die Telefonleitung umgeschaltet hat, oder dass nicht ein Modem-Konfigurationsfehler vorliegt, wodurch der PPP-Dämon nicht mitbekommt, dass die bestehende Verbindung abgebrochen wurde und sich inzwischen ein anderer Benutzer eingewählt hat.

pppd speichert die geheimen Schlüssel für PAP und CHAP in zwei separaten Dateien namens /etc/ppp/pap-secrets und /etc/ppp/chap-secrets. Durch Eintragen eines entfernten Hosts in die eine oder andere Datei können Sie genau bestimmen, ob CHAP oder PAP bei der Authentifizierung verwendet wird.

pppd ist so voreingestellt, dass es von der Gegenseite keine Authentifizierung benötigt; fordert die Gegenstelle eine Authentifizierung an, wird diese aber durchgeführt. Weil CHAP wesentlich strenger ist als PAP, versucht pppd, wann immer möglich, auf das erste Verfahren zurückzugreifen. Wird das von der Gegenseite nicht unterstützt oder kann pppd kein CHAP-Secret für den anderen Rechner in seiner chap-secrets-Datei finden, wechselt es zu PAP. Wenn auch kein PAP-Secret für die andere Seite gefunden werden kann, wird die Authentifizierung vollständig abgebrochen und als Konsequenz daraus schließlich die ganze Verbindung unterbrochen.

Dieses Verhalten kann auf verschiedene Weise angepasst werden. Wird beispielsweise die Option auth verwendet, verlangt pppd von der Gegenseite eine Authentifizierung. pppd kann dabei entweder auf CHAP oder auf PAP zurückgreifen, solange das Secret der anderen Seite in der CHAP- oder PAP-Datenbank gefunden wird. Es gibt andere Optionen, mit denen auf ein bestimmtes Authentifizierungsprotokoll zurückgegriffen wird. Wir gehen an dieser Stelle aber nicht auf sie ein.

Wenn alle Systeme, mit denen Sie sich über PPP unterhalten, bereit sind, sich Ihnen gegenüber zu authentifizieren, sollten Sie die Option auth in die globale Datei /etc/ppp/options aufnehmen und Kennwörter für alle Systeme in die Datei chap-secrets eintragen. Wird CHAP von einem System nicht unterstützt, fügen Sie den Eintrag in die Datei pap-secrets ein. Auf diese Weise stellen Sie sicher, dass sich keine unautorisierten Systeme in Ihren Host einklinken.

Die nächsten zwei Abschnitte behandeln die beiden PPP-Secrets-Dateien pap-secrets und chap-secrets. Diese Dateien sind im Verzeichnis /etc/ppp zu finden und enthalten Dreiergruppen aus Clients, Servern und Kennwörtern, denen optional eine Liste mit IP-Adressen folgt. Die Interpretation der Client- und Serverfelder ist bei CHAP und PAP unterschiedlich und hängt auch davon ab, ob wir uns bei der Gegenseite ausweisen müssen oder ob wir den Server auffordern, sich bei uns zu authentifizieren.

Die CHAP-Secrets-Datei

Wenn pppd sich über CHAP einem Server gegenüber ausweisen muss, durchsucht es die Datei chap-secrets nach einem Eintrag, bei dem das Client-Feld mit dem lokalen Hostnamen und das Serverfeld mit dem Hostnamen des Servers übereinstimmt, der bei der CHAP-Anforderung übertragen wurde. Muss sich die Gegenseite authentifizieren, sind die Rollen vertauscht: pppd sucht dann nach einem Eintrag, bei dem das Client-Feld mit dem Hostnamen des entfernten Rechners (übertragen während der CHAP-Antwort des Client) und das Serverfeld mit dem lokalen Hostnamen übereinstimmt.

Nachfolgend ein einfaches Beispiel einer chap-secrets-Datei für vlager:8

# CHAP-Secrets für vlager.vbrew.com
#
# Client Server Secret Adressen
#---------------------------------------------------------------------
vlager.vbrew.com c3po.lucas.com "Use The Source Luke" vlager.vbrew.com
c3po.lucas.com vlager.vbrew.com "arttoo! arttoo!" c3po.lucas.com
* vlager.vbrew.com "TuXdrinksVicBitter" pub.vbrew.com

Wenn vlager eine PPP-Verbindung zu c3po aufbaut, fordert c3po vlager auf, sich zu authentifizieren, indem es eine CHAP-Anforderung überträgt. pppd auf vlager durchsucht dann chap-secrets nach einem Eintrag, bei dem das Client-Feld vlager.vbrew.com und das Serverfeld c3po.lucas.com enthält, und findet dabei die erste oben aufgeführte Zeile.9 Daraufhin wird eine CHAP-Antwort aus dem Anforderungsstring und dem Secret (Use The Source Luke) erzeugt und an c3po geschickt.

pppd baut ebenfalls eine CHAP-Anforderung für c3po auf, die einen eindeutigen Anforderungsstring und den voll qualifizierten Hostnamen vlager.vbrew.com enthält. c3po erzeugt die entsprechende CHAP-Antwort auf die oben beschriebene Art und Weise und gibt diese an vlager zurück. pppd filtert sich nun den Hostnamen des Clients (c3po.vbrew.com) aus der Antwort heraus und durchsucht die Datei chap-secrets nach einem Eintrag, bei dem c3po als Client und vlager als Server vorhanden sind. Das ist im zweiten Eintrag unserer Beispieldatei der Fall. pppd kombiniert die CHAP-Anforderung und das Secret arttoo! arttoo!, verschlüsselt sie und vergleicht das Ergebnis mit der CHAP-Antwort von c3po.

Das vierte Feld ist optional und enthält eine Liste der IP-Adressen, die für den im ersten Feld aufgeführten Client akzeptabel sind. Die Adressen können in Dotted-Quad-Notation oder als Hostnamen angegeben werden, die mit Hilfe des Resolvers aufgelöst werden. Wenn beispielsweise c3po eine bestimmte Adresse während der IPCP-Vereinbarung anfordert, die nicht in dieser Liste steht, wird diese Anforderung abgelehnt, und IPCP wird beendet. Bei unserer oben aufgeführten Beispieldatei kann c3po also nur seine eigene IP-Adresse verwenden. Ist das Adressfeld leer, ist jede Adresse erlaubt. Wird als Wert »-« eingetragen, wird IP für diesen Client gar nicht erst initialisiert.

Die dritte Zeile in unserer chap-secrets-Datei ermöglicht es jedem Host, eine PPP-Verbindung mit vlager aufzubauen, weil das Sternchen (*) als Platzhalter für jeden beliebigen Hostnamen steht. Die einzige Voraussetzung ist, dass er das Secret kennt und die Adresse von pub.vbrew.com verwendet. Einträge mit solchen Platzhaltern (Wildcards) können an jeder beliebigen Stelle in der Secrets-Datei stehen, weil pppd immer den Eintrag verwendet, der am ehesten zu einem Server/Client-Paar passt.

pppd benötigt möglicherweise bei der Bildung von Hostnamen etwas Hilfe. Wie bereits erwähnt, ist der Name des anderen Hosts immer im CHAP-Anforderungs- oder -Antwortpaket enthalten. Der lokale Hostname wird standardmäßig durch den Aufruf der Funktion gethostname(2) ermittelt. Wenn Sie den Systemnamen auf Ihren unqualifizierten Hostnamen gesetzt haben, müssen Sie pppd mit der Option domain zusätzlich noch den Domainnamen bekannt geben:

# pppd domain vbrew.com

Das hängt den Domainnamen der Brauerei bei allen authentifizierungsbezogenen Aktivitäten an vlager an. Andere Optionen, mit denen Sie den lokalen Hostnamen für pppd anpassen können, sind usehostname und name. Wenn Sie die lokale IP-Adresse mit Hilfe von local:remote auf der Kommandozeile angeben und local einen Namen anstelle einer Dotted-Quad enthält, nutzt pppd diesen als lokalen Hostnamen.

Die PAP-Secrets-Datei

Die Secrets-Datei für PAP ist derjenigen von CHAP sehr ähnlich. Die ersten beiden Felder enthalten einen Benutzer- und einen Servernamen. Das dritte Feld enthält das PAP-Secret. Fordert die Gegenseite die Authentifizierung an, verwendet pppd den Eintrag, bei dem das Serverfeld mit dem lokalen Hostnamen und das Benutzerfeld mit dem in der Anforderung übertragenen Benutzernamen übereinstimmt. Wenn es sich selbst authentifizieren muss, wählt pppd das Secret aus dem Eintrag aus, das ein Feld mit dem lokalen Benutzernamen und ein Serverfeld mit dem Namen des entfernten Hosts enthält.

Eine PAP-Secrets-Datei könnte beispielsweise so aussehen:

# /etc/ppp/pap-secrets
#
# Benutzer Server Secret Adressen
vlager-pap c3po cresspahl vlager.vbrew.com
c3po vlager DonaldGNUth c3po.lucas.com

Die erste Zeile wird von uns zur Authentifizierung verwendet, wenn wir mit c3po kommunizieren. Die zweite Zeile beschreibt, wie ein Benutzer namens c3po sich uns gegenüber zu authentifizieren hat.

Der Name vlager-pap in der ersten Spalte ist der Benutzername, den wir an c3po senden. Per Voreinstellung wählt pppd den lokalen Hostnamen als Benutzernamen. Sie können aber auch einen anderen Namen bestimmen, indem Sie ihn mit der Option user übergeben.

Wenn ein Eintrag aus der Datei pap-secrets herausgesucht werden soll, um die Authentifizierung mit der Gegenseite durchzuführen, muss pppd den Namen des anderen Hosts kennen. Weil es keine Möglichkeit hat, ihn herauszufinden, müssen Sie ihn mit Hilfe der Option remotename auf der Kommandozeile mit angeben. Soll beispielsweise der obige Eintrag für die Authentifizierung mit c3po verwendet werden, müssen wir dem pppd-Befehl folgende Option hinzufügen:

# pppd ... remotename c3po user vlager-pap

Im vierten Feld (und in allen folgenden Feldern) der PAP-Secrets-Datei können Sie, genau wie bei der CHAP-Secrets-Datei auch, die IP-Adressen angeben, die für einen bestimmten Host erlaubt sind. Die Gegenstelle darf dann nur Adressen aus dieser Liste anfordern. In der Beispieldatei weist der Eintrag, den c3po für die Einwahl benutzt - die Zeile, in der c3po der Client ist -, ihn an, nur seine eigene IP-Adresse und keine andere zu benutzen.

Denken Sie daran, dass PAP eine eher schwache Authentifizierungsmethode ist und dass Sie, wenn möglich, immer auf CHAP zurückgreifen sollten. Aus diesem Grund gehen wir hier nicht detaillierter auf PAP ein. Wenn Sie mehr über PAP erfahren wollen, finden Sie weitere Informationen in der pppd(8)-Manpage.

Debugging Ihrer PPP-Konfiguration

Standardmäßig reicht pppd Warnungen und Fehlermeldungen immer an den daemon-Kanal von syslog weiter. Um diese Informationen in eine Datei oder auf eine Konsole umzuleiten, müssen Sie einen Eintrag in der Datei syslog.conf hinzufügen. Andernfalls verwirft syslog sie einfach. Der folgende Eintrag führt zur Umleitung aller Nachrichten in die Datei /var/log/ppp-log:

daemon.* /var/log/ppp-log

Wann immer Ihre PPP-Konfiguration nicht richtig funktioniert, sollten Sie einen Blick in diese Protokolldatei werfen. Wenn Ihnen die Protokollmeldungen nicht weiterhelfen, erhalten Sie weitere Debugging-Ausgaben durch die Option debug. In diesem Fall sorgt pppd dafür, dass der Inhalt sämtlicher Kontrollpakete durch syslog protokolliert wird. Alle Nachrichten werden dann an den daemon-Kanal weitergeleitet.

Schließlich gibt es für die Problemanalyse noch eine besonders drastische Methode, nämlich die Aktivierung von Debugging-Meldungen vom Kernel. Dazu geben Sie für pppd die Option kdebug an, gefolgt von einer Zahl, die die Summe folgender Werte ist: 1 für allgemeine Debugging-Meldungen, 2 zur Ausgabe aller eingehenden HDLC-Frames und 4 für die Ausgabe aller ausgehenden HDLC-Frames. Um die Kernel-Debugging-Meldungen abzufangen, starten Sie entweder einen syslogd-Dämon, der die Datei /proc/kmsg ausliest, oder den klogd-Dämon. Beide leiten die Debugging-Meldungen des Kernels an den syslog-Kernel-Kanal weiter.

Erweiterte PPP-Konfigurationen

Zwar ist die Konfiguration von PPP zur Einwahl in Netzwerke wie das Internet die wohl häufigste Anwendung, es gibt jedoch auch Benutzer, die weiter reichende Anforderungen haben. In diesem Abschnitt behandeln wir einige dieser erweiterten Konfigurationen, die mit PPP unter Linux möglich sind.

PPP-Server

Bei der Ausführung von pppd als Server steht man eigentlich nur vor der Aufgabe, ein serielles tty-Gerät so zu konfigurieren, dass es pppd mit angemessenen Optionen startet, sobald eine eingehende Datenabfrage vorliegt. Eine Möglichkeit dazu besteht in der Einrichtung eines speziellen Zugangs, z.B. ppp, dem ein Skript oder ein Programm als Login-Shell zugeordnet wird, das pppd mit diesen Optionen aufruft. Wenn Sie die Unterstützung von PAP oder CHAP beabsichtigen, können Sie alternativ das Programm mgetty verwenden, um Ihr Modem zu unterstützen und dessen »/AutoPPP/«-Funktionalität zu nutzen.

Um einen Server aufzubauen, der die Login-Methode verwendet, fügen Sie etwa folgende Zeile in Ihre /etc/passwd-Datei ein:10

ppp:x:500:200:Public PPP Account:/tmp:/etc/ppp/ppplogin

Unterstützt Ihr System Shadow-Passwörter, müssen Sie auch einen Eintrag in die /etc/shadow-Datei vornehmen:

ppp:!:10913:0:99999:7:::

Natürlich hängen die verwendete UID und GID vom Benutzer ab, der Eigentümer einer Verbindung sein soll, und davon, wie Sie ihn angelegt haben. Außerdem müssen Sie mit dem Befehl passwd noch das entsprechende Kennwort für diesen Zugang zuweisen.

Das ppplogin-Skript könnte so aussehen:

#!/bin/sh
# ppplogin - Skript zum Start von pppd beim Login
mesg n
stty -echo
exec pppd -detach silent modem crtscts

Der Befehl mesg verhindert, dass andere Benutzer an den tty schreiben können (beispielsweise mit write). Der Befehl stty schaltet das Echo aus. Das ist notwendig, weil sonst alle von der Gegenseite übertragenen Daten noch einmal zurückgeschickt würden. Die wichtigste der oben angegebenen pppd-Optionen ist -detach, weil sie verhindert, dass sich pppd vom kontrollierenden tty abtrennt. Wenn Sie diese Option nicht angeben, würde es in den Hintergrund treten und das Shell-Skript beenden. Das würde wiederum dazu führen, dass die serielle Leitung abgebaut würde und somit die Verbindung beendet wäre. Mit der silent-Option weisen Sie pppd an zu warten, bis ein Paket vom anrufenden System empfangen wurde, bevor es mit dem Senden beginnt. Auf diese Weise werden Übertragungs-Timeouts verhindert, die auftreten können, wenn das anrufende System seinen PPP-Client nur langsam hochfährt. Mit der modem-Option übernimmt pppd die Kontrolle der Modem-Steuerungsleitungen auf dem seriellen Port. Diese Option sollten Sie immer aktivieren, wenn Sie pppd mit einem Modem betreiben. Die Option crtscts schaltet den Hardware-Handshake ein.

Außer diesen Optionen sollten Sie auch irgendeine Form der Authentifizierung aktivieren. Dazu können Sie die Option auth in der pppd-Kommandozeile oder in der globalen Optionsdatei setzen. Die Manpage beschreibt auch spezifischere Optionen, mit denen Sie bestimmte Authentifizierungsprotokolle ein- und ausschalten können.

Falls Sie mgetty benutzen wollen, brauchen Sie es lediglich so zu konfigurieren, dass es das an Ihr Modem angeschlossene serielle Gerät benutzt (Details finden Sie in Kapitel 3). Dann müssen Sie nur noch pppd mit angemessenen Optionen in der Datei options auf PAP- oder CHAP-Authentifizierung einstellen und schließlich noch einen Abschnitt in Ihre /etc/mgetty/login.config-Datei eintragen, der etwa folgendermaßen aussieht:

# Konfiguration von mgetty zur automatischen Erkennung eingehender PPP-# Anrufe und
# Ausführung des pppd-Dämons zur Bearbeitung der Verbindung.
#
/AutoPPP/ - ppp /usr/sbin/pppd auth -chap +pap login

Das erste Feld enthält eine »magische« Option zur Erkennung, ob ein eingehender Anruf vom Typ PPP ist. Bei diesem String müssen Sie genau auf die Schreibweise achten - Groß- und Kleinschreibung sind hier wichtig. Die dritte Spalte enthält den Benutzernamen, der immer in den who-Listings erscheint, wenn sich jemand eingeloggt hat. Der Rest der Zeile enthält den Programmaufruf. In unserem Beispiel haben wir sichergestellt, dass die PAP-Authentifizierung erforderlich ist, CHAP abgeschaltet ist und dass die passwd-Datei des Systems zur Benutzer-Authentifizierung hinzugezogen werden soll. Das ist vielleicht in etwa das, was Sie möchten. Denken Sie daran, Sie können die Optionen entweder in der options-Datei oder auf der Kommandozeile angeben.

Hier folgt eine kleine Checkliste, die Sie der Reihe nach abhaken sollten, wenn Sie Ihre Maschine für die PPP-Einwahl fit machen wollen. Stellen Sie sicher, dass jeder Schritt korrekt funktioniert, bevor Sie mit dem nächsten Schritt fortfahren:

1. Konfigurieren Sie Ihr Modem auf automatische Antwort. Bei Hayes-kompatiblen Modems erreichen Sie das mit einem Befehl wie ATS0=3. Wenn Sie den mgetty-Dämon benutzen wollen, ist dieser Schritt nicht notwendig.
2. Konfigurieren Sie das serielle Gerät mit einem getty-artigen Befehl für die Beantwortung eingehender Anrufe. Eine häufig verwendete getty-Variante ist mgetty.
3. Überlegen Sie sich die Authentifizierungsmethoden. Werden sich Ihre Anrufer mittels PAP, CHAP oder System-Logins ausweisen?
4. Konfigurieren Sie pppd als Server, wie in diesem Abschnitt beschrieben.
5. Denken Sie über Routing nach. Müssen Sie Ihren Anrufern vielleicht eine Netzwerk-Route bereitstellen? Routing kann mit dem ip-up-Skript durchgeführt werden.

Einwahl nach Bedarf

Wann immer IP-Datenverkehr über die Verbindung stattfindet, bewirkt eine Einwahl nach Bedarf (demand dialing), dass das an Ihr Telefon angeschlossene Modem automatisch eine Einwahl durchführt und eine Verbindung zum entfernten Host aufbaut. Ein solches Einwahlverfahren ist besonders nützlich für Anwendungen, bei denen Sie keine dauerhafte Telefonverbindung zu Ihrem Internet-Provider wünschen. Wenn Sie zum Beispiel für zeitbegrenzte Ortsgespräche Geld bezahlen müssen, wäre es unter Umständen günstiger, wenn Sie nur dann eine Verbindung zu Ihrem Internet-Provider aufbauen, wenn sie gerade benötigt wird, und die meiste Zeit keine Verbindung besteht.

Traditionelle Linux-Lösungen verwendeten dafür den Befehl diald. Dieser Befehl funktionierte zwar ganz gut, war jedoch schwierig zu konfigurieren. Die Versionen 2.3.0 und folgende des PPP-Dämons haben bereits eine eingebaute Unterstützung für Einwahl nach Bedarf und sind sehr leicht zu konfigurieren.

Um pppd für Einwahl nach Bedarf zu konfigurieren, müssen Sie lediglich einige Optionen in Ihrer options-Datei oder auf der pppd-Kommandozeile angeben. Tabelle 6-2 fasst die Optionen für eine Einwahl nach Bedarf zusammen.

Tabelle 6-2
Optionen für die Einwahl nach Bedarf 
Option
Beschreibung
demand
Diese Option gibt an, dass die PPP-Verbindung mit Einwahl nach Bedarf aufgebaut werden soll. Das PPP-Netzwerkgerät ist bereits erzeugt, der connect-Befehl wird jedoch erst ausgeführt, wenn ein Datagramm durch den lokalen Host verschickt wird. Diese Option ist unbedingt erforderlich, damit Einwahl nach Bedarf funktioniert.
active-filter Ausdruck
Mit dieser Option geben Sie an, welche Datenpakete als aktiver Datenverkehr aufgefasst werden sollen. Jeder Datenverkehr, der die angegebene Regel erfüllt, startet den Leerlauf-Zeitgeber (Idle-Timer) neu und stellt damit sicher, dass pppd wieder wartet, bevor es die Verbindung kappt. Die Filtersyntax wurde dem Befehl tcpdump entlehnt. Der standardmäßig vorgegebene Filter passt zu allen Datagrammen.
holdoff n
Diese Option gibt die minimale Zeitspanne in Sekunden an, die verstreichen soll, bevor eine beendete Verbindung erneut aufgebaut wird. Falls die Verbindung abbricht, während pppd meint, sie wäre immer noch aktiv, wird sie erneut aufgebaut, sobald die Wartezeit abgelaufen ist. Diese Wartezeit wirkt sich aber nicht auf Verbindungen aus, die nach einer Leerlaufzeit (Idle-Timeout) neu aufgebaut werden.
idle n
Ist diese Option konfiguriert, unterbricht pppd eine Verbindung, sobald diese Wartezeit verstrichen ist. Die Wartezeit wird in Sekunden angegeben. Jedes neue aktive Datenpaket setzt den Zeitgeber zurück.

Eine einfache Konfiguration für Einwahl nach Bedarf sieht etwa folgendermaßen aus:

demand
holdoff 60
idle 180

Diese Konfiguration aktiviert Einwahl nach Bedarf, wartet 60 Sekunden, bevor eine unterbrochene Verbindung wieder aufgebaut wird, und beendet die Verbindung, wenn 180 Sekunden ohne irgendwelche aktiven Datentransfers über diese Verbindung verstrichen sind.

Ständige Einwahl

Ständige Einwahl ist das, was Anwender benutzen, wenn sie eine permanente Netzwerkanbindung haben wollen. Zwischen Einwahl nach Bedarf und dauerhafter Einwahl gibt es einen feinen Unterschied. Bei dauerhafter Einwahl wird die Verbindung automatisch aufgebaut, sobald der PPP-Dämon gestartet ist. Der dauerhafte Aspekt an der Verbindung kommt immer dann zur Geltung, wenn eine Telefonverbindung unterbrochen wird. Ständige Einwahl stellt sicher, dass die Verbindung immer verfügbar ist, indem eine unterbrochene Verbindung automatisch wieder aufgebaut wird.

Vielleicht gehören Sie zu den Leuten, die eine Flatrate haben, so dass Sie einen monatlichen Pauschalpreis für die Einwahl in Ihren Provider bezahlen. In einer solchen Situation ist eine dauerhafte Einwahl außerordentlich nützlich. Wenn Sie Ihre Telefonanrufe allerdings einzeln bezahlen müssen, sollten Sie vorsichtiger sein. Bezahlen Sie Ihre Telefonanrufe auf Zeitbasis, ist dauerhafte Einwahl ziemlich sicher nicht das, was Sie wollen, es sei denn, Sie benutzen Ihre Verbindung nahezu rund um die Uhr. Wenn Sie für jeden Anruf einzeln bezahlen müssen, müssen Sie Situationen vermeiden, die das Modem zu endlosen Wahlwiederholungen anregen. Der pppd-Dämon bietet eine Option, die Ihnen dabei hilft, die Auswirkungen dieses Problems zu reduzieren.

Um dauerhafte Einwahl zu aktivieren, müssen Sie die Option persist in einer Ihrer pppd-Optionsdateien angeben. Diese Option reicht völlig aus, um pppd dazu zu bringen, jedes Mal den in der Option connect angegebenen Befehl auszuführen, um eine unterbrochene Verbindung wieder aufzubauen. Wenn Sie besorgt sind, dass Ihr Modem die Wahlwiederholungen zu schnell durchführen könnte (bedingt durch einen Fehler im Modem oder beim Server am anderen Ende der Verbindung), steht Ihnen die Option holdoff zur Verfügung. Mit ihr können Sie die Mindestzeit angeben, die vor jeder neuen Verbindungsaufnahme verstreichen soll. Diese Option befreit Sie zwar nicht davon, für vergebliche Telefonanrufe bezahlen zu müssen, aber sie hilft Ihnen zumindest, die Auswirkungen zu reduzieren.

Eine typische Konfiguration mit Optionen für die dauerhafte Einwahl sieht etwa so aus:

persist
holdoff 600

Die holdoff-Zeit wird in Sekunden angegeben. In unserem Beispiel wartet pppd ganze fünf Minuten, bevor eine unterbrochene Verbindung erneut aufgebaut wird.

Es ist möglich, dauerhafte Einwahl mit Einwahl nach Bedarf zu kombinieren. Mit idle wird die Verbindung nach einer gewissen Zeit der Untätigkeit unterbrochen. Wir glauben zwar nicht, dass viele Benutzer daran Interesse haben, aber dieses Szenario wird kurz in der Manpage von pppd beschrieben.

PPPoE-Optionen in Linux

PPPoE ist in letzter Zeit immer wichtiger geworden, da es für viele DSL-Anbieter die bevorzugte Verbindungsmethode darstellt. Glücklicherweise stehen für Linux-Benutzer eine Reihe von entsprechenden Optionen zur Verfügung, die in der Regel leicht zu konfigurieren sind. PPPoE ist nicht neu, im Prinzip handelt es sich um das gleiche PPP wie bei Wählverbindungen, nur dass es nun über Ethernet benutzt wird.

Für die Erläuterungen in diesem Abschnitt wollen wir einmal davon ausgehen, dass Ihr DSL-Modem und die entsprechenden Anlagen betriebsbereit sind. Nähere Informationen zur Konfiguration solcher Geräte finden Sie im ausgezeichneten Linux-DSL HOWTO, geschrieben von David Fannin und Hal Burgiss (http://www.tldp.org/HOWTO/DSL-HOW- TO). Darüber hinaus nehmen wir an, dass die Ethernet-Karte in Ihrem PC installiert und betriebsbereit ist.

In den meisten DSL-Umgebungen ist das DSL-Modem so konfiguriert, dass es als Bridge dient. Das bedeutet, dass es keine IP-Adresse besitzt. Für Sie heißt das, dass Ihr Server mit einer WAN-IP-Adresse konfiguriert ist. Bevor Sie die WAN-Schnittstelle aktivieren, sollten Sie überprüfen, ob Sie alle lauschenden Dienste auf Ihrer Maschine gesichert haben. Außerdem sollten Sie es in Betracht ziehen, IPtables oder eine andere Firewall einzusetzen. Beim direkten Anschluss an das Internet muss Sicherheit oberste Priorität haben. Es gibt Berichte darüber, dass ungepatchte Versionen einiger Linux-Distributionen nur wenige Stunden im Internet überleben, bevor sie kompromittiert werden. Tun Sie alles Mögliche, damit Ihnen das nicht passiert!

PPPoE-Clients

Damit Sie mit der Konfiguration von PPPoE anfangen können, müssen Sie sich einen PPPoE-Client besorgen. Es gibt verschiedene Clients, einschließlich eines Clients von Roaring Penguin, der bei vielen Benutzern und Providern sehr beliebt ist. Diesen Client können Sie von http://www.roaringpenguin.com herunterladen, und zwar sowohl im Quellformat als auch als vorkompilierte RPMs. Wenn Sie die Software heruntergeladen und kompiliert oder installiert haben, sind Sie bereit für die Konfiguration. Die Client-Software enthält ein einfach zu benutzendes Konfigurationsskript namens adsl-setup. Dieses Skript stellt Ihnen eine Reihe von Fragen über Ihr System, das Netzwerk und die PPPoE-Benutzerinformationen. In einigen Fällen werden Ihnen sogar die Antworten angeboten, die Sie dann nur noch bestätigen müssen!

Das Skript ist zwar ganz hilfreich, allerdings ist es nicht narrensicher, weshalb wir Ihnen die manuelle Konfiguration erläutern. Außerdem ist es von Vorteil, vor allem aus Sicht des Netzwerkadministrators, wenn man eine gute Vorstellung davon hat, wie die Software konfiguriert wird - falls in Zukunft etwas schief geht.

Manuelle PPPoE-Client-Konfiguration

Das Konfigurieren des Clients ist ziemlich einfach, vor allem, wenn Sie zuvor bereits einmal eine Standard-PPP-Konfiguration erzeugt haben. Zuerst müssen Sie die Datei /etc/ppp/pap-secrets bearbeiten. Sie tragen anstelle der vorgegebenen Werte Ihren PPPoE-Benutzernamen und das Kennwort ein. Die Datei sieht etwa folgendermaßen aus:

#Benutzer #Server #Kennwort #IP
groucho@dslcompany.to * mein_kennwort *

Öffnen Sie als Nächstes die Datei /etc/ppp/pppoe.conf in Ihrem Texteditor. Sie müssen sowohl den Namen Ihrer WAN-Schnittstelle als auch Ihren PPPoE-Benutzernamen eintragen. Die relevanten Zeilen in der Datei sehen so aus:

# An das ADSL-Modem angeschlossene Ethernet-Karte
ETH=eth0

# ADSL-Benutzername. Möglicherweise müssen Sie noch "@provider.com" angeben
USER=groucho@dslcompany.to

Die Datei enthält eine Reihe zusätzlicher Konfigurationsoptionen. Ändern Sie diese nur, wenn Sie sich wirklich sicher sind, dass dies erforderlich ist. Falls Sie sich dazu entschlossen haben, Änderungen vorzunehmen, entnehmen Sie den PPP-Manpages weitere Informationen.

Falls Sie schließlich Ihre DNS-Server noch nicht in der Datei /etc/resolv.conf konfiguriert haben, sollten Sie das jetzt erledigen. Ausführliche Informationen über die DNS-Konfiguration finden Sie in Kapitel 5.

Wenn Sie mit der Konfiguration fertig sind, können Sie nun die Verbindung testen, um festzustellen, ob sie funktioniert. Das adsl-start-Skript wird speziell für diesen Zweck eingesetzt. Sie können es von der Kommandozeile aus aufrufen. Oder Sie schließen es idealerweise in Ihre Systemstartskripten ein. Wie Sie dabei vorgehen, variiert von Distribution zu Distribution. Schauen Sie in die Dokumentation, die mit Ihrer Distribution geliefert wurde, um genau zu erfahren, wie Sie die Startskripten installieren.

Wenn das Startskript ohne Fehler ausgeführt wurde, sollten Sie mit dem Internet verbunden sein. Eine schnelle und einfache Testmethode besteht darin, etwas mit »ping« anzusprechen. Im Erfolgsfall sieht das so aus:

vlager# ping www.google.com
PING www.google.akadns.net (66.102.7.99) 56(84) bytes of data.
64 bytes from 66.102.7.99: icmp_seq=1 ttl=245 time=5.94 ms
64 bytes from 66.102.7.99: icmp_seq=2 ttl=245 time=5.02 ms
64 bytes from 66.102.7.99: icmp_seq=3 ttl=245 time=5.02 ms
ctrl-c
--- www.google.akadns.net ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2009ms
rtt min/avg/max/mdev = 5.028/5.333/5.945/0.440 ms
vlager#

Sie können die Konfiguration außerdem mit ifconfig überprüfen:

vlager# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:08:02:F0:BB:0E
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:8701578 errors:6090 dropped:0 overruns:0 frame:5916
TX packets:3888596 errors:0 dropped:0 overruns:0 carrier:0
collisions:6289 txqueuelen:100
RX bytes:1941625928 (1851.6 Mb) TX bytes:1481305134 (1412.6 Mb)
Interrupt:30

eth1 Link encap:Ethernet HWaddr 00:90:27:FE:02:A0
inet addr:10.10.0.254 Bcast:10.10.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:48920435 errors:0 dropped:0 overruns:0 frame:0
TX packets:55211769 errors:0 dropped:0 overruns:2 carrier:9
collisions:367030 txqueuelen:100
RX bytes:2018181326 (1924.6 Mb) TX bytes:1564406617 (1491.9 Mb)
Interrupt:10 Base address:0x4000
.
ppp0 Link encap:Point-to-Point Protocol
inet addr: 64.168.44.33 P-t-P:64.168.44.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1
RX packets: 8701576 errors:0 dropped:0 overruns:0 frame:0
TX packets: 3888594 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:10

Falls irgendetwas an dieser Stelle nicht richtig funktioniert, prüfen Sie alle Verbindungen und stellen Sie sicher, dass die DSL-Anlagen korrekt konfiguriert sind. Prüfen Sie darüber hinaus Ihren Benutzernamen und das Kennwort in den Konfigurationsdateien - ein falsch geschriebenes Kennwort gehört zu den am häufigsten auftretenden Konfigurationsproblemen!

Fussnoten

1Um genau zu sein, handelt es sich bei HDLC um ein viel allgemeineres Protokoll, das von der International Standards Organization (ISO) festgelegt wurde. Es ist außerdem ein wichtiger Bestandteil der X.25-Spezifikation.
2Die Standard-Netzwerk-Route wird nur installiert, wenn noch keine vorhanden ist.
3Wenn Sie syslog.conf so bearbeiten, dass alle Protokollmeldungen in eine Datei umgeleitet werden, müssen Sie darauf achten, dass diese Datei nicht von jedem gelesen werden kann, weil chat standardmäßig auch das gesamte Skript aufzeichnet - einschließlich der Kennwörter.
4Weitere Informationen über zwei Verfahren zur dynamischen Zuweisung von Hostadressen finden Sie unter http://www.dynip.com/.
5Die Verwendung von Hostnamen bei dieser Option hat Auswirkungen auf die CHAP-Authentifizierung. Mehr dazu finden Sie im Abschnitt »Die CHAP-Secrets-Datei« weiter hinten in diesem Kapitel.
6Mit den Optionen ipcp-accept-local und ipcp-accept-remote weisen Sie Ihren pppd-Dämon an, die lokalen und entfernten IP-Adressen zu akzeptieren, die von der Gegenstelle angeboten werden, auch wenn Sie bereits Adressen in Ihrer Konfiguration angegeben haben. Sind diese Optionen nicht konfiguriert, verweigert pppd jeden Versuch, die IP-Adressen auszuhandeln.
7Wollten wir auch Routen für andere Sites erzeugen lassen, wenn sie sich einwählen, dann würden wir im Beispiel weitere geeignete case-Anweisungen an den Stellen hinzufügen, an denen ... steht.
8Die doppelten Anführungszeichen sind nicht Teil des Kennworts, sondern dienen nur dazu, die Leerzeichen innerhalb des Kennworts zu schützen.
9Der Hostname stammt aus der CHAP-Anforderung.
10Die Dienstprogramme useradd oder adduser vereinfachen diese Aufgabe (sofern sie verfügbar sind).

TOC PREV NEXT INDEX


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

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