Pi-hole مع VPN على جهاز Pi واحد: هل نظام التشغيل ما زال مدعومًا؟

يختلط أمران في جهاز واحد يجمع Pi-hole وVPN: عائلة التوزيعة التي ثبّتها، والإصدار مع المعمارية التي تدعمهما المكوّنات فعليًا. اللوحة التي تُقلع من صورة ما تُثبت أن النواة تعمل؛ لكنها لا تُثبت أن ملف FTL الثنائي الخاص بـPi-hole ومثبّت VPN يستهدفان مساحة المستخدم نفسها. الاختبار الحقيقي هو تقاطع رباعي بين دعم اللوحة وفرع الإصدار ومعمارية الحزم ومسار ترقية تستطيع تشغيله بنفسك. أضِع أي ضلع من هذه الأضلاع، فيعمل الجهاز هذا الأسبوع ثم يتركك في التحديث الأمني التالي.

فرع الإصدار هو الذي يحدد الدعم، لا اسم العائلة

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

الصورة القديمة التي ما زالت تُقلع على جهاز Pi ليست دليلًا على الدعم. فاللوحة سليمة، وفهرس الحزم قديم، ويظهر عدم التطابق لاحقًا حين يسحب المثبّت تبعية لم يعد الإصدار قادرًا على تلبيتها.

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

طابِق هدف الملف الثنائي مع مساحة المستخدم لديك

المعمارية هي الفشل الأهدأ. نواة 64 بت مع مساحة مستخدم 32 بت مزيج حقيقي ومدعوم على عدة لوحات، وهي تشغّل ملف FTL ثنائيًا ب32 بت دون شكوى، إلى اللحظة التي تثبّت فيها شيئًا منشورًا لarm64 فقط. اطبع النصفين قبل أن تختار صورة، واحفظ المُخرَج بجانب ملاحظاتك.

uname -m
dpkg --print-architecture
grep -E '^(PRETTY_NAME|VERSION_ID)=' /etc/os-release
apt-cache policy pihole-ftl

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

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

جهاز واحد، خدمتان، ومالك واحد للشبكة

حدّد مَن يملك العنونة والمُحلّل والنفق قبل تثبيت أول حزمة، وإلا انتهت خدمتان إلى المطالبة بالواجب نفسه ولم تفز أي منهما بصفاء. امنح Pi عنوانًا ثابتًا خارج نطاق DHCP الذي يوزعه الموجّه، وأبقِ النفق على شبكة فرعية خاصة به: 192.168.50.10 لجهاز Pi و10.42.0.0/24 للنفق تقسيم عملي، والأرقام نفسها اعتباطية ما دامت لا تتصادم مع ما يخدمه موجّهك أصلًا. ثم اكتب أي مكوّن يجيب على المنفذ 53، وأيها يوزّع DHCP إن كنت تستخدمه، وأيها يملك المسار الافتراضي ما دام النفق قائمًا. في صورة بلا واجهة رسومية تنتمي هذه المهمة الأخيرة إلى NetworkManager أو systemd-networkd، ثم تثبيت عميل مزوّد يعيد أيضًا كتابة إعدادات المُحلّل هو الطريق الذي ينتهي به الناس إلى نفق حي وDNS ميت.

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

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

اجعل الترقية التالية جزءًا من الاختيار

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

sudo apt update
apt-mark showhold
sudo apt full-upgrade
pihole -up

الحزم المثبَّتة هي السبب المعتاد في أن تبدو الترقية ناجحة ولا تغيّر شيئًا. أزِل التثبيت عمدًا، حزمة تلو الأخرى، ودوّن أي خدمة احتاجت إلى التثبيت.

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

حين لا يناسب أي إصدار واحد الخدمتين

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

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

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