المحتويات

المقدمة

المتطلبات الأساسية

المتطلبات

المكونات المستخدمة

الاصطلاحات

معلومات أساسية

المصادقة أحادي الإتجاه مقابل ثنائي الإتجاه

أوامر التكوين

PPP لمصادقة PAP [callN]

username <username> كلمة <password>

PPP PAP send-username <username> كلمة <password>

مثال التكوين

تكوين جانب الاتصال (العميل)

تكوين جانب التلقي (الخادم)

مخرجات تصحيح الأخطاء

تصحيح أخطاء جانب الاتصال (العميل) لمصادقة PAP أحادية الإتجاه بنجاح

تصحيح أخطاء الجانب (الخادم) المستدعى لمصادقة PAP أحادية الإتجاه الناجحة

أستكشاف أخطاء PAP وإصلاحها

لا يتفق الجانبان على PAP كبروتوكول مصادقة

مصادقة PAP غير ناجحة

معلومات ذات صلة

المقدمة

يدعم بروتوكول الاتصال من نقطة إلى نقطة (PPP) حاليا بروتوكولي مصادقة: بروتوكول مصادقة كلمة المرور (PAP) وبروتوكول المصادقة لتأكيد الاتصال بقيمة التحدي (CHAP). يتم تحديد كليهما في RFC 1334 ويتم دعمها على الواجهات المتزامنة وغير المتزامنة.

- يوفر PAP طريقة بسيطة لعقدة بعيدة لتأسيس هويتها باستخدام مصافحة ثنائية الإتجاه. بعد اكتمال مرحلة إنشاء إرتباط PPP، يتم إرسال زوج اسم مستخدم وكلمة مرور بشكل متكرر بواسطة العقدة البعيدة عبر الارتباط (في نص واضح) حتى يتم الاعتراف بالمصادقة، أو حتى يتم إنهاء الاتصال.

- PAP ليس بروتوكول مصادقة آمن. يتم إرسال كلمات المرور عبر الارتباط في نص واضح ولا توجد حماية من هجمات التشغيل أو المحاولة والخطأ. تتحكم العقدة البعيدة في تكرار محاولات تسجيل الدخول وتوقيتها.

لمزيد من المعلومات حول أستكشاف أخطاء مصادقة PPP وإصلاحها (باستخدام بروتوكول PAP أو CHAP)، ارجع إلى مصادقة PPP (بروتوكول CHAP أو PAP) لاستكشاف أخطاء وإصلاحها للحصول على مخطط تدفق كامل خطوة بخطوة لاستكشاف أخطاء مرحلة مصادقة PPP وإصلاحها. لمزيد من المعلومات حول أستكشاف أخطاء PPP وإصلاحها (LCP، والمصادقة، و NCP)، ارجع إلى المخطط الانسيابي لاستكشاف أخطاء PPP وإصلاحها للحصول على مخطط انسيابي كامل لاستكشاف أخطاء جميع مراحل PPP ذات الصلة وإصلاحها خطوة بخطوة والمعلمات التي تم التفاوض عليها.

المتطلبات الأساسية

المتطلبات

لا توجد متطلبات خاصة لهذا المستند.

المكونات المستخدمة

لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة.

الاصطلاحات

راجع اصطلاحات تلميحات Cisco التقنية للحصول على مزيد من المعلومات حول اصطلاحات المستندات.

معلومات أساسية

يعد CHAP أكثر أمانا لأنه لا يتم إرسال كلمة مرور المستخدم عبر الاتصال أبدا. لمزيد من المعلومات حول CHAP، ارجع إلى فهم مصادقة PPP CHAP وتكوينها.

وعلى الرغم من أوجه القصور، يمكن إستخدام PAP في البيئات التالية:

- قاعدة كبيرة مثبتة من تطبيقات العميل التي لا تدعم بروتوكول CHAP

- تعارض بين عمليات تنفيذ موردين مختلفة ل CHAP

- الحالات التي يجب أن تكون فيها كلمة مرور نص عادي متاحة لمحاكاة تسجيل الدخول في المضيف البعيد

