فحص واجهة VPN في لينكس باستخدام ip link طبقةً بطبقة

تقول أيقونة العميل إن الاتصال قائم، والواجهة موجودة، ومع ذلك لا تصل التطبيقات إلى أي شيء. هذا المزيج شائع، لأن الواجهة الافتراضية قد تبقى موجودة بينما يغيب نظيرها البعيد أو عناوينها أو مساراتها. ip link هي الأداة الأولى الصحيحة، وهي أيضًا الأسهل في المبالغة في تفسيرها. تصف الرايات والعدادات طبقة واحدة، والطبقات التي فوقها تفشل بشكل مستقل. وهي أيضًا الأداة التي يستشهد بها الناس حين يريدون إثبات أن النفق يعمل، وهو تحديدًا الادعاء الذي لا تستطيع وحدها إثباته.

اقرأ الواجهة قبل أن تقرأ الأيقونة

ابدأ بـ ip -details link show dev tun0 كما هو موثّق في دليل ip-link، مع استبدال الاسم التقليدي بالواجهة التي يملكها عميلك فعليًا. الرايات والنوع و MTU وهوية الواجهة ملاحظات مفيدة. لا يلزم أن تتصرف صياغة حالة الواجهة الافتراضية مثل مؤشر الحامل في كبل فعلي، لذا تعامل مع UP كبيان عن الواجهة لا عن النفق.

هذا التمييز يفسّر الحالة الأكثر إرباكًا: واجهة تبقى موجودة بينما يعيد الطرف البعيد الاتصال أو يكون غير قابل للوصول.

قد تُبقي إعدادات الاستمرارية الرابط موجودًا تحديدًا حتى لا تعيد إعادة الاتصال بناؤه، ما يعني أن الوجود ليس صحة.

أضف العدادات وطلبًا ينبغي أن يستخدمها

استخدم عرض الإحصاءات المدعوم ip -s link show dev tun0، ولاحظ عدّادات الحزم والبايتات في الاتجاهين. ثم أنشئ طلبًا غير ضار ينبغي أن يعبر الواجهة وقارن الاتجاه المعني. الطلب الذي سلك المسار المباشر لتطبيق آخر لن يحرّك تلك العدادات، وهذا هو مغزى التمرين.

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

خذ القراءة مرتين، مرة قبل ومرة بعد، بدل الثقة بلقطة واحدة.

العناوين والمسارات خطوتان منفصلتان

قد يوجد الرابط دون البادئة أو إعداد المُحلِّل أو المسار الذي يحتاجه التطبيق. تحقّق من العنوان باستخدام ip address show dev tun0، ثم تحقّق من المسار الذي ستختاره الوجهة باستخدام ip route get للهدف الفعلي. تلك الملاحظات الثلاث تجيب عن ثلاثة أسئلة مختلفة، وآخرها فقط يتعلق بالتمرير.

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

سجّل الاسم الدقيق ونطاق الأسماء والوقت مع أي مخرجات تحتفظ بها، لأن الاسم المتشابه في حاوية أخرى أو جلسة مستعادة يمثل سياقًا مختلفًا تمامًا.

لا تحذف ما لم تتعرّف عليه

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

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

هذا الحذر ينطبق أيضًا على ip link set down، الذي يبدو قابلًا للعكس وكثيرًا ما لا يكون كذلك.

ما ينبغي أن تخرج به من الفحص

ينتهي الفحص الجيد بأربع حقائق: اسم الواجهة ونطاقها، وراياتها و MTU، وفرق العدادات من طلب حقيقي، والمسار والعنوان الذي يحتاجه التطبيق فعليًا. عندما تُكتب هذه، تصبح الخطوة التالية واضحة وتخص طبقة معينة. وبدونها تكون كل تغييرات لاحقة تخمينًا مصحوبًا بخطة تراجع.

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

احتفظ بالمخرجات مع التذكرة، لأن المقارنة اللاحقة لا تفيد إلا إذا رأيت ما الذي تغيّر.

ثم أغلق الحلقة باختبار التطبيق مرة أخرى، لأن الواجهة لم تكن قط ما يهم المستخدم.