VPN متصل لكن خدمة واحدة تفشل: اعزل المرحلة

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

ابدأ بالاسم، لا بالنفق

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

resolvectl query host.internal
getent hosts host.internal

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

اسأل النواة أي مسار اختارت

جدول التوجيه ترتيب تفضيل، والمسار الذي تختاره النواة ليس دائمًا ما يعرضه الرسم. اسألها مباشرة عن الوجهة المعنية. يسمّي الجواب الواجهة والخطوة التالية وعنوان المصدر الذي سيُستخدم. قد تخرج الحزمة عبر النفق حاملةً عنوان مصدر يرفضه الطرف البعيد، وقد يُخرجها مدخل أكثر تحديدًا في الجدول الفيزيائي من واجهة Wi-Fi بدلًا من ذلك.

ip route get 10.20.30.40
ip -brief address show

اقرأ حقول dev ثم via ثم src بهذا الترتيب، لأن كلًا منها يستبعد شكًا مختلفًا. تملك هذه المرحلة أيضًا الحالة التي ثبّتها العميل، لأن قواعد جدار الحماية والمسارات قد تبقى بعد خروج غير طبيعي. لهذا فإن «لا إنترنت دون النفق» و«لا إنترنت ما لم يعمل العميل» عائلة عطل واحدة لا عائلتان.

اختبر حجم الحزمة

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

ping -M do -s 1400 10.20.30.40

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

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

اختبر الطرف البعيد

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

curl -sv http://10.20.30.41:8080/health
nc -vz -w 3 10.20.30.41 3389
ss -lnt 'sport = :8080'

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

طابِق الشكوى بمرحلة واحدة

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

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

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