একটি Pi-তে Pi-hole ও VPN: অপারেটিং সিস্টেম কি এখনও সমর্থিত?

Pi-hole ও VPN একসাথে থাকা একটি বাক্সে দুটি জিনিস গুলিয়ে যায়: আপনি যে ডিস্ট্রিবিউশন পরিবার ইনস্টল করেছেন, আর কম্পোনেন্টগুলো আসলে যে রিলিজ ও আর্কিটেকচার সমর্থন করে। একটি ইমেজ বুট হয় বলে বোর্ডটি কেবল কার্নেল চালায় তা প্রমাণ হয়; Pi-hole-এর FTL বাইনারি আর আপনার VPN ইনস্টলার একই ব্যবহারকারী-স্পেস লক্ষ্য করে কি না তা প্রমাণ হয় না। আসল পরীক্ষা হলো বোর্ড সমর্থন, রিলিজ শাখা, প্যাকেজ আর্কিটেকচার আর আপনি নিজে চালাতে পারেন এমন আপগ্রেড পথের চারমুখী ওভারল্যাপ। এর যেকোনো একটি পা হারালে যন্ত্রটি এই সপ্তাহে চলবে, তারপর পরের নিরাপত্তা হালনাগাদে আপনাকে আটকে ফেলবে।

সমর্থন ঠিক করে রিলিজ শাখা, পরিবারের নাম নয়

প্রকল্পটি এখনও কোন রিলিজের বিপরীতে পরীক্ষা করে জিজ্ঞাসা করুন, তারপর উত্তরটি Debian নয়, একটি ভার্সন স্ট্রিং হিসেবে লিখে রাখুন। Pi-hole-এর পূর্বশর্ত পৃষ্ঠা সমর্থিত অপারেটিং সিস্টেম আর আগে থেকে তৈরি FTL আর্কিটেকচারকে দুটি আলাদা শর্ত হিসেবে তালিকাভুক্ত করে, সমর্থন সীমিত রাখে সেই রিলিজগুলোতে যা ডিস্ট্রিবিউশন নিজেই এখনও রক্ষণাবেক্ষণ করে, এবং সতর্ক করে যে বৈচিত্র্য বা অস্বাভাবিক কনফিগারেশন সমর্থিত তালিকার ভেতরেও ব্যর্থ হতে পারে। এই ভাষা গুরুত্বপূর্ণ: একটি সমর্থিত পরিবার তার প্রতিটি সদস্যকে ঢেকে রাখে না।

আপনার Pi-তে এখনও বুট হওয়া একটি পুরোনো ইমেজ সমর্থনের প্রমাণ নয়। বোর্ড ঠিক আছে, প্যাকেজ সূচি বাসি, আর অমিলটা পরে প্রকাশ পায়, যখন ইনস্টলার এমন একটি নির্ভরতা টেনে আনে যা রিলিজ আর মেটাতে পারে না।

VPN দিকে অংশ বেশি, প্রতিটির নিজস্ব জানালা: টানেল ডিমন, তার কনফিগারেশন লেখা ইনস্টল সহায়ক, প্রোভাইডারের ক্লায়েন্ট অ্যাপ আর ডিস্ট্রিবিউশনের ইন্টিগ্রেশন প্যাকেজ—এই চারটি আলাদা প্রকল্প। যে ইনস্টলার আপনার ডিস্ট্রিবিউশন চিনে আর যে ইনস্টলার এমন সেবা বানায় যা রিলিজ চালু রাখতে পারে—দুটি আলাদা দাবি। ডিমনের নিজের প্ল্যাটফর্ম তালিকা দেখুন, তারপর দেখুন আপনি যে সহায়ক চালাতে চান তাতে ওই রিলিজ প্রকাশের পর হাত পড়েছে কি না। যেখানে কোনো প্রকল্প নির্দিষ্ট একটি রিলিজ পর্যন্তই সমর্থনের কথা বলে, পরেরটি আপনার নিজে বুট না করা পর্যন্ত অপরীক্ষিত ধরুন।

বাইনারি লক্ষ্যকে আপনার ব্যবহারকারী-স্পেসের সঙ্গে মিলান

আর্কিটেকচার হলো চুপচাপ ব্যর্থতা। 32-বিট ব্যবহারকারী-ভূমির সঙ্গে 64-বিট কার্নেল কয়েকটি বোর্ডে সত্যিকারের সমর্থিত সমন্বয়, আর এটি 32-বিট FTL বাইনারি অনায়াসে চালায়, ঠিক যতক্ষণ না আপনি শুধু 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 পুল দেয় তার বাইরে একটি স্থির ঠিকানা দিন, আর টানেলকে আলাদা সাবনেটে রাখুন: Pi-এর জন্য 192.168.50.10 আর টানেলের জন্য 10.42.0.0/24 একটি চালু বিভাজন, আর সংখ্যাগুলো নিজেরাই খেয়ালখুশি, যতক্ষণ সেগুলো আপনার রাউটার ইতিমধ্যে যা দেয় তার সঙ্গে সংঘর্ষ না করে। তারপর লিখে রাখুন কোন কম্পোনেন্ট 53 পোর্টে উত্তর দেয়, কোনটি DHCP বিলি করে যদি আপনি সেটি ব্যবহার করেন, আর টানেল ওঠা অবস্থায় কোনটির কাছে ডিফল্ট রুট আছে। হেডলেস ইমেজে শেষ কাজটি NetworkManager বা systemd-networkd-এর, আর প্রোভাইডার ক্লায়েন্ট ইনস্টল করা যা রিভলভার কনফিগারেশনও পুনর্লিখন করে — এভাবেই মানুষ জীবন্ত টানেল আর মৃত DNS নিয়ে বসে থাকে।

