Dépannage de l'authentification PPP (CHAP ou PAP)

Introduction

Les questions d'authentification de protocole point-à-point (PPP) sont l'une des causes classiques pour les pannes de liaison d'accès par réseau commuté. Ce document fournit des procédures de dépannage pour les problèmes d'authentification PPP.

Conditions préalables

• Activez debug ppp negotiation et debug ppp authentication.

• La phase d’authentification PPP ne commence pas tant que la phase LCP (Link Control Protocol) n’est pas terminée et qu’elle n’est pas à l’état ouvert. Si debug ppp negotiation n'indique pas que LCP est ouvert, résolvez ce problème avant de continuer.

• L'authentification PPP doit être configurée des deux côtés. Émettez ces commandes comme approprié :

  • ppp authentication chap sur les deux routeurs, pour l'authentification CHAP (Challenge Handshake Authentication Protocol) bidirectionnelle.

  • ppp authentication chap callin sur le routeur appelant, pour l'authentification unidirectionnelle.

  • ppp authentication pap sur les deux routeurs, pour l’authentification PAP.

Terminologie

• Ordinateur local (ou routeur local) : système sur lequel la session de débogage est actuellement exécutée. Lorsque vous déplacez la session de débogage d’un routeur à l’autre, appliquez le terme machine locale à l’autre routeur.

• Peer : l'autre extrémité de la liaison point à point. Par conséquent, le périphérique n'est pas la machine locale.

  Par exemple, si vous émettez la commande debug ppp negotiation sur RouterA, alors c'est la machine locale et RouterB est l'homologue. Cependant, si vous passez le débogage sur RouterB, il devient alors la machine locale et RouterA devient l'homologue.

Remarque : les termes machine locale et homologue n'impliquent pas de relation client-serveur. Selon l'emplacement où la session de débogage est exécutée, le client de numérotation peut être l'ordinateur local ou l'homologue.

Exigences

Cisco recommande que vous ayez une connaissance de ce sujet :

• Vous devez être capable de lire et de comprendre le résultat de la négociation debug ppp. Référez-vous au document Comprendre la sortie de négociation debug ppp pour plus d'informations.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Diagramme de dépannage

Ce document inclut des organigrammes pour faciliter le dépannage. Vous pouvez passer au diagramme suivant en cliquant sur les cercles numérotés.

Le routeur effectue-t-il une authentification CHAP ou PAP ?

Pour déterminer si le routeur effectue l'authentification CHAP ou PAP, recherchez ces lignes dans la sortie debug ppp negotiation et debug ppp authentication :

CHAP

Recherchez CHAP dans la phase AUTHENTICATING (AUTHENTIFICATION) :

*Mar  7 21:16:29.468: BR0:1 PPP: Phase is AUTHENTICATING, by this end
*Mar  7 21:16:29.468: BR0:1 CHAP: O CHALLENGE id 5 len 33 from "maui-soho-03"

PAP

Recherchez PAP dans la phase AUTHENTICATING (AUTHENTIFICATION) :

*Mar  7 21:24:11.980: BR0:1 PPP: Phase is AUTHENTICATING, by both
*Mar  7 21:24:12.084: BR0:1 PAP: I AUTH-REQ id 1 len 23 from "maui-soho-01"

Le routeur effectue-t-il une authentification CHAP unidirectionnelle ou bidirectionnelle ?

Recherchez l'un des messages suivants dans le résultat de la négociation debug ppp :

BR0:1 PPP: Phase is AUTHENTICATING, by both

Le message ci-dessus indique que les routeurs effectuent une authentification bidirectionnelle.

L'un des messages ci-dessous indique que les routeurs effectuent une authentification unidirectionnelle :

BR0:1 PPP: Phase is AUTHENTICATING, by the peer

ou

BR0:1 PPP: Phase is AUTHENTICATING, by this end

Est-ce un échec entrant ?

Vérifiez si vous recevez des messages d'échec ou des messages termreq entrants. N'oubliez pas que « I » indique que le message est un message entrant :

BR0:1 LCP: I TERMREQ

ou

BR0:1 CHAP: I FAILURE

Un échec entrant indique que l'homologue n'authentifie pas le nom d'utilisateur et le mot de passe du routeur local. Cela peut être dû à une mauvaise configuration sur le routeur local (en ne fournissant pas le nom d'utilisateur et le mot de passe attendus par l'homologue) ou sur le routeur distant.

Le nom d'utilisateur de la demande ou de la réponse sortante est-il identique au nom d'hôte ?

Recherchez les éléments suivants dans le résultat de la négociation debug ppp :