المصادقة أحادي الإتجاه مقابل ثنائي الإتجاه

وكما هو الحال مع معظم أنواع المصادقة، تدعم حماية مستوى التحكم (PAP) المصادقة ثنائية الإتجاه (ثنائية الإتجاه) ومتعددة الإتجاه (أحادية الإتجاه). باستخدام المصادقة أحادي الإتجاه، يقوم الجانب الذي يتلقى المكالمة (NAS) فقط بمصادقة الجانب البعيد (العميل). لا يقوم العميل البعيد بمصادقة الخادم.

باستخدام مصادقة ثنائية الإتجاه، يرسل كل جانب بشكل مستقل طلب مصادقة (AUTH-REQ) ويستلم إما مصادقة-إقرار (AUTH-ACK) أو مصادقة-غير معترف بها (AUTH-NAK). ويمكن ملاحظة ذلك باستخدام الأمر debug ppp authentication. فيما يلي مثال على تصحيح الأخطاء هذا في العميل:

*Mar  6 19:18:53.322: BR0:1 PAP: O AUTH-REQ id 7 len 18 from "PAPUSER"

! --- Outgoing PAP AUTH-REQ. We are sending out our username (PAPUSER)and password ! --- to the NAS. The NAS will verify that the username/password is correct.

*Mar  6 19:18:53.441: BR0:1 PAP: I AUTH-ACK id 7 Len 5

! --- Incoming AUTH-ACK. ! --- The NAS verified the username and password and responded with an AUTH-ACK. ! --- One-way authentication is complete at this point.

*Mar  6 19:18:53.445: BR0:1 PAP: I AUTH-REQ id 1 Len 14 from "NAS"

! --- Incoming AUTH-REQ from the NAS. This means we now verify the identity of the NAS.

*Mar  6 19:18:53.453: BR0:1 PAP: Authenticating peer NAS

! --- Performing a lookup for the username (NAS) and password.

*Mar  6 19:18:53.457: BR0:1 PAP: O AUTH-ACK id 1 Len 5

! --- Outgoing AUTH-ACK. ! --- We have verified the username/password of the NAS and responded with an AUTH-ACK. ! --- Two-way authentication is complete.

في إخراج تصحيح الأخطاء المذكور أعلاه، كانت المصادقة ثنائية الإتجاه. ومع ذلك، إذا تم تكوين المصادقة أحادي الإتجاه، فلن نرى سوى الخطين الأولين لتصحيح الأخطاء.

أوامر التكوين

هناك ثلاثة أوامر مطلوبة لمصادقة PAP العادية الموضحة أدناه:

PPP لمصادقة PAP [callN]

سيستخدم الموجه الذي تم تكوين الأمر ppp authentication pap على PAP للتحقق من هوية الجانب الآخر (النظير). هذا يعني أن الآخر جانب (نظير) ينبغي قدمت هو username/كلمة إلى الأداة محلي للتحقق.

يقول خيار الاستدعاء أن الموجه الذي تم تكوين أمر إستدعاء مصادقة PPP عليه سيصادق الجانب الآخر فقط أثناء مكالمة واردة. بالنسبة للمكالمة الصادرة، لن يقوم بمصادقة الجانب الآخر. هذا يعني أن الموجه الذي يبدأ المكالمة لا يتطلب طلب مصادقة (AUTH-REQ) من الجانب الآخر

يوضح الجدول التالي متى يمكن تكوين خيار الاستدعاء:

نوع المصادقة

العميل (الاتصال)

NAS (مستدعى)

أحادي الإتجاه

إستدعاء PPP لمصادقة

PPP لمصادقة

ثنائي الإتجاه

PPP لمصادقة

PPP لمصادقة

username <username> كلمة <password>

هذا هو اسم المستخدم وكلمة المرور المستخدمين من قبل الموجه المحلي لمصادقة نظير PPP. عندما يرسل النظير اسم مستخدم وكلمة مرور PAP الخاص به، سيقوم الموجه المحلي بالتحقق مما إذا كان اسم المستخدم وكلمة المرور ذلك قد تم تكوينهما محليا. في حالة وجود تطابق ناجح، تتم مصادقة النظير.

