فحص شبكة VPN بلا واجهة رسومية: تدفّق واحد في كل مرة، مع الأدلة
يحتاج الجهاز بلا واجهة إلى طلب تستطيع قراءة جوابه. اختبر كل عائلة عناوين وكل سياق ووجهة، ثم سجّل ما لم يغطّه الاختبار.
على جهاز بلا واجهة رسومية لا يوجد متصفّح تفتحه ولا قفل تتأمّله، لذا يجب أن يكون الفحص طلبًا تستطيع قراءة جوابه. يبدو ذلك بديهيًا حتى تلاحظ أن نتيجة واحدة لعنوان الخروج تُستخدم لاعتماد جهاز يشغّل دستة خدمات وعائلتي عناوين ووكيلًا. يبني العرض التالي دليلًا محدودًا واحدًا في كل مرة، في السياق نفسه الذي تعمل فيه الحِمل الفعلي.
قرّر ما يجب أن يثبته الاختبار
قبل تشغيل أي شيء، اكتب التوقّع في سطر واحد: أي تدفّق، وعبر أي واجهة، وإلى أي وجهة، وما ينبغي ملاحظته في الطرف الآخر. الاختبار بلا توقّع معلن ينتج رقمًا لا يستطيع أحد تفسيره.
أكثر صيغة فائدة تسمّي نقطة نهاية معتمدة تُبلغ عن عنوان المصدر الذي رأته.
تلك النقطة هي الجزء الوحيد الذي عليك ترتيبه. كل ما عدا ذلك ملاحظة من جهة العميل، والملاحظات من جهة العميل تخطئ بطرق مثيرة للاهتمام.
شغّل الملاحظة في السياق الصحيح
قشرة المدير ليست بيئة الحِمل. فقد تحمل متغيّر وكيل مختلفًا، أو جدول توجيه مختلفًا في فضاء أسماء آخر، أو ملف بيئة مستخدم آخر. شغّل الاختبار في السياق نفسه للمضيف أو الحاوية أو فضاء الأسماء أو الخدمة التي تفحصها. وإلا فأنت تقيس قشرتك.
على مضيف عادي يعني ذلك المستخدم نفسه والوحدة نفسها. وفي منشأة حاويات يعني دخول فضاء أسماء شبكة الحاوية بدلًا من الاختبار من المضيف. وعلى خدمة systemd قد يعني وحدة مؤقتة بالإعدادات نفسها.
لا يكون الطلب التالي ذا معنى إلا بعد أن تكون في السياق الصحيح.
افحص عائلتي العناوين بشكل منفصل
اطلب كل عائلة صراحةً، لأن طلب IPv4 ناجحًا لا يختبر مسار IPv6 إطلاقًا. المحدّدان --ipv4 و--ipv6 يفرضان الاختيار، والفرق بين النتيجتين هو نفسه معلومة.
curl --ipv4 https://probe.example/observed-source
curl --ipv6 https://probe.example/observed-sourceطلب IPv6 الفاشل ليس دليلًا على حجب فعّال. قد يعني أن نقطة النهاية لا تملك عنوان IPv6، أو أن DNS لم يُعِد شيئًا صالحًا، أو أن الجهاز لا يملك مسار IPv6 إطلاقًا. اقرأ الفشل قبل أن تستنتج منه. طلب IPv6 ناجح عبر النفق هو النتيجة الوحيدة التي تثبت أن مسار IPv6 مغطّى.
سجّل الجوابين جنبًا إلى جنب. أحدهما وحده نصف حقيقة.
أضف الأمور الأربعة التي يفوّتها فحص الخروج
عنوان الخروج يجيب عن سؤال واحد. وأربعة أخرى تحدّد ما إذا كان النفق يعمل كما صُمّم.
| Check | What it proves | What it does not |
|---|---|---|
| Included and excluded destinations | The split behaves as designed for those flows | Coverage of any other destination |
| Resolver path | Where a fresh lookup actually travelled | Where a cached answer came from |
| Tunnel-down behaviour | The failure policy for a new request | What an already open connection does |
| Reconnect and restart | The requirement survives the lifecycle event | Behaviour under load or partial failure |
سياسة الوجهة أولًا: اختبر تدفّقًا ينبغي تضمينه وآخر ينبغي استثناؤه، حين يتضمّن التصميم انقسامًا. ثم DNS، حيث تفحص مسار المُرْسِل الفعلي بدلًا من القيمة المضبوطة، لأن جوابًا مخزّنًا أو إعدادًا مطبوعًا لا يقول شيئًا عن وجه استعلام جديد.
يحتاج سلوك الفشل إلى خطة ومسار استرداد محفوظ. راقب طلبًا جديدًا بينما النفق غير متاح، وتذكّر أن اتصالًا قديمًا مفتوحًا ليس دليلًا على سياسة الفشل. تأتي دورة الحياة أخيرًا: أعد الملاحظة بعد إعادة اتصال أو إعادة تشغيل خدمة إذا كانت تلك الأحداث تؤثر في المتطلّب.
سجّل الأدلة، لا الحكم
احتفظ لكل نتيجة بسياق العملية والوجهة وعائلة العناوين والوقت والمصدر الملاحَظ. تلك المجموعة دليل محدود على التدفّقات التي اختبرتها، وهي قابلة للدفاع تحديدًا لأنها تقول ما غطّته.
إنها ليست تدقيقًا في سجلات مشغّل VPN، ولا شهادة لكل تطبيق مستقبلي على الجهاز.
اكتب الحدود بجانب النتيجة. الاختبار الذي يذكر ما لم يغطّه ينجو من المراجعة، أما الذي يدّعي أن الجهاز مُتحقَّق منه فلا. أبقِ دليل curl بجانب محدّدات العائلة التي استخدمتها، وأبقِ الجدول ذا الصفوف الأربعة مع النتائج.