لماذا تتوقف PPTP وL2TP/IPsec قبل ظهور موجه اسم المستخدم؟
غياب موجه اسم المستخدم يعني أن PPP لم يبدأ قط، لذا يقع الخلل في النقل أو تبادل المفاتيح أو إعداد النفق. تحقق من ترتيب المراحل قبل إعادة التثبيت.
غياب موجه اسم المستخدم هدية تشخيصية: لم يبدأ PPP بعد، لذا لم يُستشر الحساب ولا كلمة المرور ولا سياسة النطاق. في اتصال PPTP أو L2TP/IPsec لا يطلب العميل بيانات الاعتماد إلا بعد وجود النفق وبدء الخادم لجلسة PPP. وكل ما يمكن أن يفشل قبل تلك اللحظة هو النقل أو تبادل المفاتيح أو إعداد النفق، وهي مساحة أصغر بكثير من «الـVPN معطل».
غياب الموجه يضيّق الخلل إلى ثلاث مراحل
دوّن آخر مرحلة نجحت بشكل مرئي، لأن لكل مرحلة مالكاً مختلفاً وإصلاحاً مختلفاً. والتخمين في إعدادات الحساب بينما أنت عالق في مرحلة سابقة بمرحلتين هو الطريق إلى ضياع يوم كامل.
| Stage | What has to work | How a failure looks |
|---|---|---|
| Reach | UDP 500, 4500 and 1701 — or TCP 1723 plus GRE — through every firewall and NAT device | Client hangs, then reports no response |
| Key exchange | Preshared key or certificate, phase 1 and phase 2 proposals | Fast error, or a stall after the client says it is verifying |
| Tunnel | L2TP or PPTP control channel, then PPP starts | Connects, then closes with no prompt |
| User auth | PPP credentials and an address pool with room | Prompt appears, then a rejection |
العميل الذي تنتهي مهلته دون موجه لم يحصل قط على ارتباط IPsec، لذا يقع الخلل في IKE أو في وصول حزمك إلى البوابة أصلاً. والعميل الذي يعلن أنه يتحقق من بيانات الاعتماد ثم يسقط وصل أبعد مما يوحي به ذلك الإعلان. أما ظهور الموجه يتبعه رفض فهو مصادقة PPP، وموضعه مقال عن الحساب لا هذا المقال.
المرحلة الأولى: البروتوكول الذي يُسقطه جدار الحماية بصمت
تحتاج PPTP إلى TCP 1723 لقناة التحكم وإلى بروتوكول IP رقم 47 لمسار البيانات، والاثنان يسافران منفصلين. وكثير من الشبكات تمرّر 1723 وتُسقط البروتوكول 47، فتُنتج نفقاً يتفاوض ثم لا يحمل شيئاً على الإطلاق. ويحتاج الموجه الذي يقوم بـNAT أيضاً إلى تمرير يدعم GRE، ولا يمكن لمسار وصول يعمل بـIPv6 فقط أن يحمل PPTP تحت أي إعداد.
يستهلك L2TP عبر IPsec المنفذ 500 في IKE والمنفذ 4500 في تجاوز NAT، ثم يغلّف حركة L2TP نفسها في 1701، بينما يحمل ESP الحمولة المحمية بعد وجود الارتباط. اسمح بمنفذي التحكم دون ESP وستحصل على العَرَض نفسه الوارد في العنوان بالضبط: تقدّم مرئي ثم عميل ميت قبل أي مربع حوار لبيانات الاعتماد. والاختبار من نقطة اتصال هاتف طريقة رخيصة لفصل مشكلة العميل عن مشكلة المسار.
المرحلة الثانية: مفتاح ليس المفتاح، واقتراح غير معروض
المفتاح غير المتطابق يفشل سريعاً وبصمت، والنسخة المعتادة مفتاح يبدو صحيحاً على الشاشة وهو يحمل فاصل سطر ملصوقاً أو مسافة في نهايته. على عميل Linux ليس مربع الحوار بالضرورة مصدر الحقيقة: فإضافة L2TP في NetworkManager تحفظ الأسرار في ملفات تحت /etc/ipsec.d/، وأي ملف أقدم لكل اتصال ما زال /etc/ipsec.secrets يضمّه سيُستخدم بدلاً من الملف الذي كتبته للتو. انسخ ذلك الملف إلى مكان آمن، وأخرجه من مسار التضمين، ثم أعد كتابة المفتاح يدوياً.
النصف الآخر من هذه المرحلة هو الاقتراح. يجب أن يتفق الطرفان على مجموعة الخوارزميات نفسها للمرحلة 1 — التشفير والسلامة ومجموعة Diffie-Hellman — وعلى تحويلات ESP متطابقة للمرحلة 2، وإلا فلا يتشكل الارتباط على الإطلاق. البوابة التي تعرض 3DES وSHA1 وMODP1024 فقط سترفض عميلاً مضبوطاً على خوارزميات أقوى، وسجلّها يسمّي التحويل المرفوض. والسجل يسمّي عدم التطابق إذا قرأته بدلاً من إعادة تشغيل الخدمة مرة أخرى. وبدلاً من نسخ سلسلة خوارزميات من منتدى، اسأل البوابة عن التحويلات التي ستتفاوض عليها فعلاً: ike-scan الموجّه إلى عنوانها يعيد التحويلات التي ستتفاوض عليها. وإذا كان العرض الوحيد تشفيراً لم تعد سياستك تسمح به، فالإصلاح موضعه البوابة لا تخفيض العميل.
على Windows يسكن المفتاح وطريقة المصادقة في ملف تعريف الـVPN، ويظهر عدم التطابق قبل موجه بيانات الاعتماد لا بعده. وحيث يكون المستقبِل خادم Windows، تأكد من تثبيت دور الوصول عن بعد، ومن مطابقة الشهادة للاسم الذي يتصل به العملاء، ومن ألا يكون أي مرشّح منافذ أضيق من البروتوكولات أعلاه.
المرحلة الثالثة: النفق موجود وPPP لا يبدأ أبداً
عندما يكتمل IKE ولا يظهر الموجه أبداً، انظر إلى خفير النفق لا إلى جدار الحماية. يحتاج L2TP إلى شيء يستمع على UDP 1701 — xl2tpd أو kl2tpd على Linux، أو خدمة الوصول عن بعد على Windows — والخدمة المثبتة والمتوقفة تبدو من جهة العميل مطابقة لحزمة مُسقطة. تحقق من المستمع قبل أن تعيد فتح قواعد تحققت منها سابقاً. ثم على PPP أن يتفاوض، وتبادل LCP الأول هو المكان الذي يقع فيه الفشل الصامت عادةً.
هناك فخ في هذه المرحلة ليس عطلاً في الشبكة على الإطلاق: يسمح Windows باتصال واحد فقط من نوع VPN معين في وقت واحد، لذا تعيد المحاولة الثانية الخطأ 937، «اتصال آخر من هذا النوع قيد الاستخدام». هذه قاعدة محلية، والتحايل عليها بجهاز آخر أو نوع نفق آخر أو مشاركة الاتصال الواحد القائم.
اقرأ السجل بترتيب المراحل بدلاً من التخمين
أوقف العميل ثم شغّله مجدداً، واقرأ المكوّنات بالترتيب الذي تكتب به السجلات. أي خفير IPsec أولاً — strongSwan أو Libreswan، و ipsec --version يخبرك أيهما — ثم خفير L2TP، ثم pppd. والمكوّن الذي كتب آخر سطر قبل الفشل يحدد المرحلة التي يجب التحقيق فيها، لأن كل ما يأتي بعده في التسلسل لم يعمل إطلاقاً.
تحقق باتصال جديد لا بجلسة محفوظة، لأن العميل الذي يعيد الاتصال من ذاكرة التخزين المؤقت قد يتجاوز أجزاء من التبادل ويعيد نتيجة قديمة. أكّد الوصول وتبادل المفاتيح والنفق وPPP واحداً واحداً، بهذا الترتيب. عندئذٍ يكفّ الموجه الغائب عن كونه لغزاً ويصبح السطر الثاني من قائمة يمكنك العمل عليها فعلاً. وهذه القائمة هي أيضاً ما تسلّمه لفريق الشبكة، الذي سيُطلب منه لولا ذلك فحص جدار الحماية بحثاً عن عطل يسكن في خفير لم يُشغَّل.