ملاحظة: تختلف وظيفة الأمر username ل PAP عن وظيفته ل CHAP. باستخدام بروتوكول CHAP، يتم إستخدام اسم المستخدم وكلمة المرور هذا لإنشاء الاستجابة للتحدي، ولكن PAP يستخدمهما فقط للتحقق من صحة اسم المستخدم وكلمة المرور الواردين.

بالنسبة للمصادقة أحادية الإتجاه، يكون هذا الأمر مطلوبا فقط على الموجه المسمى. للمصادقة المزدوجة الإتجاه، يكون هذا الأمر ضروريا على كلا الجانبين.

PPP PAP send-username <username> كلمة <password>

تمكين مصادقة PAP الصادرة. يستخدم الموجه المحلي اسم المستخدم وكلمة المرور المحددين من قبل الأمر ppp pap sent-username لمصادقة نفسه على جهاز بعيد. يجب أن يحتوي الموجه الآخر على نفس اسم المستخدم/كلمة المرور التي تم تكوينها باستخدام الأمر username الموضح أعلاه.

إذا كنت تستخدم مصادقة أحادية الإتجاه، فإن هذا الأمر يكون ضروريا فقط على الموجه الذي يبدأ المكالمة. بالنسبة للمصادقة ثنائية الإتجاه، يجب تكوين هذا الأمر على كلا الجانبين.

مثال التكوين

تظهر أقسام التكوين التالية أوامر PAP الضرورية لسيناريو مصادقة أحادي الإتجاه.

ملاحظة: يتم عرض الأقسام ذات الصلة فقط من التكوين.

تكوين جانب الاتصال (العميل)

interface BRI0

! --- BRI interface for the dialout.

ip address negotiated

encapsulation ppp

! --- Use PPP encapsulation. This command is a required for PAP.

dialer string 3785555 class 56k

! --- Number to dial for the outgoing connection.

dialer-group 1

isdn switch-type basic-ni

isdn spid1 51299611110101 9961111

isdn spid2 51299622220101 9962222

ppp authentication pap callin

! --- Use PAP authentication for incoming calls. ! --- The callin keyword has made this a one-way authentication scenario. ! --- This router (client) will not request that the peer (server) authenticate ! --- itself back to the client.

ppp pap sent-username PAPUSER password 7

! --- Permit outbound authentication of this router (client) to the peer. ! --- Send a PAP AUTH-REQ packet to the peer with the username PAPUSER and password. ! --- The peer must have the username PAPUSER and password configured on it.

تكوين جانب التلقي (الخادم)

username PAPUSER password 0 cisco

! --- Username PAPUSER is the same as the one sent by the client. ! --- Upon receiving the AUTH-REQ packet from the client, we will verify that the ! --- username and password match the one configured here.

interface Serial0:23

! --- This is the D-channel for the PRI on the access server receiving the call.

ip unnumbered Ethernet0

no ip directed-broadcast

encapsulation ppp

! --- Use PPP encapsulation. This command is a required for PAP.

dialer-group 1

isdn switch-type primary-ni

isdn incoming-voice modem

peer default ip address pool default

fair-queue 64 256 0

ppp authentication pap

! --- Use PAP authentication for incoming calls. ! --- This router (server) will request that the peer authenticate itself to us. ! --- Note: the callin option is not used as this router is not initiating the call.

مخرجات تصحيح الأخطاء

لتصحيح أخطاء مشكلة PPP، أستخدم أوامر تفاوض PPP وdebug ppp authentication. هناك مسألتان رئيسيتان يتعين عليك أن تنتبه إليهما:

1. هل يوافق كلا الطرفين على أن PAP هي طريقة المصادقة؟

2. إذا كان الأمر كذلك، هل تنجح مصادقة PAP؟

