Weiter Zurück Inhalt

5. syncPPP Verbindung herstellen

Point-to-Point Protocol (PPP) ist u.a. in den RFCs 1332, 1334, 1570, 1661, 1662, 1994 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 initialisiert 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.

5.1 Unterschiede analog - ISDN

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:

ISDN:

5.2 Was ist eigentlich synchrones PPP

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.

5.3 Die Konfiguration

Netzdevices anlegen und konfigurieren

Beispiel:

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:

  1. ISDN-Hardwareunterstützung
  2. syncPPP Untersützung im Kernel
  3. Das zu verwendende 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:

  1. Kommandozeilenparameter
  2. 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:

Folgendes sollte man noch über den ipppd wissen:

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)
# Umstellung auf CHAP: 26.05.99 kfr@klaus.franken.de
# 
# 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 (to force PAP instead of CHAP)
# user suse

# my system name 
name suse

# 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 Abriß.

Es stehen zwei Methoden zur Verfügung: PAP und CHAP. Hier wird es so konfiguriert, daß automatisch beides funktioniert. Siehe auch PAP oder CHAP?.

Die Benutzerdaten werden an zwei Stellen konfiguriert; als erstes wird dem ipppd durch das Schlüsselwort name mitgeteilt, welche User-Id dem gegnerischen PPP-Daemon angeboten werden soll.

Als nächstes wird das Passwort selbst (im Klartext) in der Datei /etc/ppp/pap-secrets abgelegt.

Für jeden verwendeten User wird eine Zeile eingetragen, z.B. sei der Username suse und Passwort linux:

# client        server  pw              iplist
"suse"          *       "linux"
            
Diese Datei darf nur für root lesbar sein! Also
chmod 600 /etc/ppp/pap-secrets

Dies ist die einzige Stelle, wo das Passwort definiert ist. In der /etc/ppp/pap-secrets können mehrere User/Passwörter definiert sein, über die Option user bzw. name wird jeweils die richtige Zeile extrahiert, um das Passwort zu ermitteln.

Als nächstes wird die chap-secrets auf die pap-secrets gelinkt:

cd /etc/ppp
ln -s pap-secrets chap-secrets
            

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.

Sonderzeichen im Usernamen oder Passwort

Normalerweise brauchen Username und Passwort nicht in Anführungszeichen eingeschlossen werden.

Sind aber Sonderzeichen wie z.B. # darin enthalten, muß man die Anführungszeichen setzen.

Enthält der Username oder das Passwort allerdings das Anführungszeichen selbst, dann darf man widerum keine Anführungszeichen drumherum setzen!

PAP oder CHAP?

PAP und CHAP sind beides zwei Authentifizierungsmethoden für den PPP-Daemon. Wenn man die Wahl hat, sollte man CHAP bevorzugen, da hierbei die Daten (insbesondere das Passwort!) verschlüsselt übertragen werden. Der Aufbau der Dateien /etc/ppp/pap-secrets und /etc/ppp/chap-secrets sind nahezu identisch, von daher wurden sie oben verlinkt.

Wenn der PPP-Daemon keine Authentifizierung mit CHAP durchführen kann, wird automtisch versucht mit demselben Benutzernamen wie unter name angegeben eine PAP-Authentifizierung durchzuführen.

Will man die Authentifizierung mit PAP erzwingen (z.B. um den Verbindungsaufbau zu beschleunigen), setzt man den Benutzernamen hinter das Keyword user und kommentiert das Keyword name mit einem # aus (Datei /etc/ppp/options.ippp0).

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 Verbindung herstellen, damit sieht man die IP-Nummer, die man dann hier fest einträgt.

Bei dynamischen IP-Nummern, trägt man irgendwelche ein, siehe Probleme mit dynamischen IP-Nummern.

Authentication-Typ

PAP oder CHAP. Siehe auch PAP oder CHAP?.

Username, Passwort

klar ...

Nameserver

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.

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 angegebene Nummern erlaubt aktivieren.

Callback

mehr dazu siehe in

/usr/doc/packages/doc/rc.config.i4l.add

PPP bei S.u.S.E. einrichten

Die Konfiguration wird in der Datei /etc/rc.config eingetragen (außer Routing), dies kann manuell oder über YaST geschehen.

Hinweis: SuSE/YaST richtet als Authentifizierungsmethode lediglich PAP ein, wer CHAP braucht, siehe PAP oder CHAP?.

Konfiguration mit YaST:

Damit sind die rc.config-Variablen, die PPP-Options, die Passwortdatei und das Routing angepaßt.

manuelle Konfiguration:

Durch folgende Variablen in /etc/rc.config wird eine syncPPP-Verbindung gesteuert, hier als echtes Bsp. (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"
                
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.

Zum manuellen Starten, siehe: ipppd starten

5.4 Probleme beim Verbindungsaufbau, Troubleshooting.

Checkliste:

  1. Wurde der 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
                
    
  2. Stimmen die Benutzerdaten?

    Der ipppd prüft schon beim Start, mit welchem Usernamen gearbeitet wird (user suse), zu diesem Namen wird das entprechende Passwort 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.

  3. 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.

  4. 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.

  5. 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 angepaßt werden, was genau über diese Scripte geschehen soll, die hier nicht vorhanden sind.

  6. 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:

  7. Die Einwahl klappt, weitere Tests:

5.5 Übung: syncPPP-Verbindung herstellen

Ziel: PPP-Verbindung aufbauen und testen (kein Routing)

  1. Stelle eine Verbindung zu einem syncPPP-Server her. Wenn Du keinen anderen kennst, benutze den S.u.S.E. ISDN-Testrechner mit folgenden Daten:
  2. Gehe die Checkliste durch und führe die dortigen Tests aus, siehe syncPPP Troubleshooting
  3. Prüfe die IP-Nummer(n) des Servers, wenn diese fest ist, ändere die Konfiguration entsprechend.


Weiter Zurück Inhalt