هل يعيد openfortivpn كتابة DNS باستمرار؟ اعثر على المالك الحقيقي

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

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

ابدأ بما غيّرته الوصلة فعلاً

اتصل مرة واحدة بأمرك المعتاد وقارن الحل قبل وبعد. على مضيف Linux يشغّل systemd-resolved، يطبع resolvectl status خوادم DNS ونطاقات البحث لكل وصلة، ووصلة tun أو ppp جديدة تحمل خوادمها الخاصة هي البصمة الدالة على تحديث من جهة العميل. على macOS، يعرض scutil --dns إعداد أداة الحل بالترتيب الذي تراجعه التطبيقات.

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

المفتاحان والكاتب الذي يكبحه كل منهما

يوثّق openfortivpn مقطع خيارات يطفئ الكاتبين الذين يمكنه التحكم فيهما، ولكل مفتاح مقابل مكتوب بالكامل يعامله الدليل الإرشادي بالإعداد نفسه.

openfortivpn gw.example.com:443 --no-dns --pppd-no-peerdns
# written out in long form
openfortivpn gw.example.com:443 --set-dns=0 --pppd-use-peerdns=0

--no-dns يمنع العميل من تطبيق خوادم DNS التي تعلّمها من البوابة، بينما --pppd-no-peerdns يمنع pppd من دفع DNS النظير إلى النظام. ويحذّر دليل openfortivpn من أن تحديثات DNS في PPP قد تتسابق مع تحديثات DNS الخاصة بالعميل، ولهذا ينبغي أن يكون المفتاحان معاً في المقطع بدلاً من اعتبار أي منهما كافياً.

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

اختر المالك قبل أن تعطّل أي شيء

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

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

افحص الحل لكل وصلة، لا لكل ملف

ملف /etc/resolv.conf واحد ليس جرداً لما تستخدمه التطبيقات فعلاً على مضيف يعمل بحل محدود النطاق أو لكل نطاق، لذا اقرأ حالة أداة الحل بالطريقة التي تعرضها بها المنصة.

resolvectl status
resolvectl query vpn.internal.example.com
resolvectl query example.com
ip route get 10.20.0.53

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

أعد الاتصال وأكّد الحالة المنفصلة

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

ثم أعد الاتصال واقرأ القيم الثلاث نفسها مرة أخرى: عنوان أداة الحل، ونطاقات البحث، والواجهة.

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