هل يُستخدم DNS الخاص بـ VPN فعلاً؟ التقط المنفذ 53 وشاهد

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

الخيار المدفوع ليس استعلاماً

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

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

افحص ما تحمله الواجهة فعلاً

على Linux قد يكون مُحلِّل النظام هو الملف العادي أو NetworkManager أو systemd-resolved، وأيها يملكه يحدد أين يستقر الخادم المدفوع. عملية OpenVPN السطرية لا تحدّث مُحلِّل النظام من تلقاء نفسها، لذا فالتكامل الموثق هو سكربت up/down أو مدير اتصال يعرف مسبقاً كيف يطبق الإعدادات. وتشغيل الاثنين معاً طريقة فعّالة لخلق سباق.

resolvectl status
cat /etc/resolv.conf

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

تتبَّع استعلاماً واحداً خارج الجهاز

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

sudo tcpdump -ni tun0 port 53
sudo tcpdump -ni any port 53

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

الجدار الناري الذي لا يقبل إلا DNS الخاص به

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

sudo iptables -S OUTPUT
sudo iptables -S | grep -i -E 'dns|53'

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

sudo iptables -I OUTPUT 1 -p udp --dport 53 -d 172.20.8.1 -j ACCEPT

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

لماذا تثبت صفحة التسريب أقل مما يبدو

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

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