Copyright © 1996 by O'Reilly/International Thomson Verlag

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 durch das Netzwerk" dann klicken Sie hier.


Kapitel 8
Das Point-to-Point-Protokoll

Die Ps entwirren

Genau wie SLIP ist auch PPP ein Protokoll, mit dem Sie Datagramme über eine serielle Leitung übertragen können, das aber eine Reihe von Defiziten von SLIP behebt. Es erlaubt den kommunizierenden Rechnern, sich über Optionen wie IP-Adressen und die maximale Datagramm-Größe während der Startphase zu verständigen und stellt Mechanismen zur Autorisierung des kommunizierenden Partners bereit. Für jede dieser Fähigkeiten verwendet PPP ein separates Protokoll. In diesem Kapitel behandeln wir die grundlegenden Bausteine von PPP. Die Diskussion ist weit davon entfernt, vollständig zu sein. Wenn Sie mehr über PPP wissen wollen, sollten Sie sich die entsprechende RFC-Spezifikation sowie das gute Dutzend begleitender RFCs ansehen.(1)

Die Basis bei PPP bildet das High-Level Data Link Control-Protokoll, oder kurz HDLC.(2) Dieses Protokoll definiert die Begrenzung der einzelnen PPP-Frames und liefert eine 16-Bit-Prüfsumme. Im Gegensatz zur eher primitiven SLIP-Kapselung ist ein PPP-Frame in der Lage, auch Pakete anderer Protokolle als IP zu transportieren (z. B. Novells IPX oder AppleTalk). PPP erreicht dies, indem es ein Protokollfeld in den HDLC-Frame aufnimmt, der den Typ des Pakets bestimmt, das sich in diesem Frame befindet.

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

Ein wichtiger Schritt bei der Konfigurationsphase eines PPP-Links ist die Client-Authentisierung. Obwohl es nicht vorgeschrieben ist, ist es doch ein Muß bei Wählverbindungen. Üblicherweise fordert der angerufene Host (der Server) den Client auf, sich auszuweisen, indem er beweist, daß er einen geheimen Schlüssel (z. B. ein Paßwort) kennt. Wenn der Anrufer nicht mit der richtigen Antwort aufwarten kann, wird die Verbindung unterbrochen. Bei PPP funktioniert die Authentisierung in beiden Richtungen, d. h. der Anrufer kann auch den Server auffordern, sich zu authentisieren. Diese Authentisierungs-Prozeduren laufen völlig unabhängig voneinander ab. Es gibt zwei Protokolle für unterschiedliche Arten der Authentisierung, die wir weiter unten noch besprechen werden. Diese Protokolle heißen Password Authentication Protocol (PAP) und Challenge Handshake Authentication Protocol (CHAP).

Jedes Netzwerk-Protokoll wie IP, AppleTalk etc., das über die Datenverbindung geroutet wird, wird mit Hilfe eines entsprechenden Network Control Protocol (NCP) dynamisch konfiguriert. Sollen zum Beispiel IP-Datagramme über einen Link geschickt werden, müssen beide PPPs zuerst ermitteln, welche IP-Adresse von der jeweils anderen Seite verwendet wird. Das dabei benutzte 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. Bei dieser Technik werden Header von TCP-Paketen auf eine Größe von bis zu drei Byte reduziert. Sie wird auch bei CSLIP verwendet und 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 unterteilt: in einen Low-Level-HDLC-Treiber, der im Kernel angesiedelt ist, und einen Dämon (pppd), der die verschiedenen Kontrollprotokolle behandelt. Das aktuelle Release von PPP für Linux ist linux-ppp-2.1.2. Sie besteht aus dem PPP-Kernel-Modul pppd und einem Programm namens chat, mit dem der entfernte Rechner angewählt wird.

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

Genau wie SLIP wird auch PPP über einen speziellen tty-Modus (line discipline) implementiert. Um eine Leitung als PPP-Link 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 können IP-Datagramme mit oder ohne Van Jacobson-Komprimierung verarbeitet werden. Sobald Linux IPX unterstützt, wird der PPP-Treiber auch für die Verarbeitung von IPX-Paketen erweitert.

Der Kernel-Treiber wird von dem Dämon pppd unterstützt, der die gesamte Initialisierungs- und Authentizierungsphase übernimmt, die notwendig ist, bevor die eigentlichen Daten über den Link geschickt werden können. Das Verhalten von pppd kann über eine ganze Reihe von Optionen getrimmt werden. Da PPP ziemlich komplex ist, ist es unmöglich, sie alle in einem einzigen Kapitel zu behandeln. Aus diesem Grund kann das Buch nicht alle Aspekte von pppd behandeln, sondern nur eine Einführung bieten. Für weitere Informationen seien Sie auf die Manpages und die READMEs der pppd-Source-Distribution verwiesen. Dort sollten Sie Antworten auf die meisten Fragen finden, die in diesem Kapitel nicht behandelt werden konnten. Wenn Sie nach dem Lesen der Dokumentation immer noch Probleme haben, sollten Sie sich an die Newsgruppe comp.protocols.ppp wenden. In dieser Newsgruppe finden Sie die meisten der Leute, die an der Entwicklung von pppd beteiligt waren.

