هل غيّر الـ VPN إعدادات DNS لدي؟ قارن قبل وبعد
يمكن لملف شخصي أن ينقل استعلاماتك عمدًا. قارن سياسة الخادم الحال والإجابة الفعلية قبل اتصال الـ VPN وبعده، مع تثبيت متغير واحد.
تتصل بالنفق، وتفتح لوحة خاصة، فيُحلّ الاسم إلى عنوان لم تره من قبل. أو يحدث العكس: يظل المتصفح يعمل بينما تتوقف أداة سطر أوامر فجأة عن حل أي شيء. والنتيجتان تأتيان من التغيير نفسه، وغالبًا ما يفسّر الناس ذلك بجملة واحدة عن الـ VPN الذي «يستخدم DNS الخاص به»، وهي ليست دقيقة بما يكفي للتشخيص أو للتحقق. هناك سؤالان مخفيان في تلك الجملة: أي عمليات البحث يُفترض أن يتولّاها هذا الملف الشخصي، وهل أرسل جهازك فعلًا تلك الاستعلامات إلى الخادم الذي أُعطي له؟ الفصل بينهما هو المنهج كله، لأن اختبارًا يخلط بينهما يُنتج إجابة خاطئة وواثقة في الاتجاهين.
لماذا يوفّر الملف الشخصي خادم حل أصلًا
داخل النفق، تُحلّ الأسماء الواقعة خلف الطرف البعيد عادةً إلى عناوين لا وجود لها إلا في تلك الشبكة. والمنطقة الخاصة مثل corp.internal لا تملك تفويضًا عامًا، لذا يجب أن يكون الخادم الذي يجيب عنها متاحًا من داخل النفق. ويخدم الميكانيزم نفسه غرضًا ثانيًا: حين كانت الاستعلامات ستخرج عبر مزوّد خدمة الإنترنت، يُبقي الخادم الواقع في الطرف البعيد الاستعلام داخل المسار المشفّر. ولهذا يصل عنوان خادم DNS كجزء من سياسة الاتصال لا كإعداد عام اخترته مرة واحدة للجهاز.
العنوان وحده لا يحسم شيئًا. لا يمكن للخادم أن يجيب إلا إذا وُجد مسار إليه، وأكثر الأعطال شيوعًا هو خادم لا يُبلَغ إلا ما دام النفق قائمًا. وعندما يسقط النفق وتبقى السياسة، تذهب الاستعلامات إلى عنوان بلا مسار، وتكون العَرَض مهلة انتظار لا خطأً واضحًا. وهذا الفرق مهم عند قراءة نتيجة الاختبار التالية، لأن مهلة الانتظار تدفع الناس إلى إعدادات نقل لم تكن معنية أصلًا.
قارن التصميمين قبل مقارنة الإجابات
النفق الكامل وDNS المنقسم يُنتجان توقعات متعاكسة، وليس أيٌّ منهما عطلًا. في ظل النفق الكامل قد ينتقل كل استعلام إلى المزوّد أو إلى خادم الشركة، لذا فإن تغيّر إجابة الأسماء العامة بعد الاتصال أمر متوقع. وفي ظل DNS المنقسم تذهب النطاقات المدرجة فقط إلى الخادم الخاص بينما يبقى كل شيء آخر محليًا؛ على Windows تعيش قائمة النطاقات في جدول سياسة حل الأسماء، وعلى macOS في نطاقات المطابقة بإعدادات DNS، وعلى مضيف systemd-resolved في نطاقات التوجيه لكل وصلة.
هذه هي المقارنة التي يجب إجراؤها أولًا، لأنها تحدد ما يُعدّ عطلًا. في ظل DNS المنقسم، يكون الاسم العام الذي يجيب من خادم جديد هو ما يستحق التحقيق، بينما الاسم الداخلي الذي يجيب بشكل صحيح هو النظام يؤدي عمله. وفي ظل النفق الكامل، يكون الاسم العام الذي ما زال يجيب من خادم مزوّد الخدمة هو الشذوذ. ويصف توثيق مايكروسوفت لحل أسماء VPN ترتيب Windows لهذه القواعد، بما في ذلك كيف يُستشار إدخال سياسة مطابق قبل خوادم المحوّل نفسه.
هناك خادم ثالث في الغرفة يسهل نسيانه. يحل DNS الآمن في المتصفح الأسماء بنفسه ويمكنه مواصلة الإجابة بعد أن يغيّر النفق سياسة نظام التشغيل، لذا فصفحة تُحمّل تُثبت أن خادم المتصفح عمل، لا أن الملف الشخصي طُبّق. وإذا قارنت فقط ما يعرضه المتصفح، فأنت تختبر الطبقة الخطأ في نصف الحالات.
سجّل خط أساس بمتغيّر واحد فقط
غيّر النفق. لا تغيّر أيضًا الاسم أو الأداة أو لاحقة البحث في الخطوة نفسها. اختر اسمًا يُسمح لك بالاستعلام عنه، ودوّن التطبيق الذي استخدمته، واكتب إما العنوان الذي عاد أو الخطأ بدقة. على Windows يطبع Get-DnsClientServerAddress -AddressFamily IPv4 الخوادم لكل محوّل ويطبع Get-DnsClientNrptPolicy إدخالات السياسة؛ وعلى Linux مع systemd-resolved يعرض resolvectl status خوادم DNS ونطاقات التوجيه لكل وصلة؛ وعلى macOS يطبع scutil --dns ترتيب الخوادم الذي سيتبعه النظام فعليًا.
ثم اتصل عبر عناصر التحكم العادية في العميل وكرّر الأوامر نفسها بالضبط. احتفظ بالمخرجات الأولى بدلًا من تذكّرها، لأن المقارنة هي كل الغاية، والقراءة الثانية المأخوذة بعد تفريغ الذاكرة المؤقتة أصبحت قياسًا آخر. وإذا أُخذ خط الأساس والمتصفح في المقدمة وجرى تشغيل ما بعد الاتصال في طرفية، فأنت تقارن خادمين لا حالتين لخادم واحد.
الاستعلام الصريح وبحث التطبيق اختباران مختلفان
سؤال خادم واحد محدد، بـ nslookup name 10.20.0.1 أو dig @10.20.0.1 name، يُثبت شيئًا واحدًا: أن الخادم الذي سميته يجيب عندما تستطيع الوصول إليه. وهو يتجاوز منطق الاختيار كليًا، لذا لا يمكنه أن يخبرك هل كان النظام سيختار ذلك الخادم لهذا الاسم. استخدمه لاختبار ما إذا كان الخادم المعيَّن متاحًا، ولا تستخدمه لاختبار السياسة.
البحث عبر الخادم المحلي يمارس الاختيار فعلًا. يمر resolvectl query name على قواعد نطاق التوجيه نفسها ويبلّغ عن البروتوكول الذي أجاب، و Resolve-DnsName على Windows يمر عبر جدول السياسة وذاكرة العميل المؤقتة، ويعرض scutil --dns الترتيب الذي سيتبعه البحث. شغّل النوعين، واحتفظ بهما في عمودين منفصلين في ملاحظاتك. الاستعلام الصريح الناجح بجانب بحث تطبيق فاشل هو مشكلة توجيه أو اختيار، لا خادم يرفض العمل.
التخزين المؤقت يقف بينك وبين الإجابة. نظام التشغيل والخادم المحلي والمتصفح والتخزين السلبي كلها تحتفظ بالنتائج، لذا يمكن لبحث أن ينجح دون أن يغادر حزمة واحدة الجهاز. سجّل النتيجة قبل تفريغ أي شيء: ipconfig /flushdns أو resolvectl flush-caches أو sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder على macOS. تجاوز إعادة تعيين الشبكة الواسعة في هذه المرحلة، لأنها تدمّر الأدلة التي ما زلت تجمعها.
ماذا يعني الفرق
قارن الصفين اللذين سجّلتهما وصنّف التغيير قبل أن تلمس أي إعداد.
| Observation after connect | Most likely cause | Next step |
|---|---|---|
| Answer moves to a private address range | Expected under split DNS or a private zone | Confirm the suffix is in the effective policy, then test the service |
| Lookup times out while connected, works after disconnect | The assigned resolver has no route from this machine | Probe it with an explicit query, then re-read the policy |
| Internal name fails, public names work | Wrong namespace or a suffix missing from the policy | Query the fully qualified name and check the domain list per platform |
| Internal name returns a public address | Split DNS not applied; a public resolver answered | Check browser secure DNS first, then the per-link domain list |
صف واحد يستحق التشديد. الاسم الذي يُحلّ ليس خدمة تعمل، ونجاح DNS يقول فقط إن عنوانًا وُجد. ولا يقول شيئًا عن إعادة التوجيه أو قواعد الجدار الناري أو ما إذا كان حسابك يسمح له باستخدام الخدمة أصلًا، لذا أنهِ الأمر باختبار التطبيق الفعلي بدلًا من افتراض أن العطل ابتعد من تلقاء نفسه.
أعِد خط الأساس وتحقق منه
افصل الاتصال عبر عناصر التحكم الخاصة بالعميل بدلًا من إنهاء العملية، ثم أعد قراءة الأوامر الثلاثة نفسها. يجب أن تعود خوادم كل وصلة وإدخالات السياسة والإجابة عن اسم الاختبار إلى خط الأساس الذي كتبته سابقًا. إدخال سياسة متبقٍّ بعد فصل نظيف عيب حقيقي يستحق التسجيل، وهو أيضًا سبب كون التعديلات اليدوية على ملف resolver مُولَّد عادة سيئة: يُعاد كتابة الملف فيختفي التعديل، أو يبقى التعديل فيثبّت resolver لم يعد له مسار.
اعمل بهذه القائمة مرة واحدة، بالترتيب. قرّر أي تصميم ينفّذه الملف الشخصي قبل الحكم على أي نتيجة. أبقِ الاسم والأداة واللاحقة ثابتة عبر التشغيلين. افصل الاستعلام الصريح عن بحث التطبيق. اقرأ السياسة الفعّالة، لا الإجابة فقط. فرّغ ذاكرات التخزين أخيرًا، بعد كتابة المقارنة. تحقّق بالتطبيق الحقيقي، ثم أعد التشغيل مرة واحدة وتأكد أن حالة الفصل ما زالت نظيفة.