ارجع إلى تصحيح الأخطاء أدناه للحصول على معلومات حول كيفية الإجابة على هذه الأسئلة بشكل صحيح. أيضا، يرجى الرجوع إلى فهم إخراج تفاوض PPP الخاص بتصحيح الأخطاء (PPP) للحصول على شرح لجميع بنود تصحيح الأخطاء المختلفة بمعناها النسبي أثناء المراحل المختلفة PPP، بما في ذلك مصادقة PPP. هذا المستند مفيد في تحديد سبب حالات فشل تفاوض PPP بسرعة. لمزيد من المعلومات حول أستكشاف أخطاء مصادقة PPP وإصلاحها (باستخدام بروتوكول PAP أو CHAP)، ارجع إلى مصادقة PPP (بروتوكول CHAP أو PAP) لاستكشاف أخطاء وإصلاحها للحصول على مخطط تدفق كامل خطوة بخطوة لاستكشاف أخطاء مرحلة مصادقة PPP وإصلاحها.

تصحيح أخطاء جانب الاتصال (العميل) لمصادقة PAP أحادية الإتجاه بنجاح

maui-soho-01#show debug

PPP:

PPP authentication debugging is on

PPP protocol negotiation debugging is on

maui-soho-01#ping 172.22.53.144

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.22.53.144, timeout is 2 seconds:

*Mar  6 21:33:26.412: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up

*Mar  6 21:33:26.432: BR0:1 PPP: Treating connection as a callout

*Mar  6 21:33:26.436: BR0:1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load]

*Mar  6 21:33:26.440: BR0:1 PPP: No remote authentication for call-out

! --- The client will not authenticate the server for an outgoing call. ! --- Remember this is a one-way authentication example.

*Mar  6 21:33:26.444: BR0:1 LCP: O CONFREQ [Closed] id 82 Len 10

*Mar  6 21:33:26.448: BR0:1 LCP:    MagicNumber 0x2F1A7C63 (0x05062F1A7C63)

! --- Outgoing CONFREQ (CONFigure-REQuest). ! --- Notice that we do not specify an authentication method, ! --- since only the peer will authenticate us.

*Mar  6 21:33:26.475: BR0:1 LCP: I CONFREQ [REQsent] id 13 Len 14

*Mar  6 21:33:26.479: BR0:1 LCP:    AuthProto PAP (0x0304C023)

! --- Incoming LCP CONFREQ (Configure-Request) indicating that ! --- the peer(server) wishes to use PAP.

*Mar  6 21:33:26.483: BR0:1 LCP:    MagicNumber 0x3DBEE95B (0x05063DBEE95B)

*Mar  6 21:33:26.491: BR0:1 LCP: O CONFACK [REQsent] id 13 Len 14

*Mar  6 21:33:26.495: BR0:1 LCP:    AuthProto PAP (0x0304C023)

! --- This shows the outgoing LCP CONFACK (CONFigure-ACKnowledge) indicating that ! --- the client can do PAP.

*Mar  6 21:33:26.499: BR0:1 LCP:    MagicNumber 0x3DBEE95B (0x05063DBEE95B)

*Mar  6 21:33:26.511: BR0:1 LCP: I CONFACK [ACKsent] id 82 Len 10

*Mar  6 21:33:26.515: BR0:1 LCP:    MagicNumber 0x2F1A7C63 (0x05062F1.A7C63)

*Mar  6 21:33:26.519: BR0:1 LCP: State is Open

! --- This shows LCP negotiation is complete.

*Mar  6 21:33:26.523: BR0:1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 0 load]

! --- The PAP authentication (by the peer) begins.

*Mar  6 21:33:26.531: BR0:1 PAP: O AUTH-REQ id 20 Len 18 from "PAPUSER"

! --- The client sends out a PAP AUTH-REQ with username PAPUSER. ! --- This username is configured with the ppp pap sent-username command.

*Mar  6 21:33:26.555: BR0:1 PAP: I AUTH-ACK id 20 Len 5

! --- The Peer responds with a PPP AUTH-ACK, indicating that ! --- it has successfully authenticated the client.

تصحيح أخطاء الجانب (الخادم) المستدعى لمصادقة PAP أحادية الإتجاه الناجحة

maui-nas-06#show debug

PPP:

PPP authentication debugging is on

PPP protocol negotiation debugging is on

maui-nas-06#

*Jan  3 14:07:57.872: %LINK-3-UPDOWN: Interface Serial0:4, changed state to up