Arbeiten mit pppd

Wenn Sie sich über einen PPP-Link an das Internet anschließen wollen, müssen Sie die grundlegenden Netzwerk-Fähigkeiten wie das Loopback Device und den Resolver eingerichtet haben. Wie das funktioniert, wurde in den vorhergehenden Kapiteln besprochen. Bei der Verwendung von DNS über serielle Leitungen kommen noch weitere Faktoren ins Spiel; entsprechende Hinweise finden Sie in Kapitel 7, Serial Line IP.

Um sich zur Einleitung vor Augen zu führen, wie eine PPP-Verbindung mit pppd aufgebaut wird, stellen Sie sich vor, daß Sie wieder an vlager sitzen. Sie haben bereits den PPP-Server c3po angewählt und sich in den ppp-Account eingeloggt. c3po hat seinen PPP-Treiber bereits gestartet. Nachdem Sie das Kommunikationsprogramm beendet haben, mit dem Sie die Verbindung hergestellt hatten, führen Sie den folgenden Befehl aus:

# pppd /dev/cua3 38400 crtscts defaultroute
Mit diesem Befehl schalten Sie die serielle Leitung cua3 in den PPP-Modus und bauen einen IP-Link zu c3po auf. Die Übertragungsgeschwindigkeit des seriellen Ports liegt bei 38400 bps. Mit der Option crtscts aktivieren Sie den Hardware-Handshake für diesen Port, was bei Geschwindigkeiten über 9600 bps ein absolutes Muß ist.

Nachdem pppd gestartet wurde, vereinbart es zuerst mit Hilfe von LCP verschiedene Verbindungseigenschaften mit dem anderen Ende. Üblicherweise funktionieren die Standardoptionen, die pppd auszuhandeln versucht, auf Anhieb, weshalb wir an dieser Stelle nicht weiter darauf eingehen.

Im Moment gehen wir auch davon aus, daß c3po von uns keine Authentisierung erwartet, so daß die Konfigurationsphase an dieser Stelle erfolgreich abgeschlossen ist.

pppd vereinbart dann mit Hilfe von IPCP, dem IP-Kontroll-Protokoll, die IP-Parameter mit seinem Gegenüber. Weil wir in der Befehlszeile 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.

Üblicherweise gibt es mit diesen Voreinstellungen keine Schwierigkeiten. Selbst wenn Ihr Rechner in einem Ethernet hängt, können Sie dieselbe IP-Adresse sowohl für das Ethernet als auch für das PPP-Interface benutzen. Trotzdem erlaubt es 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-Konfigurations-Optionen« behandelt.

Nachdem pppd die IPCP-Setup-Phase hinter sich gebracht hat, bereitet es die Netzwerkschicht Ihres Host erstmal für die Verwendung des PPP-Links vor. Zuerst konfiguriert es das PPP-Netzwerk-Interface als Point-to-Point-Link. Dabei verwendet es ppp0 für den ersten aktiven PPP-Link, ppp1 für den zweiten und so weiter. Danach richtet es einen Eintrag in der Routing-Tabelle ein, der auf den Host am anderen Ende des Links zeigt. In unserem obigen Beispiel läßt pppd die Default-Netzwerkroute auf c3po zeigen, weil wir die Option defaultroute verwendet haben.(5) Auf diese Weise werden alle Datagramme, die nicht für Hosts in Ihrem lokalen Netzwerk bestimmt sind, an c3po übertragen. 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 Kommandozeilen-Argumente bearbeitet, durchsucht es verschiedene Dateien nach Standardoptionen. Diese Dateien dürfen beliebige gültige Kommandozeilen-Argumente enthalten, die auch über mehrere Zeilen verteilt sein können. Kommentare werden dabei durch Doppelkreuze eingeleitet.

Die erste Optionsdatei ist /etc/ppp/options, die immer durchsucht wird, während pppd startet. Es ist eine gute Idee, diese Datei für allgemeine Standardeinstellungen zu verwenden, weil Sie auf diese Weise verhindern, daß Benutzer verschiedene Dinge tun könnten, die sich auf die Systemsicherheit auswirken. Damit pppd beispielsweise irgendeine Form der Authentisierung (PAP oder CHAP) von der anderen Seite 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 Authentisierungs-Datei steht.

