أي مرحلة من مراحل VPN فشلت: IPsec أم قناة تحكم L2TP أم مصادقة PPP
حدّد آخر مرحلة نجحت، ثم أصلح تلك الطبقة وحدها: IPsec، أو قناة تحكم L2TP، أو مصادقة PPP، أو إسناد العنوان.
غيّرت كلمة المرور ولم يتغيّر شيء، لأن العطل لم يكن في PPP قط. تُبلّغ L2TP/IPsec عن خطأ اتصال واحد مقابل خمس عمليات تسليم مختلفة تمامًا، ولكل عملية تسليم إصلاحها الخاص. اعمل في الاتجاه المعاكس بدلًا من ذلك: اعثر على آخر مرحلة نجحت وغيّر فقط ما يأتي بعدها. والترتيب أدناه يحدّد أيضًا الأدلة التي تجمعها أولًا.
أجب عن أربعة أسئلة بالترتيب
أجبر المحاولة على البدء من جديد، لأن بعض العملاء يظلون يعرضون الخطأ السابق حتى يُفصل الملف الشخصي ويُعاد الاتصال به. ثم أجب عن هذا: هل كانت هناك رابطة أمان IPsec، وهل ظهر اتصال تحكم L2TP ومكالمة، وهل وصل PPP إلى حكم مصادقة، وهل منح IPCP العميل عنوانًا؟ أول لا هو المرحلة التي تصلحها. كل ما بعدها غير مُختبَر، لذا لا يثبت اسم مستخدم مرفوض شيئًا حين لم توجد رابطة أصلًا.
اضبط الساعات على الطرفين قبل المقارنة. محاولة أعادت تنظيف IPsec وفشلت عند PPP تبدو كعطل واحد حين يعرض العميل الرسالة الأخيرة فقط ويحتفظ سجل الخادم بالمحاولة السابقة. اقرأ حسب الطابع الزمني، لا حسب السطر الأعلى صوتًا.
حين لا يتوفر لديك سوى لقطة شاشة المستخدم، اعتمد على أبسط فصل: مفتاح مشترك مسبقًا خاطئ وxl2tpd لا يجيب أبدًا ينتجان النص نفسه في مربع حوار Windows، لكن أحدهما يحتاج إلى سر يُغيَّر على الطرفين والآخر يحتاج إلى تشغيل برنامج خفي أو قاعدة جدار حماية على الخادم نفسه. لا يستطيع جهاز في المنتصف إسقاط 1701 الداخلي بعد أن يلفّه IPsec بوضع النقل، فلا تبحث عن مرشح مسار غير موجود.
ما تملكه كل طبقة فعلًا
يحمي IPsec الحزم بين الطرفين؛ وينقل L2TP جلسة PPP داخل ذلك المسار المحمي، ولهذا تحدد RFC 3193 وضع النقل بدلًا من نفق خاص به. تقول تسمية العميل L2TP، فيبدو النفق وتسجيل الدخول كآلية واحدة. لكنهما ليسا كذلك: اتصال تحكم L2TP يصادق على طرفي النفق حيث يُفعّله النشر، بينما يصادق PPP على المستخدم بشكل منفصل عبر CHAP أو PAP أو MS-CHAPv2 وفق سياسة الخادم.
يفسّر هذا الفصل السرَّين اللذين يخلط بينهما الناس. المفتاح المشترك مسبقًا يصادق على طرفي IPsec. واسم المستخدم وكلمة المرور يعرّفان المستخدم إلى PPP. إعادة كتابة السر المشترك في Windows على ملف شخصي يصادق بالشهادات لا تغيّر شيئًا في المرحلة الفاشلة، وتحرير كلمة مرور PPP لا يوفّر قناة محمية مفقودة. وينطبق الضبط نفسه على فحص الهوية: لا تُعطّل هوية الطرف أو التحقق من الشهادة للحصول على نفق، لأن ما يتصل حينها هو المسار لا الطرف.
وليست المصادقة نهاية PPP أيضًا. بعد قبول المستخدم، يتفاوض IPCP على عنوان العميل وخيارات DNS وWINS التي يرغب الخادم في منحها. قد ينجح العميل في CHAP أو MS-CHAPv2 وينتهي بلا عنوان، وهذا عطل داخل PPP لا مشكلة توجيه. ويبقى L2TP الصريح بلا IPsec صالحًا وغير محمي، لذا لا يثبت اتصال ناجح أن الحركة محمية؛ افحص ما يفرضه الخادم، لا تسمية العميل.
قرّر من أول مرحلة مفقودة
اقرأ الجدول حسب أول عنصر مفقود، من اليسار إلى اليمين. العمود الأيمن هو العمل الوحيد الجدير بالجهد عند تلك النقطة؛ وكل ما على يساره مُثبَت بالفعل، وإعادة اختباره تُهدر نافذة الانقطاع دون أن تضيف معلومة.
| First thing missing | What it means | Change this |
|---|---|---|
| No IKE reply on 500 or 4500 | The path or the listener never answered | Firewall, NAT-T forwarding, server listener |
| IKE runs, no IPsec association | Identity, key, or proposal mismatch | Proposal and PFS set, pre-shared key, local and remote ID |
| Association up, no L2TP control connection | Inner signalling never reached xl2tpd | UDP 1701, tunnel and session sections, NAT encapsulation |
| Control connection up, PPP auth refused | The user or method was rejected | Credential format, allowed auth method, account policy |
| PPP auth accepted, no address assigned | IPCP never completed | Address pool in xl2tpd.conf, ms-dns and ms-wins in options.xl2tpd |
| Address assigned, applications fail | The inner path is wrong | Routes, DNS, MTU or MSS, server forwarding |
ثلاثة صفوف تستحق تحذيرًا. صف 1701 هو حيث يقع عادة عملاء Windows خلف NAT: تكتمل الرابطة ثم لا يصل شيء، ويكون التغليف هو السبب لا كلمة مرور سيئة. صف IPCP هو الذي يُقرأ خطأً كمشكلة توجيه، لأن Windows يلفّ العنوان المفقود في الخطأ 720 ولا يقول رمز شريط المهام سوى إن الاتصال فشل؛ وهذا العطل يقع بعد المصادقة وقبل التوجيه. الصف الأخير ليس عطل IPsec إطلاقًا مع أن رمز شريط المهام يقول إنه غير متصل.
أوامر تفصل الطبقات
على خادم Linux يعمل بـ strongSwan، يسرد swanctl --list-sas الروابط القائمة بهوية طرفها، ويغطي ipsec statusall مضيفات strongSwan وlibreswan الأقدم. وتحتها يُظهر ip xfrm state روابط النواة الفعلية، بينما يثبت ss -lunp | grep 1701 أين يرتبط xl2tpd. شغّل xl2tpd -D في المقدمة لترى اتصالات التحكم والمكالمات تظهر، وفعّل تنقيح pppd في /etc/ppp/options.xl2tpd لترى الطريقة المعروضة والجواب.
حين تُظهر السجلات مصادقة ناجحة، يصبح السؤال التالي هل اكتمل IPCP. تحقق من أن ip range في قسم [lns default] من /etc/xl2tpd/xl2tpd.conf لا يزال فيه عناوين حرة، وأن /etc/ppp/options.xl2tpd يحمل فعلًا ms-dns و ms-wins إذا كان العميل يتوقعها. تجمّع مستنفَد وخيار DNS مفقود يبدوان مختلفين على السلك: الأول يترك العميل بلا عنوان ومع الخطأ 720، والثاني يمنح عنوانًا بلا مُحلِّل، فتفشل الأسماء بينما يعمل ping إلى العناوين الخام. ولا يُصلَح أي منهما بإعادة إدخال كلمة المرور.
على العميل، تكتب إضافة L2TP في NetworkManager محادثة pppd في السجل، لذا يفصل journalctl -u NetworkManager -b عادةً بين النفق قائم والمصادقة مرفوضة ولا نفق إطلاقًا. على Windows، يبلّغ Get-VpnConnection عن إعدادات المصادقة الحقيقية للملف الشخصي، وتسمّي أحداث RasClient تحت Application في عارض الأحداث المكوّن الفاشل. وحين يكون مربع الحوار غامضًا جدًا، فعّل netsh ras set tracing * enable.
تسجيلات الالتقاط تحتاج تحذيرًا واحدًا. مع IPsec بوضع النقل يكون UDP 1701 الداخلي مشفّرًا، لذا يُظهر الالتقاط على الواجهة الخارجية ESP، أو UDP 4500 تحت NAT-T، ولا يُظهر L2TP إطلاقًا. غياب 1701 في الالتقاط متوقّع وليس دليلًا على منفذ محجوب؛ راقب هل تتحرك عدّادات ESP أو 4500.
NAT وMTU والمسارات: حيث يضلّلك المكدس
يكسر NAT الافتراضات قبل مصادقة أي شيء. ESP بروتوكول IP خاص به، لذا يتجاهله الجهاز المترجم ما لم يغلّفه الطرفان؛ وهذا ما يوفره UDP 4500. على خادم Windows يقف هو نفسه خلف موجه منزلي أو بوابة NAT سحابية، تفشل مرحلة IPsec بالخطأ 789 حتى يُضبط AssumeUDPEncapsulationContextOnSendRule على 2 تحت مفتاح PolicyAgent ويُعاد تشغيل الجهاز، ويبقى العطل غير قابل للتمييز عن منفذ مغلق. العملاء خلف NAT أسهل: مع عنوان عام على الخادم يحملهم NAT-T على UDP 4500 ولا تكون تلك القيمة معنية.
حين يقوم PPP، يحاكي MTU المبتلَع نفقًا ميتًا: تعبر الحزم الصغيرة، ويتعلّق مصافحة TLS أو تحميل صفحة، وقد يعرض العميل حالة متصل. اخفض MTU للواجهة أو ثبّت MSS عند البوابة قبل لوم الخادم. وتوجيه النفق المنقسم هو المحتال الآخر؛ فشبكة فرعية تُدفع بقناع خاطئ تترك النفق سليمًا وتطبيقًا واحدًا غير قابل للوصول. واسم مضيف خاص يضيف قفزة خاصة به: إذا خرج الاستعلام عبر المُحلِّل المحلي، يفشل الاسم قبل اختبار أي مسار.
قائمة تحقق قبل لمس بيانات الاعتماد
اعمل على القائمة بالترتيب وتوقف عند أول عنصر فاشل. كل خطوة رخيصة، وكل واحدة تستبعد فئة كاملة من التعديلات.
- تأكد من وجود الرابطة على الطرفين، مطابقةً بهوية الطرف لا بتسمية اتصال.
- تأكد من وصول UDP 1701 إلى xl2tpd؛ والرابطة بلا مكالمة هي عطلك.
- اقرأ حكم PPP، وإن صادق فنتيجة IPCP، قبل افتراض أن كلمة المرور خاطئة.
- الآن فقط أعد إدخال بيانات الاعتماد بالصيغة التي يتوقعها الخادم، لأن بادئة نطاق تغيّر الحساب.
- إذا استمر الفشل، التقط الطرفين بطوابع زمنية متوافقة وقارن مرحلة بمرحلة.
التوقف عند الخطوة الثانية يعني مشكلة مسار أو تغليف، ولن تحرّكها أي تعديل على كلمة المرور. والتوقف عند الخطوة الثالثة يعني أن السجل يسمّي بالفعل الطريقة أو تجمّع العناوين الذي يجب إصلاحه. وفي الحالتين يكون التغيير التالي تغييرًا يمكنك تبريره، وتتوقف عن الدوران في إعدادات لم تكن معنية أصلًا.