إلى أين يذهب DNS عند دمج Tor مع VPN

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

سمِّ كل تبادل قبل أن تصفه بالتسريب

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

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

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

استعلام الإقلاع يحدث قبل النفق

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

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

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

المتصفح وبقية الجهاز يختلفان

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

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

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

افحص كل برنامج ثم قارن بالقصد

نفّذ الملاحظات منفصلة: ما سيستخدمه النظام، وما صُهّر عليه المتصفح، وهل يحمل اتصال SOCKS اسمًا أم عنوانًا. وهذا الأخير هو الفرق بين الحل البعيد والحل المحلي، و مواصفات امتدادات SOCKS تصف كيف يُمرَّر اسم المضيف بدلًا من حله أولًا.

resolvectl status | grep -E "Current DNS Server|DNS Servers"
ss -tnp '( dport = :9050 )'
dig +short dev.internal.example
getent hosts vpn-endpoint.example.net

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

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