Nach /etc/ppp/options wird die Optionsdatei .ppprc im Home-Verzeichnis des Benutzers gelesen. Sie erlaubt jedem Benutzer einen individuellen Satz von Standardoptionen.

Die Datei /etc/ppp/options könnte beispielsweise wie folgt aussehen:

# Globale Optionen für pppd auf vlager.vbrew.com
auth                 # Authentisierung notwendig
usehostname          # verwende lokalen Hostnamen für CHAP
lock                 # verwende UUCP-konformes Device Locking
domain vbrew.com     # unser Domainname
Die ersten beiden Optionen dienen der Authentizierung und werden nachfolgend besprochen. Wegen des Schlüsselworts lock verwendet pppd die UUCP-Standardmethode zum Sperren der Gerätedateien. Nach dieser Konvention erzeugt jeder Prozeß, der auf ein serielles Device, beispielsweise /dev/cua3, zugreift, eine Lock-Datei namens LCK..cua3 im UUCP-Spool-Verzeichnis, um zu signalisieren, daß dieses Gerät benutzt wird. Ein solches Vorgehen ist notwendig, um sicherzustellen, daß andere Programme wie minicom oder uucico nicht auf das Gerät zugreifen, solange es von PPP verwendet wird.

Der Grund dafür, solche Optionen in die globale Konfigurationsdatei einzutragen, liegt darin, daß solche Optionen nicht überschrieben werden können und Sie so für einen vernünftigen Grad an Sicherheit sorgen. Andererseits existieren aber auch Optionen wie der connect-String, die auch später noch überschrieben werden können.

Anwählen mit Chat

Eine Sache, die Sie in unserem obigen Beispiel vielleicht als unbequem betrachten könnten, ist, daß Sie die Verbindung zuerst manuell aufbauen müssen, bevor Sie pppd starten können. Leider besitzt pppd im Gegensatz zu dip keine eigene Skript-Sprache, mit der Sie das entfernte System anwählen und sich einloggen können, sondern ist von einem externen Programm oder Shell-Skript abhängig, das diese Aufgabe übernimmt. Der entsprechende Befehl kann pppd mit der Kommandozeilen-Option connect übergeben werden. pppd leitet die Standard-Ein- und Ausgabe des Programms dann an die serielle Leitung um. Ein für diese Aufgabe ausgezeichnet geeignetes Programm ist expect, geschrieben von Don Libes. Es besitzt eine sehr mächtige, auf Tcl basierende Sprache und wurde genau für solche Anwendungszwecke entworfen.

Das pppd-Paket wird mit einem ähnlichen Programm namens chat geliefert, mit dem Sie Chat-Skripten ausführen können, wie sie auch von UUCP verwendet werden. Grundsätzlich besteht ein Chat-Skript aus einer abwechselnden Folge von Zeichenketten, die wir vom entfernten System erwarten, sowie den Antworten, die auf diese Strings übertragen werden sollen. Wir nennen sie expect- (die erwartete Zeichenkette) und send- (die zu übertragende Zeichenkette) Strings. Nachfolgend ein typischer Ausschnitt aus einem Chat-Skript:

ogin: b1ff ssword: s3kr3t
Diese Zeile weist chat an, darauf zu warten, bis die andere Seite den Login-Prompt gesendet hat, und dann den Loginnamen b1ff zurückzuschicken. Wir warten nur auf ogin:, so daß es keine Rolle spielt, ob der Login-Prompt mit einem großen oder kleinen »l« beginnt. Der folgende String ist ein weiterer erwarteter Text, auf den chat warten soll. Sobald dieser eingeht, wird unser Paßwort 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üßte natürlich auch die entsprechenden Modembefehle beinhalten. Nehmen wir einmal an, Ihr Modem verstünde den Hayes-Befehlssatz, und die Telefonnummer des Servers lautete 318714. Die vollständige Befehlszeile, mit der chat die Verbindung zu c3po aufbaut, würde dann lauten:

$ 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 wie 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 genauso, wie bereits oben beschrieben.

Mit der Option -v weisen Sie chat an, alle Aktivitäten in der local2-Einrichtung des syslog-Dämons aufzuzeichnen.(6)

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 ausschalten, 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. Der vollständige pppd-Aufruf würde dann wie folgt lauten:

# pppd connect "chat -f dial-c3po" /dev/cua3 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 Hintergrundprozeß 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 auch wesentlich kompliziertere Skripten erstellen. Eine sehr nützliche Möglichkeit ist, einen String angeben zu können, 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 direkt 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 eine 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. Sie erreichen dies, indem Sie ein UnterSkript an einen Expect-String anhängen. Dieses besteht genau wie beim normalen Skript auch aus einer Reihe von Send- und Expect-Strings, die durch Bindestriche voneinander getrennt sind. Das UnterSkript 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 wie folgt modifizieren:

