Pour valider le fonctionnement de l'interface RNIS avec le protocole PPP, on utilise les postes de travaux pratiques
par paires. Dans ce contexte, les deux modes : client et serveur ne
se distinguent que par l'attribution d'adresses IP.
C'est le serveur qui doit fournir les adresses données dans le
tableau ci-dessous.
Tableau 1. Plans d'adressage IP
et RNIS des liaisons WAN
Bus
Serveur PPP
N° tél.
Adresses IP serveur:client
N° tél.
Client PPP
S0.1
alderaan
104
192.168.104.1:192.168.105.2
105
bespin
S0.2
centares
106
192.168.106.1:192.168.107.2
107
coruscant
S0.3
dagobah
108
192.168.108.1:192.168.109.2
109
endor
S0.4
felucia
110
192.168.110.1:192.168.111.2
111
geonosis
S0.5
hoth
112
192.168.112.1:192.168.113.2
113
mustafar
S0.6
naboo
114
192.168.114.1:192.168.115.2
115
tatooine
Attention, les adresses données dans ce tableau étant utilisées
par des liens point à point, le masque réseau occupe les 32 bits de
l'espace d'adressage.
Saisie des options du démon PPP
Pour l'ensemble de ces travaux pratiques, les options du
gestionnaire de connexion PPP
ipppd doivent être
saisies directement sur la ligne de commande. Il faut s'assurer que
les fichiers /etc/ppp/ioptions* sont
vides. Dans le cas contraire, les paramètres contenus dans ces
fichiers peuvent être utilisés par défaut sans tenir compte de ceux
saisis sur la ligne de commande.
4.1. Sans
authentification
Q4.
Quelles sont les options de configuration à
fournir au gestionnaire de connexion pour ce mode de fonctionnement
?
Consulter les pages de manuels du démon ipppd.
Le protocole PPP n'a pas été
conçu suivant le modèle Client/Serveur. Il suppose que deux
processus pairs échangent des informations. Pour cette question
c'est l'option auth qui définit si un
hôte requiert une authentification de l'hôte pair. Cette
authentification peut être requise par chacune des extrémités en
communication. Pour désactiver l'authentification à chaque
extrémité, on ajoute le préfixe no à
l'option auth.
Q5.
Quelles sont les options qui permettent de
visualiser en détails le dialogue PPP dans les journaux systèmes ?
C'est à nouveau dans les pages de manuels que la réponse se
trouve.
C'est l'option debug qui permet
l'affichage des informations relatives aux différentes étapes de
l'établissement de la connexion PPP.
Q6.
Quels sont les noms des deux sous-couches
du protocole PPP qui
apparaissent dans les journaux systèmes ? Quels sont les
rôles respectifs de ces deux sous-couches ?
La consultation des journaux système fait apparaître les
informations suivantes.
pppd[3262]: sent [LCP ConfReq id=0x1 <mru 1492> <magic 0x46010ac>]
kernel: [ 895.700115] NET: Registered protocol family 24
pppd[3262]: rcvd [LCP ConfReq id=0x1 <magic 0xcab9fecc>]
pppd[3262]: sent [LCP ConfAck id=0x1 <magic 0xcab9fecc>]
pppd[3262]: sent [LCP ConfReq id=0x1 <mru 1492> <magic 0x46010ac>]
pppd[3262]: rcvd [LCP ConfAck id=0x1 <mru 1492> <magic 0x46010ac>]
pppd[3262]: sent [LCP EchoReq id=0x0 magic=0x46010ac]
pppd[3262]: peer from calling number 52:54:00:12:34:05 authorized
pppd[3262]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>]
pppd[3262]: rcvd [LCP EchoReq id=0x0 magic=0xcab9fecc]
pppd[3262]: sent [LCP EchoRep id=0x0 magic=0x46010ac]
pppd[3262]: rcvd [IPCP ConfReq id=0x1 <addr 10.0.0.1>]
pppd[3262]: sent [IPCP ConfAck id=0x1 <addr 10.0.0.1>]
pppd[3262]: rcvd [LCP EchoRep id=0x0 magic=0xcab9fecc]
pppd[3262]: rcvd [IPCP ConfNak id=0x1 <addr 10.67.15.1>]
pppd[3262]: sent [IPCP ConfReq id=0x2 <addr 10.67.15.1>]
pppd[3262]: rcvd [IPCP ConfAck id=0x2 <addr 10.67.15.1>]
pppd[3262]: local IP address 10.67.15.1
pppd[3262]: remote IP address 10.0.0.1
La sous-couche Link Control Protocol
(LCP) assure la configuration
automatique des interfaces à chaque extrémité. Les paramètres
négociés entre les deux hôtes en communication sont multiples :
l'adaptation de la taille de datagramme, les caractères
d'échappement, les numéros magiques et la sélection des options
d'authentification.
La sous-couche Network Control
Protocol (NCP) assure
l'encapsulation de multiples protocoles de la couche réseau. Dans
l'exemple donné, c'est le protocole IP qui est utilisé ; d'où l'acronyme
IPCP.
Q7.
Quels sont les en-têtes du dialogue qui
identifient les requêtes (émises|reçues), les rejets et les
acquittements ?
Consulter les journaux système contenant les traces d'une
connexion PPP.
La copie d'écran donnée ci-dessus fait apparaître les directives
Conf* pour chaque paramètre
négocié.
ConfReq indique une requête.
ConfAck indique un
acquittement.
ConfNak indique un rejet.
4.2. Avec
authentification PAP
Relativement à la section précédente, on ajoute ici le volet
authentification au dialogue PPP
en utilisant le protocole PAP.
Pour l'ensemble des postes de travaux pratiques les paramètres
d'authentification login/password sont
: etu/stri.
Journalisation des échanges de mots de passe
Il existe une option spécifique du gestionnaire de connexion
PPP ipppd qui permet de journaliser les échanges
sur les mots de passe : +pwlog. En
ajoutant cette option à celles déjà utilisées lors de l'appel à
ipppd sur la ligne de commande, on
peut observer l'état des transactions d'authentification.
Q8.
Quelles sont les options de configuration
spécifiques à l'authentification PAP à fournir au démon PPP ?
Consulter les pages de manuels du démon ipppd.
C'est l'option pap qui permet de
spécifier ce type d'authentification.
Q9.
Dans quel fichier sont stockés les
paramètres d'authentification login/password utilisés par le protocole
PAP ?
Consulter les pages de manuels du démon ipppd.
C'est le fichier /etc/ppp/pap-secrets qui contient les couples
login/password utilisés lors de
l'authentification.
Q10.
Quels sont les en-têtes du dialogue de la
couche LCP qui identifient les
requêtes d'authentification échangées entre les deux processus
pairs ?
Voici une copie d'écran de connexion qui fait apparaître les
directives Conf* relatives à la partie
authentification.
Quelles sont les informations échangées sur
les mots de passe avec le protocole PAP ? Est-il possible de relever le mot
de passe avec ce protocole ?
L'utilisation de la méthode d'authentification PAP implique que le mot de passe circule en
clair. Une simple capture du trafic permet de «relever» le mot de
passe.
Voici un extrait de capture réseau effectué avec le démon
pppd à l'aide de la commande
#
tshark -V -i eth0 -R "ppp" >
grepMyPassword.txt.
On reprend exactement le cas précédent en changeant le protocole
d'authentification. On utilise maintenant le protocole
CHAP qui est nettement plus
intéressant que PAP. Nous allons
voir pourquoi !
Les paramètres d'authentification login/password ne changent pas : etu/stri.
Q12.
Quelles sont les options de configuration
spécifiques à l'authentification CHAP à fournir au démon PPP ?
Consulter les pages de manuels du démon ipppd.
C'est l'option chap qui permet de
spécifier ce type d'authentification.
Q13.
Dans quel fichier sont stockés les
paramètres d'authentification login/password utilisés par le protocole
CHAP ?
Consulter les pages de manuels du démon ipppd.
C'est le fichier /etc/ppp/chap-secrets qui contient les couples
login/password utilisés lors de
l'authentification.
Q14.
Quels sont les en-têtes du dialogue de la
couche LCP qui identifient les
requêtes d'authentification échangées entre les deux processus
pairs ?
Voici une copie d'écran de connexion qui fait apparaître les
directives Conf* relatives à la partie
authentification.
pppd[6037]: pppd 2.4.5 started by root, uid 0
pppd[6037]: using channel 28
pppd[6037]: Using interface ppp0
pppd[6037]: Connect: ppp0 < /dev/pts/1
pppd[6037]: sent [LCP ConfReq id=0x1 <auth chap MD5> <magic 0x46c97184>]
pppd[6037]: rcvd [LCP ConfAck id=0x1 <auth chap MD5> <magic 0x46c97184>]
pppd[6037]: rcvd [LCP ConfReq id=0x1 <mru 1492> <auth chap MD5> <magic 0x1f157ebf>]
pppd[6037]: sent [LCP ConfAck id=0x1 <mru 1492> <auth chap MD5> <magic 0x1f157ebf>]
pppd[6037]: sent [LCP EchoReq id=0x0 magic=0x46c97184]
pppd[6037]: sent [CHAP Challenge id=0x86 <ed6d9c0c022dbe008b2d3332fb275f5af1ca499393>,\
name = "ppp-hub"]
pppd[6037]: rcvd [LCP EchoReq id=0x0 magic=0x1f157ebf]
pppd[6037]: sent [LCP EchoRep id=0x0 magic=0x46c97184]
pppd[6037]: rcvd [CHAP Challenge id=0x4f <29b6227da7da53d7ee2b4f6f7ec9a1900d5c9ac33f14>,\
name = "etu"]
pppd[6037]: sent [CHAP Response id=0x4f <cb5bf4fbb0f9afd98a477f1f8a2e4c1f>,\
name = "etu"]
pppd[6037]: rcvd [LCP EchoRep id=0x0 magic=0x1f157ebf]
pppd[6037]: rcvd [CHAP Response id=0x86 <de265c472d38a441fdbd2228314e0d86>,\
name = "etu"]
pppd[6037]: sent [CHAP Success id=0x86 "Access granted"]
pppd[6037]: rcvd [CHAP Success id=0x4f "Access granted"]
pppd[6037]: CHAP authentication succeeded: Access granted
pppd[6037]: CHAP authentication succeeded
Q15.
Quelles sont les informations échangées sur
les mots de passe avec le protocole CHAP ? Est-il possible de relever le mot
de passe avec ce protocole ?
Les éléments donnés dans le copie d'écran ci-dessus montrent
qu'il n'y a pas d'échange de mot de passe entre les deux systèmes
en communication. Seuls des Challenges
sont échangés.
![[Note]](/images/note.png)
