ما تستطيع شاشة iftop إثباته عن VPN وما لا تستطيع

تجيب شاشة iftop عن سؤال واحد في كل مرة: أي أزواج المضيفين تتبادل البايتات عبر الواجهة التي وجهتها إليها. ولا تجيب عما إذا كانت كل التطبيقات تتبع سياسة VPN، والشاشة الفارغة لا تثبت أن شيئًا لم يتسرب. والفجوة بين هذين القولين هي حيث تخطئ معظم مناقشات اختبار التسرب. وثلاثة شروط تحدد ما يعنيه العرض فعلًا، وكلها الثلاثة ظاهرة في سطر الأوامر الذي استخدمته.

ثلاثة شروط تحدد معنى الشاشة

الشروط هي: أي واجهة تُعرض، وما يخفيه عامل التصفية والأداة نفسها، وما اختبره الاختبار فعلًا. أجب عنها بهذا الترتيب، لأن خطأً في الشرط الأول يجعل الآخرين بلا معنى.

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

الشرط الأول: أي واجهة تُعرض

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

مرّر الواجهة دائمًا، واكتبها بجانب النتيجة. ولقطة شاشة بلا اسم الواجهة لا يمكن إعادة إنتاجها.

الشرط الثاني: ما يخفيه عامل التصفية والأداة

تقبل iftop تعبير تصفية، والتدفق الذي يستبعده عامل التصفية غير مرئي بحكم التركيب لا بحكم الغياب. كما تجري الأداة افتراضيًا عمليات بحث عن أسماء المضيفين لوسم العناوين، وتولّد تلك البحوث حركة DNS خاصة بها، وهي حركة لم تقصد مراقبتها. ويعطّل -n عمليات البحث ويجعل العرض رقميًا؛ وإخفاء صفوف DNS بعد ذلك ليس كعدم توليد الاستعلامات.

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

الشرط الثالث: ما اختبره الاختبار فعلًا

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

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

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

استخدام iftop كدليل مساند

عندئذٍ فقط تضيف iftop قيمة، وتضيفها كتأكيد. ويُظهر sudo iftop -i wg0 -n -B -P -f "host 203.0.113.9" هل يظهر التدفق الذي توقعته على الواجهة التي توقعتها، مع أعداد بايتات تجعل ادعاء الخمول قابلًا للفحص.

قارن ذلك بـ ss -tnp للعرض على مستوى المقبس وبـ ip route get للمسار الذي ستختاره النواة، فتصبح لديك ثلاث مشاهدات لطلب واحد بدل انطباع واحد عن جهاز. دليل iftop يوثّق اختيار الواجهة وصيغة عامل التصفية وسلوك البحث، وهي الأمور الثلاثة التي يعتمد عليها اختبار التسرب. فشاشة النطاق الترددي تحدد موقع النشاط؛ والمسار والاستثناءات وسلوك الفشل تحدد هل يلبي ذلك النشاط الشرط.