تكوين بروتوكول مصادقة كلمة مرور PPP (PAP) واستكشاف أخطاء هذا البروتوكول وإصلاحها

خيارات التنزيل

  • PDF     (349.0 KB)
    عرض باستخدام Adobe Reader على مجموعة متنوعة من الأجهزة
  • ePub     (90.7 KB)
    العرض في تطبيقات مختلفة على iPhone أو iPad أو نظام تشغيل Android أو قارئ Sony أو نظام التشغيل Windows Phone
  • Mobi (Kindle)     (85.8 KB)
    عرض على جهاز Kindle أو تطبيق Kindle على أجهزة متعددة
تم التحديث:٩ مارس ٢٠٠٥
معرّف المستند:10313

لغة خالية من التحيز

تسعى مجموعة الوثائق لهذا المنتج جاهدة لاستخدام لغة خالية من التحيز. لأغراض مجموعة الوثائق هذه، يتم تعريف "خالية من التحيز" على أنها لغة لا تعني التمييز على أساس العمر، والإعاقة، والجنس، والهوية العرقية، والهوية الإثنية، والتوجه الجنسي، والحالة الاجتماعية والاقتصادية، والتمييز متعدد الجوانب. قد تكون الاستثناءات موجودة في الوثائق بسبب اللغة التي يتم تشفيرها بشكل ثابت في واجهات المستخدم الخاصة ببرنامج المنتج، أو اللغة المستخدمة بناءً على وثائق RFP، أو اللغة التي يستخدمها منتج الجهة الخارجية المُشار إليه. تعرّف على المزيد حول كيفية استخدام Cisco للغة الشاملة.

حول هذه الترجمة

ترجمت Cisco هذا المستند باستخدام مجموعة من التقنيات الآلية والبشرية لتقديم محتوى دعم للمستخدمين في جميع أنحاء العالم بلغتهم الخاصة. يُرجى ملاحظة أن أفضل ترجمة آلية لن تكون دقيقة كما هو الحال مع الترجمة الاحترافية التي يقدمها مترجم محترف. تخلي Cisco Systems مسئوليتها عن دقة هذه الترجمات وتُوصي بالرجوع دائمًا إلى المستند الإنجليزي الأصلي (الرابط متوفر).

المقدمة

يدعم بروتوكول الاتصال من نقطة إلى نقطة (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.

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

محفوظات المراجعة

المراجعة تاريخ النشر التعليقات
1.0
09-Mar-2005
الإصدار الأولي

هل كان هذا المستند مفيدًا؟

Feedbackالتعليقات

اتصل بنا

ينطبق هذا المستند على هذه المنتجات