ogin:-BREAK-ogin: ppp ssword: GaGariN
Empfängt chat nun vom entfernten System nicht den Login-Prompt, wird das UnterSkript ausgeführt. Dabei wird zuerst ein BREAK übertragen, und danach wird erneut auf den Login-Prompt gewartet. Erscheint der Prompt nun, läuft das Skript weiter, als wäre nichts gewesen, ansonsten wird es mit einem Fehler abgebrochen.

Debuggen Ihres PPP-Setups

Per Voreinstellung schickt pppd alle Warnungen und Fehlermeldungen an die daemon-Einrichtung des syslog-Dämons. Sie müssen eine Zeile zu Ihrer syslog.conf hinzufügen, damit diese die Nachrichten in eine Datei oder sogar direkt auf die Konsole schreibt. Anderenfalls sortiert syslog sie einfach aus. Mit dem folgenden Eintrag werden alle Meldungen in die Datei /var/log/ppp-log geschrieben:

daemon.*                /var/log/ppp-log
Wenn Ihr PPP-Setup nicht auf Anhieb läuft, sollte Ihnen ein Blick in die Logdatei einen ersten Hinweis auf den möglichen Fehler liefern. Falls das nicht hilft, können Sie mit der Option debug eine gesonderte Debug-Ausgabe einschalten. Das veranlaßt pppd, den Inhalt aller empfangenen und gesendeten Kontrollpakete syslog aufzuzeichnen.

Wenn auch das nicht weiterhilft, bleibt noch die drastischste Möglichkeit, das Debugging auf Kernel-Ebene zu aktivieren, indem Sie pppd mit der Option kdebug ausführen. Die Option benötigt ein zusätzliches numerisches Argument, das eine bitweise ODER-Verknüpfung der folgenden Werte sein kann: 1 für allgemeine Debug-Nachrichten, 2 für die Ausgabe der Inhalte aller eingehenden HDLC-Frames und 4 für die Ausgabe aller ausgehenden HDLC-Frames. Um Kernel-Debugging-Nachrichten abfangen zu können, brauchen Sie entweder einen syslogd-Dämon, der die Datei /proc/kmsg liest oder den klogd-Dämon. Beide leiten das Kernel-Debugging an die kernel-Einrichtung von syslog weiter.

IP-Konfigurations-Optionen

IPCP wird verwendet, um eine Reihe von IP-Parametern während der (Leitungs-) Konfigurationsphase zu vereinbaren. Üblicherweise sendet jede Seite ein Paket mit einer IPCP-Konfigurations-Anforderung, die beschreibt, welche Werte von den Defaults 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 eine sehr große Kontrolle darüber, welche IPCP-Optionen es auszuhandeln versucht und welche nicht. Sie können dies über verschiedene Kommandozeilen-Optionen einstellen, die wir nachfolgend vorstellen wollen.

Wahl von IP-Adressen

Im obigen Beispiel haben wir pppd das System c3po anwählen lassen und einen IP-Link eingerichtet. Dabei wurden keinerlei Vorkehrungen getroffen, welche IP-Adressen an beiden Enden verwendet werden sollten. Statt dessen haben wir die Adresse von vlager als lokale IP-Adresse verwendet und c3po sich eine eigene auswählen lassen. Trotzdem kann es manchmal sinnvoll sein, die Kontrolle darüber zu haben, welche Adresse am jeweiligen Ende verwendet wird. pppd bietet zu diesem Zweck eine Reihe von Optionen an.

Um bestimmte Adressen anzufordern, müssen Sie pppd diese mit der folgenden Option bekanntgeben:

local_addr:remote_addr
local_addr und remote_addr können dabei entweder in Dotted Quad Notation oder als Hostnamen angegeben werden.(7) Bei dieser Option geht pppd davon aus, daß es sich bei der ersten um seine eigene und bei der zweiten um die Adresse der anderen Seite handelt. Lehnt eine Seite eine der Adressen während der IPCP-Vereinbarungsphase ab, wird kein IP-Link aufgebaut.(8)

Wenn Sie nur die lokale Adresse setzen möchten, gleichzeitig aber die Adresse akzeptieren wollen, die die Gegenseite verwendet, lassen Sie den remote_addr-Teil einfach weg. Soll vlager beispielsweise die IP-Adresse 130.83.4.27 anstelle seiner eigenen verwenden, können Sie 130.83.4.27: in der Kommandozeile eingeben. Genauso gehen Sie vor, wenn Sie nur die Adresse der anderen Seite einstellen wollen, indem Sie das Feld local_addr leer lassen. Per Standardeinstellung verwendet pppd dann die Adresse, die mit Ihrem Hostnamen verknüpft ist.

