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

আর্কিটেকচারের প্রশ্নটি আগে আসে, কারণ 64-বিট বোর্ড 32-বিট ইউজার স্পেস চালাতে পারে, আর অ্যাপ্লিকেশন দুটোর একটিই সরবরাহ করে।

দুটি সমর্থন-সীমানা, দুটি ইনস্টলার নয়

আপনি যে অ্যাপ্লিকেশন ব্যবহার করতে চান, তার জন্য প্রদানকারীর বর্তমান ইনস্টলেশন পৃষ্ঠাটি পড়ুন এবং বোর্ডের সঙ্গে মিলিয়ে নিন: ডিস্ট্রিবিউশন রিলিজ, প্যাকেজ আর্কিটেকচার, এবং ডেস্কটপ বা সেশনের যেকোনো শর্ত। Pi 64-বিট পরিচালনা সমর্থন করে—এটি বলে না এখন কোন ইউজার স্পেস ইনস্টল আছে, আর প্যাকেজ ম্যানেজার ঠিক সেই মানটিই যাচাই করে। dpkg --print-architecture এবং uname -m প্রতিটি একটি লাইনে এর উত্তর দেয়। রিলিজ বা আর্কিটেকচার নথিভুক্ত সেটের বাইরে হলে, সেখানে অ্যাপ্লিকেশনটি সমর্থিত নয়, এমনকি ইনস্টল হলেও।

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

অ্যাপ যা দেয়, প্রোফাইল যা দেয় না

অফিসিয়াল অ্যাপ্লিকেশন শুধু সংযোগ নয়: এটি সাধারণত প্রদানকারীর কিল সুইচ, DNS পরিচালনা ও ফিচার টগল বহন করে, এবং প্রদানকারী এই আচরণগুলো একটি সেট হিসেবে সমর্থন করে। স্ট্যান্ডার্ড ক্লায়েন্টকে দেওয়া হাতে তৈরি প্রোফাইল এর কিছুই উত্তরাধিকারে পায় না। হাতে পরিচালিত ক্লায়েন্ট সংযোগের জীবনচক্র ও স্থানীয় ব্যর্থতা-নীতি নিজের হাতে রাখে, যা আপনি নিজে কনফিগার করলে ঠিকঠাক, আর সেগুলো সঙ্গে এসেছে ধরে নিলে বিস্ময়কর। দুটি বিকল্পই একই সার্ভারে পৌঁছায়; শুধু একটিতেই পারিপার্শ্বিক যুক্তি থাকে।

কোনো ফিচার গুরুত্বপূর্ণ হলে, যেমন টানেলের বাইরে ট্রাফিক আটকানো, তা প্রদানকারীর অ্যাপ্লিকেশনে নয়, আপনার কনফিগারেশনেই থাকতে হবে।

হাতে WireGuard: যে ধাপগুলো গুরুত্বপূর্ণ

প্রদানকারী স্ট্যান্ডার্ড-সামঞ্জস্যপূর্ণ ক্লায়েন্টের জন্য WireGuard কনফিগারেশন তৈরি করার কথা নথিভুক্ত করে এবং হাতে করা সেটআপের জন্য সেই পথের সুপারিশ করে, পুরনো ডিভাইসের জন্য OpenVPN রেখে দেয়। অ্যাকাউন্ট ড্যাশবোর্ডে প্রোফাইল তৈরি করুন, তা Pi-তে আনুন, এবং এমন জায়গায় রাখুন যেখান থেকে কেবল মালিকই পড়তে পারেন। ফাইলটি কখনো সাপোর্ট থ্রেডে পেস্ট করবেন না, কারণ বন্ধুত্বপূর্ণ ফাইলনাম ভেতরের প্রাইভেট কী-কে প্রকাশযোগ্য করে না। তারপর অন্য কিছু যুক্ত করার আগে একটি অনুরোধ দিয়ে টানেল পরীক্ষা করুন।

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

Pi-টি গেটওয়েও কি না, তা ঠিক করুন

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

তারপর জীবনচক্রটি মেনে নিন: Pi থেকে নতুন অনুরোধ, নির্ধারিত রিজলভার দিয়ে নাম-রেজলিউশন, এবং আপনি যে বুট বা পুনঃসংযোগ আচরণের পরিকল্পনা করেছেন। অ্যাপ বা প্রোফাইল এগুলো দেয় ধরে না নিয়ে প্রতিটি যাচাই করুন।

যে মিথটি বাদ দেওয়া উচিত তা হলো, লিনাক্স ইনস্টলার ও WireGuard ফাইল একই সিদ্ধান্তের প্রতিনিধিত্ব করে। এরা ভিন্ন মালিকাধীন দুই পরিচালনা মডেল।

সম্পর্কিত নিবন্ধ