لماذا لا يُثبت تصنيف الدولة في DNS وجود تسريب في VPN

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

اقرأ ما لاحظه الاختبار فعلًا

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

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

الـ anycast والتمرير يفسّران معظم المفاجآت

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

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

لذلك يمكن لأداة حل مضبوطة أن تكون صحيحة ومع ذلك تنتج نتيجة تبدو أجنبية، ويمكن لأداة حل في بلدك أن تكون الخاطئة لأنها تتبع طرفًا لم تختره.

من تلقّى الاسم، وبأي مسار

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

resolvectl query example.com
resolvectl status | grep -A3 'DNS Servers'
dig +short TXT whoami.akamai.net

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

قارن بالسياسة التي اخترتها

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

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

اجعل الاختبارات ضيقة وآمنة

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

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