Einige PPP-Server, die viele Client-Sites verwalten müssen, weisen Adressen dynamisch zu. Adressen werden an Systeme nur vergeben, wenn ein Anruf erfolgt, und werden anschließend recyclet, sobald die Verbindung wieder unterbrochen wird. Wenn Sie einen solchen Server anwählen, müssen Sie darauf achten, daß Sie keine bestimmte Adresse vom Server anfordern, sondern die Ihnen zugedachte akzeptieren. Das bedeutet, daß Sie das Argument local_addr nicht verwenden dürfen. Gleichzeitig müssen Sie auch die Option noipdefault verwenden, mit der Sie pppd anweisen, auf eine IP-Adresse von der Gegenseite zu warten, statt die lokale Host-Adresse zu verwenden.

Routen über einen PPP-Link

Nachdem das Netzwerk-Interface eingerichtet ist, setzt pppd nur eine Host-Route 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. Darum muß eine Netzwerkroute eingerichtet werden.

Sie haben bereits gesehen, daß Sie pppd mit der Option defaultroute anweisen können, die Default-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 zu erreichen. Nehmen wir zum Beispiel einen Angestellten der virtuellen Brauerei, dessen zu Hause stehende Maschine loner heißt. Wird über PPP eine Verbindung mit vlager aufgebaut, verwendet er eine Adresse des Brauerei-Subnetzes. Auf vlager können wir pppd nun mit der Option proxyarp aufrufen, was einen sog. Proxy-ARP-Eintrag für loner installiert (Proxy bedeutet soviel wie Vollmacht). Auf diese Weise wird loner automatisch für alle Hosts in der Brauerei und Winzerei zugänglich gemacht.

Leider sind die Dinge nicht immer so einfach. Beispielsweise wird bei der Verbindung von zwei lokalen Netzwerken eine bestimmte Netzwerkroute benötigt, weil beide Netzwerke ihre persönliche Default-Route haben könnten. Würden beide Seiten den PPP-Link als Default-Route verwenden, würde das außerdem eine Schleife erzeugen, bei der Pakete mit unbekanntem Ziel solange hin- und hertransportiert würden, bis deren »Time-to-live« überschritten wäre.

Nehmen wir als Beispiel einmal an, daß 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 an das Hauptnetz der Brauerei über PPP anschließen, um Kundendaten zu aktualisieren etc. Erneut dient vlager als Gateway. Die Gegenseite verwendet dabei den Namen sub-etha und die IP-Adresse 172.16.3.1..

Sobald sub-etha die Verbindung zu vlager herstellt, legt es wie gewöhnlich eine Default-Route an, die auf vlager zeigt. Gleichzeitig müssen wir aber auf vlager eine Netzwerkroute für Subnetz 3 einrichten, die über sub-etha läuft. Dazu verwenden wir ein pppd-Feature, das 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 ausgeführt wird, nachdem das PPP-Interface konfiguriert wurde. Wenn vorhanden, wird es mit den folgenden Parametern aufgerufen:

ip-up iface device speed local_addr remote_addr
iface steht für das zu verwendende Netzwerk-Interface, device ist der Pfadname auf die verwendete serielle Gerätedatei (/dev/tty, wenn stdin/stdout verwendet werden), und speed steht für die Geschwindigkeit der seriellen Schnittstelle. local_addr und remote_addr enthalten die IP-Adressen beider Enden des Links in Dotted Quad Notation. In unserem Fall könnte das ip-up-Skript das folgende Kode-Fragment enthalten:
#!/bin/sh
case $5 in
172.16.3.1)            # sub-etha
        route add -net 172.16.3.0 gw 172.16.3.1;;
...
esac
exit 0
Auf dieselbe Weise wird /etc/ppp/ip-down verwendet, um alle Aktionen von ip-up wieder rückgängig zu machen, nachdem der PPP-Link wieder unterbrochen wurde.

Nun, das Routing-Schema ist 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 den PPP-Link. Das ist kein Problem, wenn alle Hosts in der Zweigstelle die Default-Route auf sub-etha zeigen lassen und alle Hosts der Brauerei standardmäßig auf vlager routen. Wenn dies nicht der Fall ist, ist die einzige Möglichkeit üblicherweise die Verwendung eines Routing-Dämons wie gated. Nachdem die Netzwerkroute auf vlager eingerichtet ist, gibt der Routing-Dämon die neue Route an alle Hosts der angebundenen Subnetze weiter.

Link-Kontrolloptionen

LCP, das Link Control Protocol, haben wir ja bereits vorgestellt. Es wird genutzt, um die Charakteristika eines Links zu vereinbaren und den Link zu testen.

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