BR0:1 CHAP: O CHALLENGE id 9 len 33 from "maui-soho-03"

ou

BR0:1 CHAP: O RESPONSE id 16 len 33 from "maui-soho-03"

Notez le nom d'utilisateur dans la demande ou la réponse sortante. Dans cet exemple, il s'agit de maui-soho-03. Vous avez besoin de ceci pour vérifier que le nom d'utilisateur et le mot de passe utilisés pour l'authentification correspondent à celui attendu par le côté distant. Par exemple, si le routeur local s'identifie à l'homologue comme A, mais que l'homologue attendait B, l'authentification échoue.

Si le nom d'utilisateur de la demande d'accès sortante n'est pas le même que le nom d'hôte, recherchez la commande ppp chap hostname <username> où le nom d'utilisateur correspond au nom d'utilisateur de la demande d'accès sortante. Notez le nom d'utilisateur et le mot de passe (dans la commande ppp chap password associée). Vous utiliserez ces informations lors du dépannage du routeur distant.

La machine distante est-elle un routeur Cisco auquel vous avez accès ?

Comme nous avons déterminé que le routeur local a reçu une défaillance entrante, nous savons que la défaillance se produit sur l'homologue. Si vous avez accès au routeur Cisco distant, effectuez un dépannage sur ce périphérique.

Si vous n'avez pas accès au routeur distant, contactez l'administrateur de ce routeur pour vérifier le nom d'utilisateur et le mot de passe qu'il attend.

Posez les questions suivantes :

1. Quel nom d’utilisateur le routeur distant attend-il ?

   Utilisez la commande ppp chap hostname <username> sous l'interface physique ou de numérotation. Configurez ici le nom d'utilisateur fourni par l'administrateur distant.

   Remarque : cette option est sensible à la casse.

2. Quel mot de passe le routeur distant attend-il ?

   Utilisez la commande ppp chap password <password> sous l'interface physique ou de numérotation.

   Remarque : cette option est sensible à la casse.

Pour plus d'informations, référez-vous au document Authentification PPP utilisant les commandes ppp chap hostname et ppp authentication chap callin.

Dépannage des échecs CHAP sortants

Si l'homologue détecte un message d'échec entrant, cela signifie que le routeur local n'a pas pu authentifier l'homologue et a envoyé le message. Par conséquent, vous devez maintenant dépanner le routeur sur lequel indique la panne sortante.

Ces messages sur le routeur local indiquent une panne sortante :

BR0:1 CHAP: O FAILURE id 10 len 26 msg is "Authentication failure"

ou

BR0:1 LCP: O TERMREQ [Open] id 22 len 4

Le routeur n'utilise pas de AAA ou uniquement un AAA local

Si le routeur n'utilise pas de système d'authentification, d'autorisation et de comptabilité (AAA) basé sur le serveur (Radius ou Tacacs+), le routeur peut utiliser soit aucun AAA, soit un AAA local. Vérifiez si l'un des messages suivants s'affiche dans le résultat du débogage :

Impossible de valider la réponse

Nom d'utilisateur <nom d'utilisateur> introuvable

BR0:1 CHAP: I RESPONSE id 18 len 33 from "maui-soho-03"

! -- Incoming CHAP response to our challenge. ! -- The username used in the response is maui-soho-03.

BR0:1 CHAP: Unable to validate Response.  Username maui-soho-03 not found

! -- The username supplied by the peer is not configured on the router. ! -- We assume the peer does not have permission to connect.

BR0:1 CHAP: O FAILURE id 18 len 26 msg is "Authentication failure"

! -- Outgoing CHAP failure message. ! -- The peer will see this as an incoming failure.

BR0:1 PPP: Phase is TERMINATING [0 sess, 0 load]

Une non-correspondance de nom d'utilisateur peut être due à deux raisons :

1. L'homologue n'a pas fourni le nom d'utilisateur attendu par le routeur local. Par exemple, nous attendions (et configurions) le nom d'utilisateur RouterA, mais l'homologue utilisait le nom RouterB. Vous pouvez soit configurer le nom d'utilisateur et le mot de passe envoyés par l'homologue, soit corriger l'homologue avec le bon nom d'utilisateur.

2. Le nom d’utilisateur n’est pas configuré sur le routeur local. Si le nom d'utilisateur fourni par l'homologue correspond à ce que le routeur local attendait, configurez le nom d'utilisateur et le mot de passe.

Ce problème se produit le plus souvent lorsque l'homologue utilise la commande ppp chap hostname pour configurer un nom d'utilisateur autre que le nom d'hôte du routeur.

