ما يكشفه ردّ STUN حين يعمل VPN على الموجّه

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

هذا هو الجزء الذي يستحق التمهّل. عبارة «المتصفّح لا يملك عنوان VPN» تجيب عن سؤال يخصّ الواجهات، بينما العنوان المنعكس إجابة عن مسار عبر الترجمة. والخلط بين الاثنين ينتج استنتاجات واثقة بشأن الكشف لا تدعمها الأدلة.

جهازان، ومجموعتان من الواجهات

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

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

ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ips

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

ما يُسمح لردّ Binding بأن يقوله

RFC 8489 يعرّف طلب Binding واستجابته، حيث يبلّغ الخادم عن عنوان النقل المصدر الذي لاحظه لذلك الطلب. إنه تصريح عن خماسية واحدة في لحظة واحدة، لا إحصاء لواجهات العميل. لذلك يحدث كل ما يهم بين العميل ونقطة الملاحظة.

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

ثلاث حالات تتشابه وليست واحدة

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

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

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

الجمع ليس اختيارًا

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

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

حدّد السياسة، ثم اقرأ الجواب

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

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

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