বাক্স ভাগ করা ঠিক। ভূমিকা ভাগ করা ঠিক নয়। Pi-hole 53 পোর্টের একমাত্র শ্রোতা হতে চায়, আর VPN ডিমন চায় নিজের DNS সেটিং ক্লায়েন্টদের কাছে ঠেলে দিতে, তাই দুইয়ের মধ্যে ক্লায়েন্টরা কার উপর ভরসা করবে তা বেছে নিন আর অন্যটিকে পথ থেকে সরে থাকতে কনফিগার করুন।

যেখানে পারেন প্রশাসনের পথ টানেলের বাইরে রাখুন। রিভলভার আর টানেল একসঙ্গে ব্যর্থ হলে আপনি তখনও LAN ঠিকানায় SSH পৌঁছাতে চাইবেন, আর তার মানে হলো ব্যবস্থাপনা সেবাটি কোনোটির উপরই নির্ভর করবে না।

পরের আপগ্রেডটিকে বেছে নেওয়ার অংশ করুন

যে রিলিজ আপনি আপগ্রেড করতে পারেন না, সেটি এমন সমর্থন-সীমা যা আপনি ইতিমধ্যেই মেনে নিয়েছেন। যন্ত্রটি আপনার পরিবারের DNS বহনের আগে একটি অতিরিক্ত কার্ডে আপগ্রেডের প্রক্রিয়া পরীক্ষা করুন, আর প্যাকেজ আপগ্রেডই যথেষ্ট ধরে নেওয়ার বদলে শাখা বদল সম্পর্কে প্রকল্পগুলো কী বলে তা পড়ুন।

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

ধরে রাখা প্যাকেজই সাধারণত কারণ হয় যে আপগ্রেড সফল দেখায় অথচ কিছুই বদলায় না। হোল্ডগুলো ইচ্ছাকৃতভাবে একটা একটা করে সরান, আর খেয়াল করুন কোন সেবার পিন দরকার ছিল।

লাফ দেওয়ার আগে Pi-hole কনফিগারেশন, স্থির লিজ আর যেকোনো টানেল প্রোফাইল রপ্তানি করুন, এবং নতুন ইমেজে সেগুলো ফিরিয়ে আনতে পারবেন কি না নিশ্চিত করুন। লাফ দেওয়ার পর সাধারণ ক্লায়েন্ট DNS, টানেলের পেছনের ব্যক্তিগত সম্পদ, পুনঃসংযোগ, আর গেটওয়ের যেকোনো ফরওয়ার্ডিং নিয়ম পরীক্ষা করুন। যে বাক্স বুট হয় আর ping-এর উত্তর দেয়, সে প্রায় কিছুই পাস করেনি।

যখন কোনো একক রিলিজ দুই সেবার সঙ্গে মেলে না

কখনও ওভারল্যাপটা খালি: VPN সহায়কটি আপনি ইনস্টল করতে পারেন এমন Pi-hole প্যাকেজের চেয়ে নতুন রিলিজে গেছে, নাকি বোর্ডের ভেন্ডর ইমেজ দুটিরই পেছনে পড়ে আছে। সেক্ষেত্রে ইনস্টলারকে খুশি করতে রিলিজ মেটাডেটা সম্পাদনার বদলে ভূমিকাগুলো আলাদা করুন। দুটি ছোট ডিভাইস, বা একটি ডিভাইস আর দ্বিতীয় সেবার জন্য একটি কনটেইনার, এমন যন্ত্রের চেয়ে কম খরচে পড়ে যার সমর্থনের গল্প একটি মিথ্যার উপর দাঁড়িয়ে।

ভার্সন জাল করা একমাত্র শর্টকাট যা সোজা প্রত্যাখ্যান করা উচিত। প্যাকেজ ম্যানেজার রিলিজ ফাইল যা বলে তা বিশ্বাস করে, তাই জাল শনাক্তকারী আপনাকে এমন ইনস্টল দেয় যা ঠিক করতে দুটি প্রকল্পের কোনোটিই সাহায্য করবে না।

যদি দুটি চলতি রিলিজ সবকিছু মেটায়, যে রিলিজের আপগ্রেড নোট অনুমান ছাড়াই অনুসরণ করতে পারেন সেটি বেছে নিন, আর খোঁজা বন্ধ করুন। তারপর ভার্সন, আর্কিটেকচার, সেবার মালিক আর পুনরুদ্ধারের ধাপ এক জায়গায় লিখে রাখুন, কারণ SD কার্ডে পরের যে হাত পড়বে তার চারটিই লাগবে।