Utilisez la commande username <username> password <password> où <username> est remplacé par le nom d'utilisateur dans le message d'erreur ci-dessus.

Nom d'utilisateur <nom d'utilisateur> introuvable

Impossible d'authentifier pour l'homologue

BR0:1 CHAP: I CHALLENGE id 17 len 33 from "maui-soho-01"

! -- Incoming challenge from maui-soho-01. ! -- This router must look up the username specified ! -- in order to create the CHAP response.

BR0:1 CHAP: Username maui-soho-01 not found

! -- The username (maui-soho-01) supplied by the peer is not configured locally.

BR0:1 CHAP: Unable to authenticate for peer

! -- Since this router does not recognize the username ! -- it cannot create the outgoing CHAP RESPONSE.

BR0:1 PPP: Phase is TERMINATING

! -- Authentication fails.

Une non-correspondance de nom d'utilisateur peut être due à deux raisons :

1. L'homologue n'a pas fourni le nom d'utilisateur attendu par le routeur local. Par exemple, nous attendions (et configurions) le nom d'utilisateur RouterA. Cependant, l'homologue a utilisé le nom RouterB. Vous pouvez soit configurer le nom d'utilisateur et le mot de passe envoyés par l'homologue, soit mettre à jour l'homologue avec le nom d'utilisateur correct.

2. Le nom d’utilisateur n’est pas configuré sur le routeur local. Si le nom d'utilisateur fourni par l'homologue correspond à ce que le routeur local attendait, configurez le nom d'utilisateur et le mot de passe.

Ce problème se produit le plus souvent lorsque l'homologue utilise la commande ppp chap hostname pour configurer un nom d'utilisateur autre que le nom d'hôte du routeur.

Utilisez la commande username <username> password <password> où <username> est remplacé par le nom d'utilisateur dans le message d'erreur ci-dessus.

Échec de la comparaison MD/DES

BR0:1 CHAP: I RESPONSE id 16 len 33 from "maui-soho-03"
  BR0:1 CHAP: O FAILURE id 16 len 25 msg is "MD/DES compare failed"

Cette erreur est due à une non-concordance de mot de passe. Cela peut être dû à deux raisons :

1. L'homologue n'a pas fourni le mot de passe attendu par le routeur local. Par exemple, nous attendions (et configurions) le mot de passe letmeIn, mais l'homologue a utilisé le mot de passe letmein. Vous pouvez soit reconfigurer le nom d'utilisateur et le mot de passe envoyés par l'homologue, soit corriger l'homologue avec le bon nom d'utilisateur.

2. Le mot de passe du routeur local n’est pas correctement configuré. Si vous avez vérifié que le mot de passe fourni par l'homologue est correct, reconfigurez le routeur local.

Solution :

1. Supprimez le nom d'utilisateur et le mot de passe existants à l'aide de cette commande :

   no username <username>
   
   

   Où <username> est remplacé par le nom d'utilisateur dans le message d'erreur. Dans cet exemple, il s'agirait de maui-soho-03.

2. Configurez le nom d'utilisateur et le mot de passe à l'aide de cette commande :

   username  password 
   
   

   Le nom d’utilisateur doit être identique à celui du message CHAP affiché ci-dessus. Le mot de passe doit correspondre à celui du routeur distant.

Dépannage des problèmes AAA généraux liés au serveur

Remarque : ce document n'est pas conçu comme une ressource de dépannage AAA. Pour plus d'informations sur le dépannage de AAA, reportez-vous aux ressources suivantes :

• Opérations AAA

• RADIUS

• TACACS

Problème : L'authentification PAP fonctionne pour PPP, mais MsCHAPv2 échoue

Il se peut que vous ne puissiez pas vous authentifier auprès d'un serveur ACS, car ce dernier ne reçoit pas la demande d'authentification, ce qui entraîne l'échec d'une session. Ce comportement est observé et consigné sous l'ID de bogue Cisco CSCee0466 (clients enregistrés uniquement) . Pour contourner ce problème, utilisez un serveur RADIUS pour les sessions PPP. Cependant, conservez le serveur TACACS+ à des fins d'administration sur le routeur.

Informations connexes

• Présentation de la sortie de négociation de débogage ppp
• Présentation et configuration de l'authentification PPP CHAP
• Authentification PPP par le biais des commandes ppp chap hostname et ppp authentication chap callin
• Configuration et dépannage du protocole PAP (Password Authentication Protocol) pour PPP
• Numérotation et accès de l'assistance technique
• Assistance et documentation techniques - Cisco Systems