4. Connexion avec le protocole PPP

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.

[Note] 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 ?

Consulter la page Point-to-Point Protocol.

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>] 1
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>] 2
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

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.

2

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.

[Note] 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.

pppd[5259]: sent [LCP ConfReq id=0x1 <auth pap> <magic 0x53c04a36>]
pppd[5259]: rcvd [LCP ConfAck id=0x1 <auth pap> <magic 0x53c04a36>]
pppd[5259]: rcvd [LCP ConfReq id=0x1 <mru 1492> <magic 0x3f810ce9>]
pppd[5259]: sent [LCP ConfAck id=0x1 <mru 1492> <magic 0x3f810ce9>]
pppd[5259]: sent [LCP EchoReq id=0x0 magic=0x53c04a36]
pppd[5259]: rcvd [LCP EchoReq id=0x0 magic=0x3f810ce9]
pppd[5259]: sent [LCP EchoRep id=0x0 magic=0x53c04a36]
pppd[5259]: rcvd [PAP AuthReq id=0x1 user="etu" password=<hidden>]

Q11.

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.

Type: PPPoE Session (0x8864)
PPP-over-Ethernet Session
    0001 .... = Version: 1
    .... 0001 = Type: 1
    Code: Session Data (0x00)
    Session ID: 0x0003
    Payload Length: 16
Point-to-Point Protocol
    Protocol: Password Authentication Protocol (0xc023)
PPP Password Authentication Protocol
    Code: Authenticate-Request (1)
    Identifier: 1
    Length: 14
    Data
        Peer-ID-Length: 3
        Peer-ID: etu
        Password-Length: 5
        Password: stri

4.3. Avec authentification CHAP

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.