Fehlerbehebung PPP-Authentifizierung (CHAP oder PAP)

Einleitung

Point-to-Point Protocol (PPP)-Authentifizierungsprobleme gehören zu den häufigsten Ursachen für Ausfälle der DFÜ-Verbindung. In diesem Dokument finden Sie einige Verfahren zur Fehlerbehebung bei PPP-Authentifizierungsproblemen.

Voraussetzungen

• Aktivieren Sie debug ppp negotiation und debug ppp authentication.

• Die PPP-Authentifizierungsphase beginnt erst, wenn die LCP-Phase (Link Control Protocol) abgeschlossen ist und sich im offenen Zustand befindet. Wenn debug ppp negotiation nicht anzeigt, dass das LCP geöffnet ist, beheben Sie dieses Problem, bevor Sie fortfahren.

• Die PPP-Authentifizierung muss auf beiden Seiten konfiguriert werden. Führen Sie die folgenden Befehle aus:

  • ppp authentication chap auf beiden Routern zur bidirektionalen CHAP-Authentifizierung (Challenge Handshake Authentication Protocol).

  • ppp authentication chap callin auf dem anrufenden Router für unidirektionale Authentifizierung

  • ppp authentication pap auf beiden Routern zur PAP-Authentifizierung.

Terminologie

• Lokaler Computer (oder lokaler Router) - Dies ist das System, auf dem die Debugsitzung derzeit ausgeführt wird. Wenn Sie die Debugsitzung von einem Router auf den anderen übertragen, wenden Sie den Begriff "lokaler Computer" auf den anderen Router an.

• Peer - Das andere Ende der Point-to-Point-Verbindung. Daher ist das Gerät nicht der lokale Computer.

  Wenn Sie beispielsweise den Befehl debug ppp negotiation auf RouterA eingeben, ist dies der lokale Computer, und RouterB ist der Peer. Wenn Sie jedoch die Debugging-Funktion auf RouterB umstellen, wird dieser zum lokalen Computer und RouterA zum Peer.

Hinweis: Die Begriffe "lokales System" und "Peer" implizieren keine Client-Server-Beziehung. Je nachdem, wo die Debugsitzung ausgeführt wird, kann der Einwahlclient der lokale Computer oder Peer sein.

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in diesem Thema verfügen:

• Sie müssen die debug ppp negotiation-Ausgabe lesen und verstehen können. Weitere Informationen finden Sie im Dokument Understanding debug ppp negotiation Output.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).

Fehlerbehebung: Flussdiagramm

Dieses Dokument enthält einige Flussdiagramme, die bei der Fehlerbehebung helfen. Sie können mit dem nächsten Flussdiagramm fortfahren, indem Sie auf die nummerierten Kreise klicken.

Führt der Router eine CHAP- oder PAP-Authentifizierung durch?

Um festzustellen, ob der Router eine CHAP- oder PAP-Authentifizierung durchführt, suchen Sie in der Ausgabe von debug ppp negotiation und debug ppp authentication nach den folgenden Zeilen:

CHAP

Suchen Sie in der AUTHENTIFIZIERUNGsphase nach CHAP:

*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

Suchen Sie in der AUTHENTIFIZIERUNGsphase nach PAP:

*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"

Führt der Router eine unidirektionale oder eine bidirektionale CHAP-Authentifizierung durch?

Suchen Sie in der Ausgabe des debug ppp negotiation nach einer der folgenden Meldungen:

BR0:1 PPP: Phase is AUTHENTICATING, by both

Die obige Meldung zeigt an, dass die Router eine bidirektionale Authentifizierung durchführen.

Eine der folgenden Meldungen zeigt an, dass die Router eine unidirektionale Authentifizierung durchführen:

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

Oder

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

Handelt es sich um einen eingehenden Fehler?

Überprüfen Sie, ob Sie eingehende termreq- oder Fehlermeldungen erhalten. Denken Sie daran, dass "I" anzeigt, dass die Nachricht eine eingehende Nachricht ist:

BR0:1 LCP: I TERMREQ

Oder

BR0:1 CHAP: I FAILURE

Ein eingehender Fehler weist darauf hin, dass der Peer den Benutzernamen und das Kennwort des lokalen Routers nicht authentifiziert. Dies kann auf eine Fehlkonfiguration auf dem lokalen Router (ohne Angabe des vom Peer erwarteten Benutzernamens und Kennworts) oder auf dem Remote-Router zurückzuführen sein.