Die »Asynchronous Control Character Map«, allgemein Async-Map genannt, wird bei asynchronen Links wie beispielsweise Telefonleitungen verwendet, um Steuerzeichen zu erkennen, die durch eine Zwei-Zeichen-Sequenz (Escape-Sequenz) ersetzt werden müssen. Beispielsweise könnten Sie die beim Software-Handshake verwendeten Zeichen XON und XOFF umgehen wollen, weil einige fehlerhaft konfigurierte Modems sich beim Empfang von XOFF verabschieden. Ein weiterer Kandidat ist Ctrl-] (das telnet-Escape-Zeichen). PPP erlaubt es Ihnen, solche Zeichen mit den ASCII-Kodes 0 bis 31 besonders zu kennzeichnen, indem Sie sie in die Async-Map aufnehmen.

Die Async-Map ist eine 32 Bit breite Bitmap, bei der das niederwertigste Bit dem ASCII-Zeichen NUL und das höherwertigste Bit dem ASCII-Wert 31 entspricht. Ist ein Bit gesetzt, bedeutet das, daß das entsprechende Zeichen erst umgewandelt werden muß, bevor es über den Link transportiert werden kann. Am Anfang steht die Async-Map auf 0xffffffff, alle Steuerzeichen müssen umgewandelt werden.

Um Ihrer Seite mitzuteilen, daß nicht alle 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 nutzen:

asyncmap 0x000A0000
Mit der »Maximum Receive Unit«, oder 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 das Interface verarbeiten kann. Die MRU ist eher eine Empfehlung an die andere Seite, keine Frames zu generieren, die länger als die MRU sind. Das Interface muß aber dennoch in der Lage sein, Frames mit einer Größe von bis zu 1500 Byte zu empfangen.

Die Wahl einer MRU ist daher also nicht so sehr eine Frage dessen, was ein Link zu übertragen in der Lage ist, sondern eher, wie der beste Durchsatz zu erzielen ist. 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-Session) Ihren Cursor nicht zum »ruckeln« bringen. Sie weisen pppd an, eine MRU von 296 zu verwenden, indem Sie die Option mru 296 in der Kommandozeile übergeben. Kleine MRUs machen allerdings nur Sinn, wenn Sie die VJ-Header-Komprimierung nicht deaktiviert haben (sie ist per Standardeinstellung aktiviert).

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 Konfigurations-Anforderungen 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.

Zum Schluß 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 diese, um zu prüfen, ob der Link noch funktioniert. Sie aktivieren diese Option 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, daß die Gegenseite mit einer »Echo Response« antwortet. Erfolgt 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 Standardeinstellung ist dieses Feature deaktiviert.

Allgemeine Sicherheitsaspekte

Ein fehlerhaft konfigurierter PPP-Dämon kann eine vernichtende Sicherheitslücke sein. Im schlimmsten Fall kann das so sein, als ob sich jeder direkt an Ihr Ethernet anschließen könnte (und das ist sehr schlecht). In diesem Abschnitt wollen wir einige Maßnahmen diskutieren, die Ihre PPP-Konfiguration sicher machen sollten.

Ein Problem mit pppd ist, daß es zur Konfiguration des Netz-Interfaces und der Routing-Tabelle root-Privilegien benötigt. Üblicherweise lösen Sie dieses Problem, indem Sie es mit Setuid root ausführen. Jedoch erlaubt es pppd dem Benutzer, verschiedene sicherheitsrelevante Optionen zu setzen. Um sich vor Angriffen zu schützen, die ein Benutzer durch Manipulation dieser 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«. Einige dieser Optionen, wie die zur Authentisierung, können dann vom Benutzer nicht überschrieben werden, was eine vernünftige Sicherung gegen Manipulationen darstellt.

Natürlich müssen Sie sich aber auch selbst vor dem System schützen, mit dem Sie über PPP kommunizieren. Um zu verhindern, daß sich Hosts als jemand anders ausgeben, sollten Sie immer irgendeine Form der Authentisierung 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 einschränken. Der folgende Abschnitt befaßt sich mit diesen Themen.

Authentizierung mit PPP

CHAP verglichen mit PAP

Mit PPP kann jedes System seine Gegenseite auffordern, sich zu authentisieren. Dazu kann eins von zwei Authentizierungs-Protokollen verwendet werden. Dies 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 authentisieren, gleichgültig, ob sie die rufende oder angerufene Seite ist. Im folgenden werde ich von »Client« und »Server« reden, um zwischen dem sich authentisierenden System und dem Authentikator zu unterscheiden. Ein PPP-Dämon kann von seinem Gegenüber die Authentisierung anfordern, indem er einfach eine weitere LCP-Konfigurations-Anforderung sendet, die das verwendete Authentisierungs-Protokoll enthält.

