Point-to-Point Protocol (PPP) ist u.a. in den
RFCs 1661, 1662, 1332 and 1334 definiert.
Es wurde ursprünglich entwickelt, um Daten über serielle Leitungen
zu verschicken. Es bietet grundsätzlich auch weitere Netzwerkprotokolle
(Apple, IPX, ...) unter Linux ist aber nur IP vorgesehen.
PPP bietet verschiedene Features wie z.B. den Austausch der IP-Nummern,
Authentication, Compressions etc.
Aus diesem Grund findet zunächst durch das Link Control Protocol
(LCP) ein Handshake statt, durch den die Verbindung initialisisert
wird (oder 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 umdenken.
Bei ISDN dreht sich alles um.
Die Netzverbindung besteht logisch immer, gewählt wird aber nur
bei Bedarf.
Analog:
manuelles starten eines Scripte oder über diald
wählen, z.B. mit 'chat'
pppd fährt hoch und macht Handshake mit Partner
ifconfig und route Aufrufe durch pppd
Optionsfile: /etc/ppp/options
liest automatisch /etc/ppp/options.DEVICE
(DEVICE ist das aktuell verwendete serielle Device).
ISDN:
Netz wird konfiguriert, diverse isdnctrl und ein
ifconfig Aufruf
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 characterweise verschicken. Entsprechend packt asyncPPP
seine Päckchen anders ein. Es gibt ein ausgewiesenes
Byte welches den Paketanfang bzw. das Ende markiert.
Diese Byte muss, sofern es im Datenstrom auftaucht natürlich
anders dargestellt werden. Dafür gibt es ein weiteres
reserviertes Byte, das Escape-Byte.
NETDEV='ippp0'
# neues Device
isdnctrl addif $NETDEV
# setzte MSN/EAZ
isdnctrl eaz $NETDEV 456
# def. Nummer(n) zum rauswaehlen
isdnctrl addphone $NETDEV out 09011
# erlaube Nummern, die anrufen duerfen
#isdnctrl addphone $NETDEV in
# duerfen alle anrufen? Nein: setze secure=on
isdnctrl secure $NETDEV on
# Layer-2 Protokoll: (x75i, x75ui, x75bui, hdlc)
isdnctrl l2_prot $NETDEV hdlc
# Layer-3 (nur trans)
isdnctrl l3_prot $NETDEV trans
# Ecapsulation: (rawip, cisco_h, syncppp)
isdnctrl encap $NETDEV syncppp
# Idletime
isdnctrl huptimeout $NETDEV 60
# maximale Waehlversuche
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
ipppd starten
Vor dem Start des ipppd müssen drei Voraussetzungen
erfüllt sein:
ISDN-Hardwareunterstützung
syncPPP Untersützung im Kernel
Das zu verwendene Device muß angelegt sein
(isdnctrl addif)
Die syncPPP Unterstützung des Kernels prüft der ipppd
leider über eine etwas unglücklich Methode ab:
Es muß ein Device ippp0 vorhanden sein. Außerdem
kann man das Device nicht beliebig benennen, es muß mit
ippp beginnen. Merke: Benutze immer als Devicename
ippp0
Der ipppd kann über 2,5 Arten Optionen annehmen:
Kommandozeilenparameter
Das Optionsfile /etc/ppp/ioptions
Die 2,5te Methode ist die Angabe eines Optionsfile als
Kommandozeilenparameter (-file).
In Anlehnung an den pppd empfehle ich folgende Struktur:
Globale Optionen (für alle ipppd's) in
/etc/ppp/ioptions
Devicespezifische Optionen (z.B. für ippp0) in
/etc/ppp/options.ippp0
Start des ipppd mit
ipppd pidfile /var/run/ipppd.ippp0.pid file /etc/ppp/options.ippp0 &
Folgendes sollte man noch über den ipppd wissen:
Es werden z.T. andere Optionen als beim pppd
benutzt, zu den Unterschieden siehe man ipppd
Die Optionen und Paßwörter werden nur beim Start
neu eingelesen.
Beim Testen sollte man also immer nachschauen, ob
noch ipppd'd laufen und neustarten.
Es können verschiedene ipppd auf ein Device
reagieren, daher pppbind.
Die Datei /etc/ppp/ioptions muß existieren.
Folgende Optionen haben sich für die verschiedensten ISP's
als stabil erwiesen:
# /etc/ppp/options.ippp0
#
# for isdn4linux/syncPPP and dynamic IP-numbers
#
#
# Klaus Franken, kfr@suse.de
# Version: 27.08.97 (5.1)
#
# This file is copy by YaST from /etc/ppp/ioptions.YaST
# to options.<device>
# The device(s)
# for more than one device try:
# /dev/ippp0 /dev/ippp1 ...
/dev/ippp0
# The IP addresses: <local>:<remote>
# just "0.0.0.0:" or nothing for dynamic IP
#0.0.0.0:
# my user name
user suse
# my system name (only for CHAP!)
# name my_system_name
# accept IP addresses from peer
# use with dynamic IP
ipcp-accept-local
ipcp-accept-remote
noipdefault
# try to get IP address from interface
# option specific to ipppd (as opposed to pppd)
# use only with static IP
#useifip
# disable all header-compression
-vj
-vjccomp
-ac
-pc
-bsdcomp
# sometimes you need this:
#noccp
# max receive unit
mru 1524
# max transmit unit
mtu 1500
# If this machine is a server, force authentication by uncommenting one
# of the following. However, if this machine is a client, doing this will
# prevent a succesful connection! (message "peer refused to authenticate").
# So, only uncomment on a server.
# "+pap" / "+chap" NUR AKTIVIEREN, WENN DIES EIN SERVER IST!!!
#+pap
#+chap
# if you have problems with handshaking (no response for first
# lcp-package) try to decrease the retry-cycle. Default is 3 sec,
# try for example 2 sec:
# lcp-restart 2
Authentifizierung beim ipppd
Der ipppd verhält sich bei der Benutzerauthentifizierung
exakt genauso wie der pppd. Daher nur ein kurzer
Abriss.
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 wird dem ipppd durch das Schlüsselword user
mitgeteilt, welche User-Id dem gegnerischen PPP-Daemon
angeboten werden soll.
Als nächstes wird das Passwort selbst (in Klartext) in
der Datei /etc/ppp/pap-secrets abgelegt.
Diese Datei darf nur für root lesbar sein! Also
chmod 600 /etc/ppp/pap-secrets.
Für jeden verwendeten User wird eine Zeile eingetragen,
z.B. sei der Username suse und Passwort linux:
# client server pw iplist
"suse" * "linux"
Dies ist die einzige Stelle, wo der Username und das
Passwort definiert ist (sein sollte).
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 ev. eine Route
darüber definiert ist, wird bei Bedarf automatisch ein
Wählvorgang ausgelöst. Manuell kann man dies auslösen
durch isdnctrl dial ippp0.
Meldungen werden über syslog nach /var/log/messages
geschrieben.
Welche Daten muß ich über den Zugang kennen?
Folgende Daten sollte man kennen, die meisten sollte der
ISP zur Verfügung stellen.
Protokoll
Es sollte syncPPP sein.
Telefonnummer des ISP
klar...
meine MSN
Mit welcher meiner Telefonnummern möchte/muß ich wählen,
siehe
Was ist meine MSN?.
IP-Nummern
Wenn man feste IP-Nummern hat, gibt der ISP zumindest
die persönlich an, die IP-Nummer des PtP (also die des
ISP) kennt deswegen noch nicht unbedingt. In diesem
Fall, gibt man irgendeine ein (wie bei dynamischen)
und läßt eine Verbingung herstellen, damit sieht man
die IP-Nummer, die man dann hier fest einträgt.
Mit folgenden weiteren Parametern, kann man die ISDN-Verbindung
steuern.
Idle-Time
Nach wie vielen Sekunden Inaktivität soll aufgelegt
werden. Will man dieses Feature abstellen, kann man
die Zeit auf 0 stellen.
Hinweis: Diese Zeitangabe ist nicht exakt.
Maximale Wählversuche
Wie oft soll gewählt werden, wenn der Gegner nicht
abnimmt?
Hinweis: Diese Anzahl gilt nicht, wenn es Hardwareprobleme
gibt, zieht man z.B. das ISDN-Kabel, wird unendlich oft
probiert.
Hinweis: Diese Anzahl gilt nicht, wenn die Wählverbindung
zustandekam, aber die PPP-Verbindung nicht aufgebaut werden
konnte. Ist z.B. das Passwort falsch eingetragen, wird
immer wieder eine Verbindung aufgebaut, solange Pakete
verschickt werden.
einkommende Telefonnumern
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 angegeben Nummern erlaubt aktivieren.
Die Konfiguration wird in der Datei /etc/rc.config
eingetragen (ausser Routing), dies kann manuell oder
über YaST geschehen.
Konfiguration mit YaST:
Menüpunkt Administration des Systems,
Netzwerk konfigurieren und Netzwerk Grundkonfiguration
auswählen.
Es erscheint eine Maske der konfigurierten
Netzdevices, wähle ein freies aus (sofern es nicht schon
ippp0 gibt. Mit F5 wählt man den Netzwerktyp aus,
hier also ISDN SyncPP.
Mit 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-Options,
die Passwortdatei und das Routing angepasst.
manuelle Konfiguration:
Durch folgende Variablen in
/etc/rc.config wird eine syncPPP-Verbindung
gesteuert, hier als echtes Bsp. (mit _0):
Erklärung: 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 per Default nur 4 angegeben sind), die jeweils
durch eine Extension, z.B. _2 gekennzeichnet werden.
Dabei müssen nicht alle aktiv sein. Welche aktiviert
werden sollen, wird in der Variablen NETCONFIG
gesteuert, sollen z.B. _0 und _2 aktiv sein,
setzt man: NETCONFIG="_0 _2".
Als nächstes muß der ipppd konfiguriert werden, erstelle
eine Datei /etc/ppp/options.ippp0
(siehe
PPP-Optionen) am besten in
dem Du
/etc/ppp/ioptions.YaST kopierst.
In der Optionsdatei, setzte den Usernamen und prüfe, ob das
Device stimmt.
Dann trägst Du das Passwort passend zum Usernamen in
/etc/ppp/pap-secrets ein.
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
Stimmen die Benutzerdaten?
Der ipppd prüft schon beim Start, mit welchen Usernamen
gearbeitet wird (user suse), zu diesem Namen
das entprechende Passwort gelesen. Klappt das nicht,
wird eine Meldung ausgegen, 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.
Wird überhaupt eine Verbindung aufgebaut?
Sobald die Gegenstelle abnimmt (und damit Kosten
entstehen) erscheint eine connect-Meldung.
Wird keine Verbindung aufgebaut, gibt es vermutlich
eine cause-Meldung. Siehe:
Cause Meldungen.
Erscheinen nur dialing-Meldungen, aber sonst nichts,
liegt es an der Hardware oder am Hardware-Modul,
siehe
Hardware testen und
Installation.
Klappt die Einwahl?
Bei Erfolgreicher Einwahl erscheinen Meldungen über die
IP-Nummern, z.B.:
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 ercheint:
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.
Ursache: der ipppd startet beim (Dis-) Connect das
Script /etc/ppp/ip-up (ip-down).
Aufgrund eines kleinen Fehlers im offiziellen ipppd
(behoben in der CVS-Version und ab S.u.S.E. 5.2) ist die
Abprüfung auf Ausführbarkeit fehlerhaft, woraufhin
trotzdem versucht wird das Script zu starten.
Nach der Ferhlermeldung passiert genau nichts.#
Allerdings sollte die Meldung trotzdem beachtet werden,
denn da wir dynamische IP-Nummer benutzen, muß das
Routing angepasst werden, was genau über diese Scripte
geschehen soll, die hier nicht vorhanden sind.
Die Einwahl klappt nicht:
Wenn die Einwahl nicht klappt, sieht man in
/var/log/messages meist nur, daß die Gegenstelle
aufgelegt hat, um den Grund dafür zu ermitteln, braucht man
mehr Meldungen vom LCP. Dazu trägt man in
/etc/ppp/ioptions folgendes ein:
# Set 'debug' to create a lot of information in /var/log/messages
debug
# Set '+pwlog' for logging passwords in /var/log/messages
#+pwlog
und startet den ipppd neu.
Durch debug werden die LCP-Messages ausgegeben,
durch +pwlog kann man sich zusätzlich das
verschickte Passwort angeben lassen - letzteres ist nur
empfohlen, wenn ansonsten alles richtig scheint, denn
wenn jemand fremndes Zugriff auf /var/log/messages
bekommt...
Häufige Ursachen:
Username/Passwort falsch:
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
Wenn die Gegenseite nicht antwortet, kann es sein, daß
sie nicht schnell genug hochkommt (lcp-restart
erhöhen), oder kein (sync-) 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.
Noch während der LCP-Messages legt die Gegenstelle
auf.
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 Bsp-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 Authetication-Server sein
möchte, nicht daß man PAP oder CHAP benutzen möchte;
letzteres geschieht nur implizit durch Angabe user,
name und den Eintragungen in
pap-secrets bzw. chap-secrets.
Die Einwahl klappt, weitere Tests:
Zunächst vergleiche man die Ausgabe des ipppd mit
der Ausgabe von ifconfig. Die IP-Nummern
müssen übereinstimmen (und gegenüber der Grundeinstellung
verändert sein).
Ist das Routing richtig gesetzt? Prüfe route -n.
Siehe
Routing.
Es muß eine Hostroute für den
PtP-Partner gesetzt sein.
Versuche die Gegenstelle anzupingen,
z.B. ping 193.102.150.13.
Warte, bis die Verbindung automatisch abbricht und
prüfe die Routingtabelle erneut.