Entspricht der Benutzername bei der ausgehenden Herausforderung oder der Antwort dem Hostnamen?

Suchen Sie in der Ausgabe von debug ppp negotiation nach folgenden Informationen:

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

Oder

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

Notieren Sie sich den Benutzernamen für die ausgehende Herausforderung oder Antwort. In diesem Beispiel ist es maui-soho-03. Sie benötigen dies, um sicherzustellen, dass der Benutzername und das Kennwort für die Authentifizierung mit dem von der Remoteseite erwarteten übereinstimmen. Wenn sich der lokale Router beispielsweise beim Peer als A identifiziert, der Peer aber B erwartet hat, schlägt die Authentifizierung fehl.

Wenn der Benutzername in der ausgehenden Herausforderung nicht mit dem Hostnamen übereinstimmt, suchen Sie nach dem Befehl ppp chap hostname <username>, wobei der Benutzername dem Benutzernamen in der ausgehenden Herausforderung entspricht. Notieren Sie sich den Benutzernamen und das Passwort (im zugehörigen Befehl ppp chap password). Sie verwenden diese Informationen, wenn Sie eine Fehlerbehebung für den Remote-Router durchführen.

Ist der Remote-Computer ein Cisco Router, auf den Sie Zugriff haben?

Da wir festgestellt haben, dass der lokale Router einen eingehenden Fehler erhalten hat, wissen wir, dass der Fehler auf dem Peer auftritt. Wenn Sie Zugriff auf den Cisco Remote-Router haben, können Sie die Fehlerbehebung für dieses Gerät durchführen.

Wenn Sie keinen Zugriff auf den Remote-Router haben, wenden Sie sich an den Administrator des Routers, um den Benutzernamen und das Kennwort zu überprüfen, die er erwartet.

Stellen Sie folgende Fragen:

1. Welchen Benutzernamen erwartet der Remote-Router?

   Verwenden Sie den Befehl ppp chap hostname <benutzername> unter der physischen Schnittstelle oder der Wählschnittstelle. Konfigurieren Sie hier den vom Remote-Administrator bereitgestellten Benutzernamen.

   Hinweis: Hierbei wird zwischen Groß- und Kleinschreibung unterschieden.

2. Welches Kennwort erwartet der Remote-Router?

   Verwenden Sie den Befehl ppp chap password <password> unter der physischen Schnittstelle oder der Wählschnittstelle.

   Hinweis: Hierbei wird zwischen Groß- und Kleinschreibung unterschieden.

Weitere Informationen finden Sie im Dokument PPP Authentication Using the ppp chap hostname and ppp authentication chap callin Commands.

Fehlerbehebung bei ausgehenden CHAP-Fehlern

Wenn der Peer eine eingehende Fehlermeldung erkennt, bedeutet dies, dass der lokale Router den Peer nicht authentifiziert und die Nachricht versendet hat. Daher müssen Sie jetzt eine Fehlerbehebung für den Router durchführen, der den ausgehenden Fehler anzeigt.

Diese Meldungen auf dem lokalen Router weisen auf einen ausgehenden Fehler hin:

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

Oder

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

Der Router verwendet kein oder nur lokales AAA

Wenn der Router kein serverbasiertes AAA-System (Authentication, Authorization und Accounting) verwendet (Radius oder TACACS+), kann der Router entweder kein AAA oder lokales AAA verwenden. Überprüfen Sie, ob in der Debugausgabe eine der folgenden Meldungen angezeigt wird:

Antwort kann nicht überprüft werden

Benutzername <Benutzername> nicht gefunden

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]

Eine Nichtübereinstimmung des Benutzernamens kann auf zwei Ursachen zurückzuführen sein:

1. Der Peer hat den vom lokalen Router erwarteten Benutzernamen nicht bereitgestellt. Beispielsweise erwarteten (und konfigurierten) wir den Benutzernamen RouterA, der Peer verwendete jedoch den Namen RouterB. Sie können entweder den Benutzernamen und das Kennwort konfigurieren, die vom Peer gesendet werden, oder den Peer mit dem richtigen Benutzernamen korrigieren.

2. Auf dem lokalen Router ist der Benutzername nicht konfiguriert. Wenn der vom Peer bereitgestellte Benutzername mit dem übereinstimmt, was der lokale Router erwartet hat, konfigurieren Sie den Benutzernamen und das Kennwort.

Dieses Problem tritt am häufigsten auf, wenn der Peer mit dem Befehl ppp chap hostname einen anderen Benutzernamen als den Router-Hostnamen konfiguriert.

