هل تحتاج إلى DNS ديناميكي لخادم VPN منزلي؟

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

الشرط الأول: عنوانك يتغير فعلًا

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

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

curl -fsS https://api.ipify.org; echo

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

الشرط الثاني: العملاء يبحثون عن الاسم مرة أخرى

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

OpenVPN يعيد تحليل السطر remote vpn.example.net 1194 في كل مرة يعيد الاتصال، و resolv-retry infinite يبقيه يعيد المحاولة بدلًا من الخروج عندما يفشل البحث. وعلى الخادم، float يجعل الجلسة القائمة تتبع نظيرًا تغيّر عنوان مصدره. أما WireGuard فهو أكثر مباشرة: wg-quick up يحلل Endpoint عند تطبيق الإعداد، ويعيد العميل تحليله عندما يعيد بناء النفق، لذا فمصافحة ما زالت تنجح مع العنوان القديم تظل تنجح حتى تتوقف.

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

الشرط الثالث: مسار الدخول ما زال مفتوحًا

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

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

ماذا تشغل عندما تتحقق الشروط الثلاثة

ddclient هو برنامج التحديث الأقل مفاجأة لمضيف صغير. إعداد أدنى ينشر العنوان الذي يراه المزود، وهو ما يتجنب خطأ NAT المزدوج:

protocol=dyndns2
use=web, web=https://api.ipify.org
server=updates.your-dns-provider.net
login=vpn-home
password=update-token
vpn.example.net

شغّله من مؤقت systemd كل بضع دقائق بدلًا من حلقة shell، وسجّل رد المزود بدلًا من افتراض النجاح. عامل بيانات الاعتماد مثل مفتاح، لأنها تحدد إلى أين يُرسل كل عميل: استخدم رمز تحديث محدود النطاق بدلًا من كلمة مرور الحساب، وأبقِ الملف على الوضع 0600، وأرسل التحديثات عبر HTTPS.

تحقق قبل أن تلتزم

بحث واحد يخبرك بما يراه بقية العالم، ويطبع مدة TTL التي عليك انتظارها بعد تغيير:

dig +noall +answer vpn.example.net @1.1.1.1

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

احتفظ بتراجع يستغرق دقيقة: سجّل آخر عنوان عامل ومدة TTL السابقة، حتى تنشر الاثنين يدويًا بينما يمر المزود بفترة سيئة.

عندما تكون الإجابة لا

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

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

قبل أن تنتقل، أكّد أربعة أشياء بالترتيب:

• العنوان الذي ينشره برنامج التحديث يطابق عنوان WAN في الراوتر.
• مدة TTL للسجل قصيرة بما يكفي ليظهر التغيير خلال دقائق.
• تحويل المنفذ مرتبط بالواجهة، لا بعنوان ثابت.
• عميل حقيقي واحد أعاد الاتصال ومرر حركة منذ آخر تغيير.

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