ddclient ينشر عنوان خروج VPN: أصلح مصدر الاكتشاف

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

تأكّد ممّا يُفترض أن يصل إليه الاسم

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

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

عناوين الواجهات تحتاج أيضًا إلى تفسير. عنوان حاسوب محمول خلف موجّه منزلي ليس عنوان WAN العام، وحتى عنوان WAN للموجّه قد يقف خلف NAT من نوع carrier-grade، حيث لا يمكن لنشره أن يحقّق وصولًا واردًا.

أعِد إنتاج القيمة قبل تغيير أي شيء

راقب المسارين منفصلين. مع رفع النفق، يبلّغ الفحص عن الخروج؛ ومع إغلاق النفق، أو مع ربط الفحص بالواجهة الفيزيائية، يبلّغ عن عنوان المنزل: curl --interface eth0 https://ifconfig.me. إذا اختلف الجوابان، فقد أعدت إنتاج العطل دون أن تمسّ أداة التحديث.

ثم شغّل العميل في وضع يفحص الإعداد دون تنفيذ تحديث، مثل ddclient -verbose -noexec، واقرأ أي طريقة اكتشاف اختار. يذكر الخرج المطوّل الطريقة والقيمة التي حصل عليها، وهذه هي الحقيقة التي تحتاجها قبل تحرير أي شيء.

وجّه الاكتشاف إلى المسار المختار

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

بالنسبة لمسار حالة الموجّه، تستخدم إصدارات ddclient الأحدث عائلة الخيارات usev4 و fwv4، مع نمط تخطٍّ اختياري لنص الصفحة المحيط. راجع README الخاص بالإصدار المثبّت لديك، لأن الإصدارات الأقدم تكتب الفكرة نفسها بـ use و fw، واسم خيار منسوخ من إصدار خاطئ يفشل عند بدء التشغيل.

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

أبقِ الأسرار والإصدارات مستقيمة

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

إن ddclient README يوثّق مناهج الاكتشاف وأسماء خياراتها. لا تخلط نتائج IPv4 و IPv6 في سجل واحد، ولا تفترض أن خيارًا موجودًا في إصدار موجود في آخر.

تحقّق من القيمة، ثم من قابلية الوصول

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

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