Das Point-to-Point Protocol (PPP) ist unter anderem in den RFCs 1661, 1662, 1332 und 1334 definiert. Es wurde ursprünglich entwickelt, um Daten über serielle Leitungen zu verschicken. Es kann grundsätzlich für verschiedene Netzwerkprotokolle wie Apple, IP, IPX, usw. verwendet werden; unter Linux ist aber nur IP vorgesehen. PPP bietet verschiedene Features, wie z.B. den Austausch der IP-Nummern, Authentifizierung, Komprimierung und einige andere.
Aus diesem Grund findet zunächst durch das Link Control Protocol (LCP) ein Handshake statt, durch den die Verbindung initialisiert wird oder eben auch nicht. In der Praxis ergeben sich genau hierdurch die Probleme gemäß der Richtlinie das schöne an Standards ist, daß sich jeder seinen eigenen aussuchen kann.
Wer analoges PPP gewöhnt ist, muß hier ein wenig umdenken. Die Netzverbindung besteht logisch immer, gewählt wird aber nur bei Bedarf.
diald
chat
pppd
fährt hoch und macht Handshake mit Partnerifconfig
und route
Aufrufe durch pppd
/etc/ppp/options
/etc/ppp/options.DEVICE
,
wobei DEVICE
das aktuell verwendete serielle
Device ist.
isdnctrl
und ein
ifconfig
Aufrufipppd
wird gestartetisdnctrl
).ipppd
wird aktiviert; er läuft die ganze Zeitipppd
macht Handshakeipppd
das Device neu an und startet /etc/ppp/ip-up
.ipppd
ein
Reconnect auf das Device; der analoge PPP-Daemon beendet
sich.ipppd
/etc/ppp/ip-down
./etc/ppp/ioptions
Der Unterschied zwischen synchronem und asynchronem PPP ist das Framing, also das Einpacken der Rohdaten für die jeweilige Verbindungsart. SyncPPP packt in HDLC ein. Auf einer Modemstrecke bzw. einer seriellen Schnittstelle kann man aber nur zeichenweise arbeiten. Entsprechend packt asyncPPP seine Päckchen anders ein. Es gibt ein ausgewiesenes Byte, welches den Paketanfang bzw. das Ende markiert. Diese Byte muß, sofern es im Datenstrom auftaucht, natürlich anders dargestellt werden. Dafür gibt es ein weiteres reserviertes Byte, das Escape-Byte.
Nachfolgend wird gezeigt, wie die Netzwerkdevices angelegt und konfiguriert werden:
NETDEV='ippp0'
# neues Device
isdnctrl addif $NETDEV
# setzte MSN/EAZ
isdnctrl eaz $NETDEV 456
# def. Nummer(n) zum Rauswählen
isdnctrl addphone $NETDEV out 09011
# erlaube Nummern, die anrufen dürfen
#isdnctrl addphone $NETDEV in
# dürfen alle anrufen? Nein: setze secure=on
isdnctrl secure $NETDEV on
# Layer-2 Protokoll: (x75i, x75ui, x75bui, hdlc)
isdnctrl l2_prot $NETDEV hdlc
# Layer-3 Protokoll: (nur trans)
isdnctrl l3_prot $NETDEV trans
# Ecapsulation: (rawip, cisco_h, syncppp)
isdnctrl encap $NETDEV syncppp
# Idletime
isdnctrl huptimeout $NETDEV 60
# maximale Wählversuche
isdnctrl dialmax $NETDEV 5
# nur einen bestimmten Kanal benutzen
#isdnctrl bind $NETDEV
# PPP an Netzdevice binden
isdnctrl pppbind $NETDEV 0
# Netzdevice konfigurieren
ifconfig $NETDEV 1.1.1.1 pointopoint 193.102.150.13 up
# OPEN-Meldung ausgeben:
isdnctrl verbose 3
Gelöscht wird das Interface durch die Befehle:
ifconfig $NETDEV down
isdnctrl delif $NETDEV
Vor dem Start des ipppd
müssen drei Voraussetzungen
erfüllt sein:
isdnctrl addif
).Die syncPPP-Unterstützung des Kernels überprüft der ipppd
leider über eine etwas unglückliche Methode:
Es muß ein Device ippp0
vorhanden sein. Außerdem
kann man das Device nicht beliebig benennen, es muß mit
ippp
beginnen. Deshalb sollte man sich unbedingt
merken, als Devicenamen immer ippp0
zu verwenden.
Der ipppd
kann über 2,5 Arten Optionen annehmen:
/etc/ppp/ioptions
-file
).
In Anlehnung an den pppd
empfehle ich folgende Struktur:
ipppd
s sollten in
/etc/ppp/ioptions
gesetzt werden.ippp0
, sollte eine spezielle Datei wie
/etc/ppp/options.ippp0
verwendet werden.ipppd
wird so gestartet:
ipppd pidfile /var/run/ipppd.ippp0.pid \
file /etc/ppp/options.ippp0 &
Folgendes sollte man noch über den ipppd
wissen:
pppd
benutzt; zu den Unterschieden siehe man ipppd
.ipppd
s laufen und diese neu starten.ipppd
auf ein Device
reagieren, daher pppbind
. /etc/ppp/ioptions
muß existieren.Folgende Optionen haben sich für die verschiedensten ISPs als stabil erwiesen:
# /etc/ppp/options.ippp0
#
# für isdn4linux/syncPPP und dynamische IP-Nummern
#
#
# Klaus Franken, kfr@suse.de
# Version: 27.08.97 (5.1)
#
# Diese Datei wird von YaST von /etc/ppp/ioptions.YaST
# nach options.<device> kopiert.
# die Device(s)
# für mehr als ein Device versuche folgendes:
# /dev/ippp0 /dev/ippp1 ...
/dev/ippp0
# die IP-Adresse: <lokal>:<remote>
# einfach "0.0.0.0:" oder nichts für dyn. IP
#0.0.0.0:
# der eigene Benutzername
user suse
# der eigene Systemname (nur für CHAP!)
# name my_system_name
# IP-Adressen vom Partner akzeptieren
# dynamische IP-Nummern verwenden
ipcp-accept-local
ipcp-accept-remote
noipdefault
# versuche, die IP-Adresse vom Interface zu ermitteln
# nur mit statischer IP-Adresse verwenden
#useifip
# alle Header-Komprimierungen abschalten
-vj
-vjccomp
-ac
-pc
-bsdcomp
# manchmal wird dies benötigt:
#noccp
# max receive unit
mru 1524
# max transmit unit
mtu 1500
# Wenn es sich bei dem Rechner um einen Server handelt,
# können sie durch Entfernen des Kommentarzeichens bei
# einem der folgenden Einträge eine Authentifizierung
# erzwingen. Wenn der Rechner jedoch als Client ver-
# wendet wird, würde das eine erfolgreiche Verbindung
# verhindern (Meldung: "peer refused to authenticate").
#
# "+pap" / "+chap" NUR AKTIVIEREN, WENN DIES EIN
# SERVER IST!!!
#+pap
#+chap
# Wenn es Problem mit dem Handshaking gibt (keine
# Antwort auf das erste lcp-Paket), sollte versucht
# werden, den Wiederholungszyklus zu verringern.
# Der Standard sind drei Sekunden, versuche z.B.
# zwei Sekunden:
# lcp-restart 2
Der ipppd
verhält sich bei der Benutzerauthentifizierung
exakt genauso wie der pppd
. Daher erfolgt hier nur ein
kurzer Abriß.
Es stehen zwei Methoden zur Verfügung: PAP und CHAP. Meistens wird PAP angeboten; über CHAP kann man im PPP HOWTO nachlesen.
Die Benutzerdaten werden an zwei Stellen konfiguriert;
als erstes wird dem ipppd
durch das Schlüsselwort
user
mitgeteilt, welche UserID dem gegnerischen
PPP-Daemon angeboten werden soll.
Als nächstes wird das Paßwort selbst als Klartext in
der Datei /etc/ppp/pap-secrets
abgelegt.
Diese Datei darf nur für root lesbar sein. Also passe
unbedingt die Rechte an:
chmod 600 /etc/ppp/pap-secrets
Für jeden verwendeten User wird eine Zeile eingetragen;
z.B. sei der Benutzername suse
und das Paßwort
linux
:
# client server pw iplist
"suse" * "linux"
Dies ist die einzige Stelle, an der das
Paßwort definiert ist. In der Datei /etc/ppp/pap-secrets
können mehrere User/Paßwörter definiert sein, über die Option
user
wird jeweils die richtige Zeile ausgewählt, um
das Paßwort zu ermitteln.
Der Benutzername muß nicht im System bekannt sein, zumindest besteht zwischen dem PAP- oder CHAP-Benutzernamen und dem Systembenutzer kein Zusammenhang.
Nachdem der ipppd
gestartet ist und eventuell eine Route
darüber definiert ist, wird bei Bedarf automatisch ein
Wählvorgang ausgelöst. Manuell kann man dies so auslösen:
isdnctrl dial ippp0
Meldungen werden über syslog nach /var/log/messages
geschrieben.
Folgende Daten sollte man kennen, die meisten sollte der ISP zur Verfügung stellen.
Es sollte syncPPP sein.
Natürlich benötigt man die Telefonnummer des Providers.
Mit welcher meiner Telefonnummern möchte/muß ich wählen, siehe dazu Abschnitt Was ist meine MSN?.
Wenn man feste IP-Nummern hat, gibt der ISP zumindest die persönlichen an. Die IP-Nummer auf der anderen Seite der PtP-Verbindung, also die des ISPs, kennt man deswegen noch nicht unbedingt. In einem solchen Fall gibt man wie bei dynamischen IP-Nummern irgendeine IP-Nummer vor und läßt eine Verbindung herstellen, damit man die wirkliche IP-Nummer sieht, die man dann fest einträgt.
Bei dynamischen IP-Nummern trägt man irgendwelche Nummern ein; siehe Abschnitt Probleme mit dynamischen IP-Nummern.
PAP oder CHAP
Natürlich muß man den Benutzernamen und das passende Paßwort auf dem PPP-Server kennen.
Die IP-Nummer des zu verwendenden Nameservers sollte man vom ISP mitgeteilt bekommen. Ansonsten siehe
http://www.suse.de/Support/sdb/nonameserver.html
Mit folgenden weiteren Parametern kann man die ISDN-Verbindung steuern:
Nach wie vielen Sekunden Inaktivität soll aufgelegt werden. Will man dieses Feature abstellen, kann man die Zeit auf »0« stellen.
Diese Zeitangabe ist jedoch nicht exakt.
Wie oft soll gewählt werden, wenn der Gegner nicht abnimmt?
Diese Anzahl gilt nicht, wenn es Hardwareprobleme gibt; zieht man z.B. das ISDN-Kabel, wird unendlich oft probiert.
Diese Anzahl gilt nicht, wenn die Wählverbindung zustande kam, aber die PPP-Verbindung nicht aufgebaut werden konnte. Ist z.B. das Paßwort falsch eingetragen, wird immer wieder eine Verbindung aufgebaut, solange Pakete verschickt werden.
In diesem Fall soll keiner die Verbindung von außen aufbauen
dürfen, deshalb sollte man keine eingehende Telefonnummer
angeben und die Option secure
bzw.
Nur angegebene Nummern erlaubt aktivieren.
Mehr zum Thema Callback findet sich in
/usr/doc/packages/doc/rc.config.i4l.add
Die Konfiguration bis auf's Routing wird in der Datei
/etc/rc.config
eingetragen, dies kann manuell oder
über YaST geschehen.
Um PPP über YaST zu konfigurieren, geht man so vor:
ippp0
gibt. Mit F5
wählt man den Netzwerktyp aus,
hier also ISDN SyncPP.F6
vergibt man die IP-Nummern,
siehe Abschnitt
Welche IP-Nummer setze ich denn eigentlich?,
und kann auch direkt das Default-Gateway angeben,
siehe Abschnitt
Routing.F8
werden nun die ISDN-relevanten Daten
eingetragen.
Nachdem man das Device aktiviert hat, kann man es in
der ISDN-Maske direkt hochfahren mit: Starten.Damit sind die rc.config
-Variablen, die PPP-Optionen,
die Paßwortdatei und das Routing angepaßt.
Durch folgende Variablen in
/etc/rc.config
wird eine syncPPP-Verbindung
gesteuert, hier als echtes Beispiel (mit _0
):
IPADDR_2="1.1.1.1"
NETDEV_2="ippp0"
IFCONFIG_2="1.1.1.1 pointopoint 193.102.150.13 up"
I4L_IDLETIME_2="60"
I4L_DIALMAX_2="5"
I4L_LOCALMSN_2="7417559"
I4L_REMOTE_OUT_2="52145922"
I4L_REMOTE_IN_2=""
I4L_ENCAP_2="syncppp"
I4L_SECURE_2="on"
Die Bedeutung der Felder ist oben angegeben;
in der /etc/rc.config
sind auch vor den Feldern
entsprechende Kommentare.
Es können beliebig viele Netzdevices definiert werden,
auch wenn standardmäßig nur vier angegeben sind, die jeweils
durch eine Extension wie z.B. _2
gekennzeichnet werden.
Dabei müssen nicht alle aktiv sein. Welche aktiviert
werden sollen, wird in der Variablen NETCONFIG
festgelegt; sollen z.B. _0
und _2
aktiv sein,
setzt man: NETCONFIG="_0 _2"
.
Als nächstes muß der ipppd
konfiguriert werden.
Hierzu erstelle man
eine Datei /etc/ppp/options.ippp0
(siehe Abschnitt
PPP-Optionen); am besten in
dem Du die Datei
/etc/ppp/ioptions.YaST
kopierst.
In der Optionendatei muß der Benutzername gesetzt werden
und überprüft werden, ob das Device stimmt.
Dann trägst Du das Paßwort passend zum Benutzernamen in
/etc/ppp/pap-secrets
ein.
Das manuelle Starten ist in Abschnitt ipppd starten beschrieben.
Bei Problemen sollte man folgende Checkliste durchlaufen:
ipppd
überhaupt gestartet?
Kontrolliere mit
ps ax | grep ipppd
ob einer
läuft bzw. wieviele laufen.
Kontrolliere in /var/log/messages
die Startmeldungen,
z.B.:
syslog: info: no CHAP secret entry for this user!
ipppd[536]: Found 1 devices: /dev/ippp0,
ipppd[540]: ipppd i2.2.9 (isdn4linux version of pppd by MH) started
ipppd[540]: init_unit: 0
ipppd[540]: Connect[0]: /dev/ippp0, fd: 8
ipppd
prüft schon beim Start, mit welchem Usernamen
gearbeitet wird (user suse
). Zu diesem Namen
wird das entprechende Paßwort gelesen. Klappt das nicht,
wird eine Meldung ausgegeben, z.B.:
Apr 9 20:32:17 glen syslog: info: no PAP secret entry for this user!
In diesem Fall wird eine Einwahl mittels PAP nicht
funktionieren, die 12 Pfennige kann man sich also sparen.
Ursache ist meist ein Tippfehler beim Benutzernamen oder
falsche Permisssions der pap-secrets
.
Analoges gilt für CHAP.
connect
-Meldung.
Wird keine Verbindung aufgebaut, gibt es vermutlich
eine cause
-Meldung, siehe Abschnitt
Cause Meldungen.
Erscheinen nur dialing
-Meldungen, aber sonst nichts,
liegt es an der Hardware oder am Hardware-Modul,
siehe die Abschnitte
Hardware testen und
Installation.
ipppd[540]: local IP address 149.228.142.59
ipppd[540]: remote IP address 193.102.150.13
Sieht man diese Meldungen, dann Glückwunsch! Der
Gegner wird ab jetzt zum Partner.
select: Bad file number
Direkt nach der Ausgabe der IP-Nummern erscheint:
ipppd[353]: select: Bad file number
ipppd[353]: Couldn't restore device fd flags: Bad file number
ipppd[353]: Exit.
Was hat es damit auf sich? Zunächst einmal, die Verbindung
ist trotz allem aufgebaut.
Die Ursache ist folgende: der ipppd
startet beim
Connect bzw. Disconnect das
Skript /etc/ppp/ip-up
bzw. ip-down
.
Aufgrund eines kleinen Fehlers im offiziellen ipppd
,
der in der CVS-Version und ab SuSE 5.2 behoben ist, ist die
Überprüfung auf Ausführbarkeit fehlerhaft, woraufhin
trotzdem versucht wird, das Skript zu starten.
Nach der Fehlermeldung passiert genau nichts.
Allerdings sollte die Meldung trotzdem beachtet werden,
denn da wir dynamische IP-Nummern benutzen, muß das
Routing angepaßt werden, was genau über diese Skripte
geschehen soll, die hier nicht vorhanden sind.
/var/log/messages
meist nur, daß die Gegenstelle
aufgelegt hat. Um den Grund für das Problem zu ermitteln,
braucht man mehr Meldungen vom LCP. Dazu trägt man in
/etc/ppp/ioptions
folgendes ein
# Definiere "debug", um möglichst viele Informationen
# in /var/log/messages zu erhalten.
debug
# Definiere "+pwlog", um auch Paßworter in
# /var/log/messages zu speichern
#+pwlog
und startet den ipppd
neu.
Durch debug
werden die LCP-Messages ausgegeben,
durch +pwlog
kann man sich zusätzlich das
verschickte Paßwort angeben lassen - letzteres wird nur
empfohlen, wenn ansonsten alles richtig scheint, denn
wenn jemand fremdes Zugriff auf /var/log/messages
bekäme, hätte man ein echtes Problem.
Häufige Ursachen für Probleme sind:
In diesem Fall wird etwas in dieser Art protokolliert:
ipppd[10314]: sent [0][PAP AuthReq id=0x1 user="kfr" password="falsch"]
ipppd[10314]: rcvd [0][PAP AuthNak id=0x1msg=""]
ipppd[10314]: Remote message:
ipppd[10314]: PAP authentication failed
Richtig sollte es so aussehen:
ipppd[7840]: sent [0][PAP AuthReq id=0x1 user="kfr" password="isdnworkshop"]
ipppd[7840]: rcvd [0][PAP AuthAck id=0x1msg=""]
ipppd[7840]: Remote message:
ipppd[7840]: bundle, he: 0 we: 0
Normalerweise werden LCP-Messages gesendet und empfangen, um das Handshaking durchzuführen (send, rcvd):
ipppd[10314]: sent [0][LCP ConfReq id=0x1 <mru 1524> <magic0x93ade903>]
ipppd[10314]: rcvd [0][LCP ConfReq id=0x1 <mru 1524> <auth pap>
<MPdiscr: 0x3 [ 00 c0 7b 70 d5 fa ]>]
Wenn die Gegenseite nicht antwortet, kann es sein, daß
sie nicht schnell genug hochkommt (lcp-restart
erhöhen) oder kein passender PPP-Daemon dort läuft.
Ist dies nicht nur ein temporäres Problem, ist entweder
die Nummer falsch, oder der ISP bietet tatsächlich kein
syncPPP an.
Im letzteren Fall muß man asyncPPP fahren, siehe:
http://www.suse.de/Support/sdb/ppp_async.html
Hierbei sollte man am Protokoll erkennen, welche
Optionen angefordert oder abgewiesen werden. Danach
bleibt einem nur der mühsame Weg, diese Optionen
zu setzen/deaktivieren, siehe Beispiel-Optionsfile
und man ipppd
.
peer refused to authenticate
Man hat selbst +pap
oder +chap
angegeben.
Ein häufiges Mißverständnis: Diese Optionen geben
an, daß man selber der Authentifizierungs-Server sein
möchte, nicht, daß man PAP oder CHAP benutzen möchte;
letzteres geschieht nur implizit durch die
Angabe von user
,
name
und den Eintragungen in
pap-secrets
bzw. chap-secrets
.
ipppd
mit
der Ausgabe von ifconfig
. Die IP-Nummern
müssen übereinstimmen und gegenüber der Grundeinstellung
verändert sein.route -n
,
siehe Abschnitt
Routing. Es muß eine Hostroute für den
PtP-Partner gesetzt sein.ping 193.102.150.13
.
Ziel dieser Übung ist, ein PPP-Verbindung aufzubauen und zu testen (kein Routing).