PAP arbeitet grundsätzlich auf dieselbe Weise wie die normale Login-Prozedur. Der Client authentiziert sich, indem er einen Benutzernamen und ein (optional verschlüsseltes) Paßwort an den Server schickt, die der Server dann beide mit seiner sog. Secrets-Datenbank vergleicht. Diese Technik ist durch Lauscher angreifbar, die an der seriellen Leitung horchen. Auch Angriffe nach dem Trial-and-Error-Verfahren sind hier denkbar.

CHAP hat diese Defizite nicht. Bei CHAP sendet der Authentikator (d. h. der Server) einen zufällig erzeugten »Anforderungs-String« 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, daß es die Authentizierung durch den Client nicht nur beim Start abfragt, sondern solche Anforderungen in regelmäßigen Zeitabständen sendet, um sicherzustellen, daß der Client nicht durch einen Eindringling ersetzt wurde, der beispielsweise nur die Telefonleitung umgeschaltet hat.

pppd speichert die geheimen Schlüssel für CHAP und PAP in zwei separaten Dateien namens /etc/ppp/chap-secrets und pap-secrets. Durch Eintragen eines entfernten Host in die eine oder andere Datei haben Sie die Kontrolle darüber, ob CHAP oder PAP bei der Authentisierung verwendet wird.

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

Dieses Verhalten kann auf verschiedene Weise angepaßt werden. Wird beispielsweise die Option auth verwendet, verlangt pppd von der Gegenseite eine Authentizierung. 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 Authentizierungs-Protokoll zurückgegriffen wird. Ich gehe 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 authentisieren, sollten Sie die Option auth in die globale Datei /etc /ppp/options aufnehmen und Paßwö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, daß keine unautorisierten Systeme mit Ihrem Host anbandeln.

Die nächsten beiden Abschnitte diskutieren 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 Paßwörtern, denen optional eine Liste mit IP-Adressen folgt. Die Interpretation der Client- und Server-Felder ist bei CHAP und PAP unterschiedlich und hängt auch davon ab, ob wir uns bei der Gegenseite authentizieren, oder ob wir den Server auffordern, sich bei uns zu authentizieren.

Die CHAP-Secrets-Datei

Wenn pppd sich über CHAP einem Server gegenüber ausweisen muß, durchsucht es die Datei chap-secrets nach einem Eintrag, bei dem das Client-Feld mit dem lokalen Hostnamen und das Server-Feld mit dem Hostnamen des Servers (während der CHAP-Anforderung mit übertragen) übereinstimmen. Muß sich die Gegenseite authentizieren, sind die Regeln einfach umgekehrt: 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 Server-Feld mit dem lokalen Hostnamen übereinstimmen.

Nachfolgend ein einfaches Beispiel einer chap-secrets-Datei für vlager:(9)

# 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  "riverrun, pasteve"   c3po.lucas.com
*                 vlager.vbrew.com  "VeryStupidPassword"  pub.vbrew.com
Wird eine PPP-Verbindung zu c3po aufgebaut, fordert c3po vlager auf, sich zu authentizieren, indem es eine CHAP-Anforderung überträgt. pppd durchsucht dann chap-secrets nach einem Eintrag, bei dem das Client-Feld vlager.vbrew.com und das Server-Feld c3po.lucas.com enthalten,(10) und findet dabei die erste oben aufgeführte Zeile. Daraufhin wird eine CHAP-Antwort aus dem Anforderungs-String und dem Secret (Use The Source Luke) erzeugt und an c3po geschickt.