*Jan  3 14:07:57.876: Se0:4 PPP: Treating connection as a callin

! --- Since the connection is incoming, we will authenticate the client.

*Jan  3 14:07:57.876: Se0:4 PPP: Phase is ESTABLISHING, Passive Open

*Jan  3 14:07:57.876: Se0:4 LCP: State is Listen

*Jan  3 14:07:58.120: Se0:4 LCP: I CONFREQ [Listen] id 83 Len 10

*Jan  3 14:07:58.120: Se0:4 LCP:    MagicNumber 0x2F319828 (0x05062F319828)

*Jan  3 14:07:58.124: Se0:4 LCP: O CONFREQ [Listen] id 13 Len 14

*Jan  3 14:07:58.124: Se0:4 LCP:    AuthProto PAP (0x0304C023)

! --- Outgoing CONFREQ (Configure-Request) ! --- use PAP for the peer authentication.

*Jan  3 14:07:58.124: Se0:4 LCP:    MagicNumber 0x3DD5D5B9 (0x05063DD5D5B9)

*Jan  3 14:07:58.124: Se0:4 LCP: O CONFACK [Listen] id 83 Len 10

*Jan  3 14:07:58.124: Se0:4 LCP:    MagicNumber 0x2F319828 (0x05062F319828)

*Jan  3 14:07:58.172: Se0:4 LCP: I CONFACK [ACKsent] id 13 Len 14

*Jan  3 14:07:58.172: Se0:4 LCP:    AuthProto PAP (0x0304C023)

! --- This shows the incoming LCP CONFACK (Configure-Acknowledge) indicating that ! --- the client can do PAP.

*Jan  3 14:07:58.172: Se0:4 LCP:    MagicNumber 0x3DD5D5B9 (0x05063DD5D5B9)

*Jan  3 14:07:58.172: Se0:4 LCP: State is Open

*Jan  3 14:07:58.172: Se0:4 PPP: Phase is AUTHENTICATING, by this end

! --- The PAP authentication (by this side) begins.

*Jan  3 14:07:58.204: Se0:4 PAP: I AUTH-REQ id 21 Len 18 from "PAPUSER"

! --- Incoming AUTH-REQ from the peer. This means we must now verify ! --- the identity of the peer.

*Jan  3 14:07:58.204: Se0:4 PPP: Phase is FORWARDING

*Jan  3 14:07:58.204: Se0:4 PPP: Phase is AUTHENTICATING

*Jan  3 14:07:58.204: Se0:4 PAP: Authenticating peer PAPUSER

! --- Performing a lookup for the username (PAPUSER) and password.

*Jan  3 14:07:58.208: Se0:4 PAP: O AUTH-ACK id 21 Len 5

! --- This shows the outgoing AUTH-ACK. ! --- We have verified the username and password and responded with an AUTH-ACK. ! --- One-way authentication is complete.

أستكشاف أخطاء PAP وإصلاحها

عند أستكشاف أخطاء PAP وإصلاحها، أجب على نفس الأسئلة الموضحة في قسم إخراج تصحيح الأخطاء:

1. هل يوافق كلا الطرفين على أن PAP هي طريقة المصادقة؟

2. إذا كان الأمر كذلك، هل تنجح مصادقة PAP؟

لمزيد من المعلومات حول أستكشاف أخطاء مصادقة PPP وإصلاحها (باستخدام بروتوكول PAP أو CHAP)، ارجع إلى مصادقة PPP (بروتوكول CHAP أو PAP) لاستكشاف أخطاء وإصلاحها للحصول على مخطط تدفق كامل خطوة بخطوة لاستكشاف أخطاء مرحلة مصادقة PPP وإصلاحها.

لا يتفق الجانبان على PAP كبروتوكول مصادقة

في تكوين معين قد تلاحظ أن الجانبين لا يتفقان على PAP كبروتوكول مصادقة أو يتفقان بدلا من ذلك على CHAP (عندما تريد PAP). أستخدم الخطوات التالية لاستكشاف أخطاء هذه المشكلات وإصلاحها:

1. تحقق من أن الموجه الذي يستقبل المكالمة يتضمن أحد أوامر المصادقة التالية

ppp authentication pap

or

ppp authentication pap chap

or

ppp authentication chap pap

2. تحقق من أن الموجه الذي يقوم بإجراء المكالمة به إستدعاء PPP لمصادقة PAP.

3. تحقق من أن جانب الاتصال يحتوي على الأمر ppp pap send-username username كلمة بشكل صحيح، حيث يتطابق اسم المستخدم وكلمة المرور مع الكلمة التي تم تكوينها على الموجه المستلم.

4. قم بتكوين الأمر ppp chap deny في وضع تكوين الواجهة على موجه الاتصال.

سوف تقبل موجهات Cisco بشكل افتراضي CHAP كبروتوكول مصادقة. في الحالة التي يرغب فيها العميل في تنفيذ بروتوكول PAP ولكن يمكن لخادم الوصول تنفيذ PAP أو CHAP (تكوين بروتوكول PPP لمصادقة بروتوكول PPP)، يمكن إستخدام الأمر ppp chap refuse لإجبار العميل على قبول PAP كبروتوكول مصادقة.

maui-soho-01(config)#interface BRI 0

maui-soho-01(config-if)#ppp chap refuse

مصادقة PAP غير ناجحة

إذا اتفق الجانبان على PAP كبروتوكول مصادقة، لكن اتصال PAP يفشل، هو على الأرجح مشكلة اسم مستخدم/كلمة مرور.

1. تحقق من أن جانب الاتصال يحتوي على الأمر ppp pap send-username username كلمة بشكل صحيح، حيث يتطابق اسم المستخدم وكلمة المرور مع الواحد الذي تم تكوينه على الموجه المستقبل.

2. بالنسبة للمصادقة المزدوجة الإتجاه، تحقق من أن الجانب المتلقي يحتوي على الأمر ppp pap send-username password تم تكوينه بشكل صحيح، حيث يتطابق اسم المستخدم وكلمة المرور مع الذي تم تكوينه على موجه الاتصال.

عند إجراء المصادقة المزدوجة الإتجاه، إذا لم يكن الأمر ppp pap send-username username password موجودا على الموجه المستلم ويحاول عميل PPP إجبار الخادم على المصادقة عن بعد، فإن إخراج debug ppp negotiation (أو debug ppp authentication) يشير إلى

*Jan  3 16:47:20.259: Se0:1 PAP: Failed request for PAP credentials.  Username maui-nas-06

رسالة الخطأ هذه هي إشارة إلى مشكلة تكوين وليس بالضرورة خرق أمان.

3. 3. تحقق من أن اسم المستخدم وكلمة المرور، يطابقان الكلمة التي تم تكوينها في الأمر ppp pap send-username username password على النظير.

إذا لم تتطابق سترى هذه الرسالة:

*Jan  3 17:18:57.559: Se0:3 PAP: I AUTH-REQ id 25 Len 18 from "PAPUSER"

*Jan  3 17:18:57.559: Se0:3 PPP: Phase is FORWARDING

*Jan  3 17:18:57.559: Se0:3 PPP: Phase is AUTHENTICATING

*Jan  3 17:18:57.559: Se0:3 PAP: Authenticating peer PAPUSER

*Jan  3 17:18:57.559: Se0:3 PAP: O AUTH-NAK id 25 Len 32 msg is

"Password validation failure"

! --- This is an outgoing AUTH-NAK. This means that the mismatch occurred ! --- on this router. Verify that the username and password configured locally is ! --- identical to that on the peer.

معلومات ذات صلة

- تكوين المصادقة

- المخطط الانسيابي لاستكشاف أخطاء PPP وإصلاحها

- أستكشاف أخطاء مصادقة PPP (CHAP أو PAP) وإصلاحها

- فهم إخراج تفاوض تصحيح أخطاء PPP

- مصادقة PPP باستخدام أوامر إستدعاء بروتوكول PPP chap hostname و مصادقة PPP

- تقنية الاتصال: نظرة عامة وتفسيرات

- الدعم التقني والمستندات - Cisco Systems