Pi-hole و VPN روی یک Pi: آیا سیستم‌عامل هنوز پشتیبانی می‌شود؟

در جعبه‌ای ترکیبی از Pi-hole و VPN دو چیز با هم اشتباه می‌شوند: خانوادهٔ توزیعی که نصب کرده‌اید و نسخه به‌همراه معماری‌ای که اجزا واقعاً پشتیبانی می‌کنند. بوردی که یک ایمیج را بوت می‌کند ثابت می‌کند که کرنل اجرا می‌شود؛ ثابت نمی‌کند که باینری FTL مربوط به Pi-hole و نصب‌کنندهٔ VPN شما یک فضای کاربر را هدف گرفته‌اند. آزمون واقعی هم‌پوشانی چهارطرفهٔ پشتیبانی بورد، شاخهٔ نسخه، معماری بسته‌ها و مسیر ارتقایی است که خودتان بتوانید آن را پیش ببرید. هر یک از این چهار پایه را از دست بدهید و دستگاه این هفته کار می‌کند و بعد در به‌روزرسانی امنیتی بعدی رهایتان می‌کند.

پشتیبانی را شاخهٔ نسخه تعیین می‌کند، نه نام خانواده

بپرسید پروژه هنوز روی کدام نسخه آزمایش می‌کند، بعد پاسخ را به‌صورت رشتهٔ نسخه بنویسید نه Debian. صفحهٔ پیش‌نیازهای Pi-hole سیستم‌عامل‌های پشتیبانی‌شده و معماری‌های ازپیش‌ساختهٔ 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 بیتی معمولاً سریع‌تر از بازسازی زنجیرهٔ ابزاری است که ناسازگاری را ساخته است.

بازاریابی بورد هم این را حل نمی‌کند. اندازهٔ حافظه و مدل CPU هیچ چیزی دربارهٔ اینکه بسته‌هایتان به کدام 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 را روی آدرس LAN قابل دسترس می‌خواهید، و این یعنی سرویس مدیریت نباید به هیچ‌کدام وابسته باشد.

ارتقای بعدی را بخشی از انتخاب کنید

نسخه‌ای که نمی‌توانید ارتقا دهید سقف پشتیبانی‌ای است که از قبل پذیرفته‌اید. مکانیک ارتقا را روی یک کارت یدکی آزمایش کنید پیش از آنکه دستگاه DNS خانه‌تان را حمل کند، و بخوانید پروژه‌ها دربارهٔ جهیدن بین شاخه‌ها چه می‌گویند، به‌جای اینکه فرض کنید ارتقای بسته کافی است.

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

بسته‌های نگه‌داشته‌شده دلیل معمول این‌اند که یک ارتقا موفق به نظر می‌رسد و هیچ چیز را تغییر نمی‌دهد. قفل‌ها را عمداً یکی‌یکی بردارید و یادداشت کنید کدام سرویس به آن سنجاق نیاز داشت.

قبل از جهش، پیکربندی Pi-hole، اجاره‌های ایستا و هر پروفایل تونل را صادر کنید و تأیید کنید که می‌توانید آن‌ها را روی یک ایمیج تازه بازگردانید. بعد از جهش، DNS معمولی کلاینت‌ها، منبع خصوصی پشت تونل، اتصال دوباره و هر قاعدهٔ ارسال روی گیت‌وی را آزمایش کنید. جعبه‌ای که بوت می‌شود و به ping پاسخ می‌دهد تقریباً هیچ چیزی را پاس نکرده است.

وقتی هیچ نسخهٔ واحدی به هر دو سرویس نمی‌خورد

گاهی هم‌پوشانی خالی است: راهنمای VPN به نسخه‌ای تازه‌تر از بستهٔ Pi-hole که می‌توانید نصب کنید رفته، یا ایمیج فروشندهٔ بورد از هر دو عقب افتاده. در این حالت نقش‌ها را جدا کنید به‌جای اینکه فرادادهٔ نسخه را برای راضی‌کردن نصب‌کننده ویرایش کنید. دو دستگاه کوچک، یا یک دستگاه به‌علاوهٔ یک کانتینر برای سرویس دوم، کمتر از دستگاهی تمام می‌شوند که داستان پشتیبانی‌اش بر یک دروغ تکیه دارد.

جعل نسخه تنها میان‌بری است که باید قاطعانه رد کنید. مدیران بسته به آنچه فایل نسخه می‌گوید اعتماد می‌کنند، پس شناسهٔ جعلی نصبی به شما می‌دهد که هیچ‌یک از دو پروژه در اشکال‌زدایی‌اش کمکتان نمی‌کند.

اگر دو نسخهٔ کنونی همه چیز را برآورده می‌کنند، آن یکی را انتخاب کنید که یادداشت‌های ارتقایش را بدون حدس‌زدن می‌توانید دنبال کنید، و دست از جست‌وجو بردارید. بعد نسخه، معماری، مالکان سرویس‌ها و مرحلهٔ بازگردانی را در یک جا ثبت کنید، چون نفر بعدی که کارت SD را لمس می‌کند به هر چهار مورد نیاز خواهد داشت.