Verwenden Sie den Befehl username <username> password <password>, wobei <username> in der obigen Fehlermeldung durch den Benutzernamen ersetzt wird.

Benutzername <Benutzername> nicht gefunden

Authentifizierung für Peer nicht möglich

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.

Eine Nichtübereinstimmung des Benutzernamens kann auf zwei Ursachen zurückzuführen sein:

1. Der Peer hat den vom lokalen Router erwarteten Benutzernamen nicht bereitgestellt. Beispielsweise erwarteten (und konfigurierten) wir den Benutzernamen RouterA. Der Peer verwendete jedoch den Namen RouterB. Sie können entweder den Benutzernamen und das Kennwort konfigurieren, die vom Peer gesendet werden, oder den Peer mit dem richtigen Benutzernamen aktualisieren.

2. Auf dem lokalen Router ist der Benutzername nicht konfiguriert. Wenn der vom Peer bereitgestellte Benutzername mit dem übereinstimmt, was der lokale Router erwartet hat, konfigurieren Sie den Benutzernamen und das Kennwort.

Dieses Problem tritt am häufigsten auf, wenn der Peer mit dem Befehl ppp chap hostname einen anderen Benutzernamen als den Router-Hostnamen konfiguriert.

Verwenden Sie den Befehl username <username> password <password>, wobei <username> in der obigen Fehlermeldung durch den Benutzernamen ersetzt wird.

MD/DES-Vergleich fehlgeschlagen

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"

Dieser Fehler wird durch eine Passwortungleichheit verursacht. Dies kann auf zwei Ursachen zurückzuführen sein:

1. Der Peer hat das vom lokalen Router erwartete Kennwort nicht bereitgestellt. Beispielsweise erwarteten (und konfigurierten) wir das Kennwort LetmeIn, aber der Peer verwendete das Kennwort letmein. Sie können entweder den Benutzernamen und das Kennwort, die vom Peer gesendet wurden, neu konfigurieren oder den Peer mit dem richtigen Benutzernamen korrigieren.

2. Auf dem lokalen Router ist das Kennwort nicht richtig konfiguriert. Wenn Sie überprüft haben, dass das vom Peer angegebene Kennwort richtig ist, konfigurieren Sie den lokalen Router neu.

Lösung:

1. Entfernen Sie den vorhandenen Benutzernamen und das Kennwort mit dem folgenden Befehl:

   no username <username>
   
   

   Dabei wird <Benutzername> durch den Benutzernamen in der Fehlermeldung ersetzt. In diesem Beispiel wäre das maui-soho-03.

2. Konfigurieren Sie Benutzername und Kennwort mit dem folgenden Befehl:

   username  password 
   
   

   Der Benutzername muss mit dem Benutzernamen in der oben angezeigten CHAP-Nachricht übereinstimmen. Das Kennwort sollte mit dem Kennwort auf dem Remote-Router übereinstimmen.

Fehlerbehebung bei allgemeinen serverbasierten AAA-Problemen

Hinweis: Dieses Dokument ist nicht als AAA-Ressource zur Fehlerbehebung gedacht. Weitere Informationen zur Fehlerbehebung bei AAA finden Sie in den folgenden Ressourcen:

• AAA-Betrieb

• RADIUS

• TACACS

Problem: PAP-Authentifizierung funktioniert für PPP, aber MsCHAPv2 schlägt fehl

Möglicherweise können Sie sich nicht bei einem ACS-Server authentifizieren, da der ACS-Server die Authentifizierungsanforderung nicht empfängt. Dies führt dazu, dass eine Sitzung fehlschlägt. Dieses Verhalten wird unter der Cisco Bug-ID CSCee04466 beobachtet und protokolliert (nur registrierte Kunden). Verwenden Sie zur Problemumgehung einen RADIUS-Server für PPP-Sitzungen. Behalten Sie den TACACS+-Server jedoch zu administrativen Zwecken auf dem Router bei.

Zugehörige Informationen

• Grundlagen der debug ppp negotiation-Ausgabe
• Verständnis und Konfiguration der PPP-CHAP-Authentifizierung
• PPP-Authentifizierung mit ppp chap Hostname und ppp authentication chap callin-Befehlen
• Konfiguration und Fehlerbehebung des PPP Password Authentication Protocol (PAP)
• Unterstützung von Einwahl- und Zugriffstechnologie
• Technischer Support und Dokumentation für Cisco Systeme