Zur selben Zeit baut pppd eine CHAP-Anforderung für c3po auf, die einen eindeutigen Anforderungs-String 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 Client (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 und pppd kombiniert die CHAP-Anforderung und das Secret riverrun, pasteve, 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. Fordert beispielsweise c3po eine bestimmte Adresse während der IPCP-Vereinbarung an, die nicht in dieser Liste steht, wird diese Anforderung abgelehnt und IPCP wird beendet. Bei unserer oben aufgeführten Beispieldatei ist c3po also auf die Verwendung seiner eigenen IP-Adresse eingeschränkt. Ist das Adreßfeld 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 erlaubt es jedem Host, einen PPP-Link mit vlager aufzubauen, weil das Sternchen (*) als Platzhalter für jeden beliebigen Hostnamen steht. Die einzige Voraussetzung ist, daß er das Secret kennt und die Adresse von pub.vbrew.com verwendet. Einträge mit sochen 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 paßt.

pppd benötigt möglicherweise bei der Bildung von Hostnamen etwas Hilfe. Wie bereits vorher erläutert, ist der Name des anderen Host 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 bekanntgeben:

# pppd … domain vbrew.com
Das hängt den Domainnamen der Brauerei bei allen authentizierungsbezogenen 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 in 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 der 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 Authentizierung an, verwendet pppd den Eintrag, bei dem das Server-Feld mit dem lokalen Hostnamen und das Benutzerfeld mit dem in der Anforderung übertragenen Benutzernamen übereinstimmen. Wenn es sich selbst authentizieren muß, wählt sich pppd das Secret aus dem Eintrag aus, bei dem das erste Feld den lokalen Hostnamen und das Server-Feld den entfernten Hostnamen enthält.

Eine PAP-Secrets-Datei könnte beispielsweise wie folgt 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 Authentizierung verwendet, wenn wir mit c3po kommunizieren. Die zweite Zeile beschreibt, wie ein Benutzer namens c3po sich uns gegenüber zu authentizieren hat.

Der Name vlager-pap in der ersten Spalte ist der Benutzername, den wir an c3po senden. Per Standardeinstellung 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 Authentizierung mit der Gegenseite durchzuführen, muß pppd den Namen des anderen Host wissen. Weil es keine Möglichkeit hat, ihn herauszufinden, müssen Sie ihn mit Hilfe der Option remotename in der Kommandozeile mit angeben. Soll beispielsweise der obige Eintrag für die Authentizierung mit c3po verwendet werden, muß die pppd-Kommandozeile wie folgt aussehen:

# pppd ... remotename c3po user vlager-pap
Im vierten Feld (und in allen folgenden Feldern) 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 unserer Beispieldatei verlangen wir, daß c3po seine echte IP-Adresse benutzt.

Denken Sie daran, daß PAP eine eher schwache Authentizierungs-Methode ist, und daß 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.

Konfiguration eines PPP-Servers

Wenn Sie pppd als Server ausführen wollen, müssen Sie nur die entsprechenden Optionen in der Kommandozeile angeben. Stellen Sie sich vor, Sie generieren einen speziellen Account, z. B. ppp, dem Sie dann ein Skript oder ein Programm als Login-Shell zuweisen, das pppd mit den entsprechenden Optionen startet. Beispielsweise könnten Sie die folgende Zeile in die /etc/passwd einfügen:

ppp:*:500:200:Public PPP Account:/tmp:/etc/ppp/ppplogin
Natürlich können Sie andere UIDs und GIDs verwenden, als oben aufgeführt. Außerdem müssen Sie mit dem Befehl passwd noch das entsprechende Paßwort für diesen Account zuweisen.

Das Skript ppplogin könnte dann wie folgt aussehen:

#!/bin/sh
# ppplogin -- Skript zum automatischen Starten von pppd beim Login
mesg n
stty -echo
exec pppd -detach silent modem crtscts
Der Befehl mesg verhindert, daß 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 nochmal zurückgeschickt würden. Die wichtigste der oben angegebenen pppd-Optionen ist -detach, weil sie verhindert, daß 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, daß 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 Sie mit dem Senden beginnen. 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.

Neben diesen Optionen sollten Sie auch irgendeine Form der Authentizierung aktivieren. Dazu können Sie die Option auth in der pppd-Kommandozeile oder in den globalen Optionsdateien setzen. Die Manpage beschreibt auch spezifischere Optionen, mit denen Sie bestimmte Authentizierungs-Protokolle ein- und ausschalten können.


Fußnoten

(1)
Die relevanten RFCs sind in der Bibliographie am Ende dieses Buches aufgeführt.
(2)
Tatsächlich ist HDLC ein wesentlich allgemeineres Protokoll, das sich die International Standards Organization (ISO) ausgedacht hat.
(3)
Beide Autoren haben angedeutet, daß sie in naher Zukunft sehr beschäftigt sein werden. Wenn Sie irgendwelche Fragen zu PPP im allgemeinen haben, sollten Sie besser die Leute auf der linux-ppp-Mailing-Liste fragen.
(4)
karl@morningstar.com
(5)
Die Default-Netzwerkroute wird nur installiert, wenn noch keine vorhanden ist.
(6)
Wenn Sie syslog.conf so editieren, daß der Log in einer Datei gespeichert wird, müssen Sie darauf achten, daß diese Datei nicht von jedem gelesen werden kann, weil chat per Voreinstellung auch das gesamte Skript aufzeichnet einschließlich aller Paßwörter etc.
(7)
Die Verwendung von Hostnamen bei dieser Option hat Auswirkungen für die CHAP-Authentisierung. Mehr dazu finden Sie im Abschnitt zu CHAP in diesem Kapitel.
(8)
Sie können der anderen PPP-Seite erlauben, Ihre Vorstellung einer IP-Adresse zu überschreiben, indem Sie pppd mit den Optionen ipcp-accept-local und ipcp-accept-remote ausführen.
(9)
Die Anführungszeichen sind nicht Teil des Paßworts, sondern dienen nur dazu, die Leerzeichen innerhalb des Paßworts zu schützen.
(10)
Der Hostname stammt aus der CHAP-Anforderung.

Inhaltsverzeichnis Kapitel 7 Kapitel 9