هل يشفّر VPN لديك استعلامات DNS، أم القفزة التالية فقط؟

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

دوِّن من يتلقى الاستعلام في كل مرحلة قبل أن تمسّ ملف إعدادات.

ترتيبان يبدوان متطابقين على صفحة الإعدادات

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

الفرق قابل للقياس لا فلسفي. ابحث عن جلسة TLS على العميل أو على الخادم، فتعرف أي ترتيب لديك في الواقع.

ارسم سلسلة المُحلِّلات قبل أن تغيّرها

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

ثم اسأل أي مكوّن صُمّم العميل لاستخدامه. عنوان DNS الذي يدفعه ملف تعريف VPN يدلّك على وجهة الاستعلامات، لا على العملية التي تجيب عنها.

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

تحقّق من القفزة المشفّرة

ابدأ من العميل وتأكد مما إذا كان يحمل جلسة TLS إلى المنفذ 853. فالاستعلام الذي يُحلّ بنجاح عبر المنفذ 53 لا يثبت شيئًا عن التشفير.

resolvectl status | grep -E "DNS Servers|DNS over TLS"
kdig +tls +tls-ca +tls-hostname=dns.example.net @198.51.100.53 example.com A

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

ss -tunp '( dport = :853 )'
dig @127.0.0.1 example.com A +short

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

سجّل المالك وسلوك الفشل

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

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

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