هل تمر الحركة فعلاً عبر الـ VPN؟ كيف تتحقق من ذلك

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

ابدأ بالمسار الذي ستسلكه الحزمة

جدول التوجيه هو القرار، لذا اسأله عن وجهة واحدة بدل قراءة الجدول كله وتخمينه. على Linux، يعرض ip route get الواجهة وعنوان المصدر اللذين اختارهما النواة:

ip route get 203.0.113.10
ip route get 10.20.5.7

على Windows، يكون Find-NetRoute -RemoteIPAddress 203.0.113.10 أنفع من route print -4 للسبب نفسه: فهو يبلّغ عن المسار الذي فاز، لا عن كل مسار موجود. اقرأ الجدول مرة واحدة على أي حال بحثاً عن صف 0.0.0.0. وجود زوج /1 هناك يعني أن عميل النفق الكامل أعاد كتابة المسار الافتراضي: فخيار redirect-gateway def1 في OpenVPN يثبّت 0.0.0.0/1 و 128.0.0.0/1 عبر النفق، وهو يتغلب على 0.0.0.0/0 الموجود بمطابقة أطول بادئة دون حذف المسار الفيزيائي الافتراضي. ولهذا يمكن أن يتعايش مساران افتراضيان بينما يظل كل شيء يدخل النفق.

تفصيلان يجعلان الجدول يكذب. أولاً، انظر إلى البادئة التي طابقت بدل عدد المسارات الافتراضية، لأن مقياس الواجهة أو زوج /1 هو ما يحدد الفائز. ثانياً، الاتصال الموجود مسبقاً يحتفظ بالمسار الذي أُنشئ به؛ فبعد صعود النفق قد تظل الجلسة المفتوحة تستخدم المسار القديم إلى أن تُعاد، ولهذا يبدو أن إعادة الاتصال تُصلح مشكلة توجيه. العميل العامل — ps ax | grep openvpn — لا يثبت إلا أن العملية بدأت.

تتبّع اسماً داخلياً واسماً عاماً واحداً

البحث في المسار يُظهر النية؛ والمسار يُظهر التسليم. تتبّع اسماً يجب أن يكون داخلياً واسماً يجب ألا يكون كذلك، أثناء الاتصال، ثم قارن أول قفزة:

traceroute intranet.corp.example
traceroute 1.1.1.1

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

تجعل ICMP المفلترة هذا الفحص يكذب: نجوم في المتابعتين تبدو كنفق ميت وهي غالباً جدار حماية. جرّب منفذ TCP حيث يمكنك — traceroute -T -p 443 على Linux — وتذكّر أن التتبّع لا يقول أي مُحلّل أجاب: فقد يُحلّ الاسم محلياً ويظل الوصول إليه عبر النفق.

التقط على المحوّل الفيزيائي، لا على النفق

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

sudo tcpdump -ni eth0 udp port 53
sudo tcpdump -ni eth0 host 10.20.0.5

يمسك المرشّح الأول حلّ الأسماء الخارج محلياً، وهو أكثر تسريب شيوعاً وأخفه — فالصفحة تُحمّل مع ذلك، والمُحلّل رأى الاستعلام فقط. ويمسك الثاني الحركة العادية إلى عنوان داخلي يجب ألا يوجد إلا داخل النفق. على Windows يؤدي pktmon المهمة نفسها بلا برنامج تشغيل: pktmon filter add -p 53، ثم pktmon start --capture --pkt-size 128، ثم pktmon stop و pktmon format pktmon.etl -o capture.txt. تختلف هذه الأعلام قليلاً بين إصدارات Windows، لذا راجع pktmon filter add /? قبل الوثوق بالصياغة.

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

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

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

sudo curl --interface tun0 https://example.net/ip
sudo curl --interface eth0 https://example.net/ip

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

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

استخدم عرض الخادم لتأكيد النظير

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

فخّان يقيمان هنا. النفق المُقنَّع يجعل كل تدفق يبدو صادراً من البوابة، فتتراص السجلات والمحاسبة لكل عميل على عنوان واحد. ويُعامَل العميل كمضيف محلي، فالسؤال عن شخص ينسخ ملفات عبر VPN يُجاب عنه بحركة مشاركة الملفات على الخادم أو بتدقيق المضيف على الخادم — فمراقبة النفق تعطي نقاط النهاية والحجم، لا أسماء الملفات.

ميّز قرار التصميم من التسريب

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

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

حين تختلف الفحوص، عادةً يسمّي الاختلاف العطل:

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