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

مغلفان ورابط فيزيائي واحد

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

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

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

راقب طلبًا واحدًا وهو يقطع الرحلة

اختر وجهة واسأل النواة أي واجهة ستستخدم. هذا الأمر الواحد يحسم معظم الجدال حول ما إذا كان النفق يفعل شيئًا:

ip route get 203.0.113.7
ip -brief addr show
ip -4 addr show dev wg0

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

ثم انظر إلى القفزة الأولى من داخل المغلف، وقارنها بالقفزة الأولى خارجه:

traceroute -n -m 3 203.0.113.7
sudo tcpdump -ni wg0 -c 5

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

ثلاثة عناوين، وموقع واحد فقط يراها

يخلط الناس بين هذه الأمور باستمرار، ويُنتج الخلط تقارير تسرب كاذبة. فهي حقول مختلفة في ترويسات مختلفة بأعمار مختلفة.

AddressWhere it appearsWho can see it
Endpoint addressOuter header, the peer you connect toYour access network and the path to it
Inner tunnel addressInside the envelope, on the virtual interfaceThe peer, and anything the peer routes to
Exit addressSource of the packet that reaches the websiteThe website and its upstream

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

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

أين يُفتح المغلف، وما ينجو منه

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

لا ينجو شيء آخر بشكل افتراضي. فالطلب غير المشفر يكون مقروءًا عند المخرج تمامًا كما كان مقروءًا على شبكة Wi-Fi في المقهى، ولا يضيف النفق حماية لم تكن للتطبيق أصلًا. وبالمثل تحدد قواعد جدار الحماية وسياسة التمرير عند المخرج ما يحدث بعد ذلك؛ فالمصافحة الناجحة حقيقة عن اتصال النظير لا عن بقية الرحلة.

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

تحقق من المسار الذي سلكه التطبيق فعلًا

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

getent hosts example.com
ip route get "$(getent hosts example.com | awk '{print $1; exit}')"
ss -tnp state established '( dport = :443 )'

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

تصف بنية أمان RFC 4301 النسخة الخاصة بطبقة IP من هذا اللف في IPsec، وينطبق منطق الطبقات نفسه على WireGuard و OpenVPN. وما إن تستطيع الإشارة إلى الحزمة الداخلية والحزمة الخارجية ككائنين منفصلين حتى يكف معظم سلوك النفق عن أن يكون غامضًا ويصير جدول توجيه يمكنك قراءته.

مقالات ذات صلة