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 quelques procédures de dépannage pour les problèmes d'authentification PPP.
Activez debug ppp negotiation et debug ppp authentication.
La phase d’authentification PPP ne commence que lorsque la phase LCP (Link Control Protocol) est terminée et qu’elle est à l’état ouvert. Si debug ppp negotiation n'indique pas que LCP est ouvert, corrigez ce problème avant de continuer.
L’authentification PPP doit être configurée des deux côtés. Émettez ces commandes selon les besoins :
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.
Machine locale (ou routeur local) : système sur lequel la session de débogage est en cours d'exécution. 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, c'est l'ordinateur local et RouterB est l'homologue. Cependant, si vous passez au débogage RouterB, il devient 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 d'exécution de la session de débogage, le client de numérotation peut être l'ordinateur ou l'homologue local.
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 Présentation de la sortie de la négociation debug ppp pour plus d'informations.
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.
Ce document comprend quelques organigrammes pour faciliter le dépannage. Vous pouvez passer à l'organigramme suivant en cliquant sur les cercles numérotés.
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 :
Recherchez CHAP dans la phase AUTHENTICATING :
*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"
Recherchez PAP dans la phase AUTHENTICATING :
*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"
Recherchez l'un de ces messages dans la sortie debug ppp negotiation :
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
Vérifiez si vous recevez des messages de requête ou d'échec 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 ne parvient pas à authentifier 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.
Recherchez ce qui suit dans la sortie debug ppp negotiation :
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 le défi ou la réponse sortante. Dans cet exemple, c'est maui-soho-03. Vous devez 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 en tant que A, mais que l’homologue attendait B, l’authentification échoue.
Si le nom d'utilisateur dans le défi sortant n'est pas le même que le nom d'hôte, recherchez la commande ppp chap hostname <nom d'utilisateur> , où le nom d'utilisateur correspond au nom d'utilisateur dans le défi sortant. Notez le nom d'utilisateur et le mot de passe (dans la commande ppp chap password qui l'accompagne). Vous utiliserez ces informations lors du dépannage du routeur distant.
Puisque 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, procédez au 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 :
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 valeur est sensible à la casse.
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 valeur est sensible à la casse.
Pour plus d'informations, référez-vous au document Authentification PPP à l'aide des commandes ppp chap hostname et ppp authentication chap callin.
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 défaillance sortante.
Ces messages sur le routeur local indiquent une défaillance 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
Si le routeur n'utilise pas de système AAA (Authentication, Authorization, and Accounting) basé sur le serveur (Radius ou Tacacs+), le routeur peut alors utiliser un AAA local ou AAA. Vérifiez si vous voyez l'un des messages suivants dans la sortie de 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 causée par deux raisons :
L'homologue n'a pas fourni le nom d'utilisateur attendu par le routeur local. Par exemple, nous attendions (et configurons) le nom d'utilisateur RouterA, mais l'homologue utilisait le nom RouterB. Vous pouvez configurer le nom d'utilisateur et le mot de passe envoyés par l'homologue ou corriger l'homologue avec le nom d'utilisateur approprié.
Le nom d’utilisateur du routeur local n’est pas configuré. 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 apparaît 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 de s'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 causée par deux raisons :
L'homologue n'a pas fourni le nom d'utilisateur attendu par le routeur local. Par exemple, nous attendions (et configurons) le nom d'utilisateur RouterA. Cependant, l’homologue a utilisé le nom RouterB. Vous pouvez configurer le nom d'utilisateur et le mot de passe envoyés par l'homologue ou mettre à jour l'homologue avec le nom d'utilisateur correct.
Le nom d’utilisateur du routeur local n’est pas configuré. 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 apparaît 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.
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 causée par une non-correspondance de mot de passe. Cela peut être dû à deux raisons :
L’homologue n’a pas fourni le mot de passe attendu par le routeur local. Par exemple, nous attendions (et configurons) 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.
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 :
Supprimez l'entrée de nom d'utilisateur et de mot de passe existante à l'aide de cette commande :
no username <username>
Où <nom d'utilisateur> est remplacé par le nom d'utilisateur dans le message d'erreur. Dans cet exemple, ce serait maui-soho-03.
Configurez le nom d'utilisateur et le mot de passe à l'aide de cette commande :
usernamepassword
Le nom d'utilisateur doit être identique au message CHAP ci-dessus. Le mot de passe doit correspondre à celui du routeur distant.
Remarque : Ce document n'est pas destiné à être une ressource de dépannage AAA. Pour plus d'informations sur le dépannage d'AAA, reportez-vous aux ressources suivantes :
Il se peut que vous ne puissiez pas vous authentifier auprès d'un serveur ACS, car le serveur ACS 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 CSCee04466 (clients enregistrés uniquement). Comme solution de contournement, utilisez un serveur RADIUS pour les sessions PPP. Cependant, conservez le serveur TACACS+ à des fins administratives sur le routeur.
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
18-Dec-2007 |
Première publication |