Raspberry Pi-তে অফিসের VPN: প্রথমে এই প্রশ্নগুলো করুন
একটি পোর্টাল URL আর Linux শব্দটি কোনো ক্লায়েন্ট চুক্তি নয়। কিছু ইনস্টল করার আগে প্রোটোকল, আর্কিটেকচার, প্রমাণীকরণ ও নীতির উত্তর নিন।
নিয়োগকর্তার চারটি উত্তর ঠিক করে দেয় একটি Pi অফিসের VPN-এ যোগ দিতে পারবে কি না: এটি কোন গেটওয়ে প্রোটোকল বলে, কোন অপারেটিং সিস্টেম ও আর্কিটেকচার সমর্থন করে, প্রমাণীকরণ কীভাবে হতে হবে, এবং অফিসিয়াল ক্লায়েন্ট ছাড়া অন্য ক্লায়েন্ট অনুমোদিত কি না। একটি পোর্টাল URL আর Linux শব্দটি এর কোনোটিই নিষ্পত্তি করে না। কিছু ডাউনলোড করার আগে জিজ্ঞাসা করুন, কারণ উত্তরগুলো বদলে দেয় আপনি কোন প্যাকেজ ইনস্টল করবেন এবং হেডলেস সেটআপ আদৌ কার্যকর কি না।
চারটি উত্তর লিখে রাখুন। বাকি অংশটি হলো প্রতিটি উত্তর কী বদলায়।
গেটওয়ে প্রোটোকলই ক্লায়েন্ট নির্ধারণ করে
গেটওয়ে এক বা একাধিক প্রোটোকল বলে, আর ক্লায়েন্টকে অবশ্যই সেই প্রোটোকলটি বাস্তবায়ন করতে হবে যা আপনার প্রতিষ্ঠান সত্যিই চালায়। OpenConnect একটি স্বাধীন বাস্তবায়ন যা Cisco AnyConnect সামঞ্জস্য দিয়ে শুরু হয়েছিল এবং এখন আরও কয়েকটি এন্টারপ্রাইজ গেটওয়ে কভার করে; এটি ভেন্ডরের ব্র্যান্ডেড ক্লায়েন্ট নয়, এবং প্রোটোকল সামঞ্জস্য প্রতিটি গেটওয়ে বৈশিষ্ট্য, পোস্টচার যাচাই বা ডিভাইস নীতির সমর্থন নিশ্চিত করে না। পোর্টালের URL থেকে অনুমান না করে নেটওয়ার্ক দলের সাথে প্রোটোকল নিশ্চিত করুন। তারপর নিশ্চিত করুন যে নিয়োগকর্তা এই স্থাপনার জন্য এই ক্লায়েন্ট গ্রহণ করেন।
সামঞ্জস্যের প্রমাণ আসতে হবে নিয়োগকর্তার নথি থেকে বা যে সহকর্মী একই মডেলে এটি করেছেন তার কাছ থেকে, রিপোজিটরিতে একটি প্যাকেজ থাকা থেকে নয়।
আর্কিটেকচার কোনো খুঁটিনাটি নয়
Pi-এর OS সংস্করণ ও ইউজার-স্পেস আর্কিটেকচার, আপনি যে ক্লায়েন্ট সংস্করণ ব্যবহার করতে চান এবং সেই প্যাকেজ কোথা থেকে আসে তা লিখে রাখুন। ফাইলের নাম বদলে যাওয়ায় একটি x86 ইনস্টলার অন্য আর্কিটেকচারের জন্য উপযুক্ত হয়ে যায় না, আর যে ভেন্ডর ক্লায়েন্ট কেবল x86 বিল্ড দেয় তা Pi-তে আদৌ চলতে পারে না। এই একটি তথ্যই প্রমাণীকরণ নিয়ে আলোচনার আগেই পুরো প্রশ্নটির নিষ্পত্তি করতে পারে। ফোরামের থ্রেড থেকে এলোমেলো বাইনারি ইনস্টল না করে প্যাকেজের উৎসের রক্ষণাবেক্ষণ দেখুন।
64-বিট কার্নেলে 64-বিট ইউজার স্পেস হলো সহজ কেস; 64-বিট বোর্ডে 32-বিট ইউজার স্পেস হলো যেখানে মানুষ ভুল প্যাকেজ ইনস্টল করে। dpkg --print-architecture এবং uname -m এক লাইনে দুই অংশেরই উত্তর দেয়।
প্রমাণীকরণই কর্মপ্রবাহ নির্ধারণ করে
পাসওয়ার্ড, MFA এবং ব্রাউজার-মধ্যস্থ সাইন-ইন প্রত্যেকটি নিজস্ব কর্মপ্রবাহ চাপিয়ে দেয়। হার্ডওয়্যার টোকেনে রাখা একটি সার্টিফিকেটের জন্য এমন ড্রাইভার লাগতে পারে যা Pi-তে নেই, আবার SSO প্রবাহ এমন একটি ব্রাউজার উইন্ডো খুলতে পারে যা হেডলেস সেশন দেখাতে পারে না। কিছু গেটওয়ে ঠিক এই ক্ষেত্রেই ডিভাইস-কোড বা হাতে-কপি পথ দেয়, আর কিছু দেয় না। প্রতিষ্ঠান হেডলেস Linux হোস্টের জন্য কোন পদ্ধতি সমর্থন করে জিজ্ঞাসা করুন, তারপর তার ওপর নির্ভর করার আগে সেটি পরীক্ষা করুন।
ফ্রন্টএন্ড ইন্টিগ্রেশন প্রমাণীকরণ থেকে আলাদা একটি সিদ্ধান্ত। একটি NetworkManager প্লাগইন সংযোগ ব্যবস্থা করতে ও তার গোপনীয়তা সংরক্ষণ করতে পারে, কিন্তু অসমর্থিত প্রমাণীকরণ পদ্ধতিকে সামঞ্জস্যপূর্ণ করতে পারে না। এই দুটি প্রশ্ন আলাদা রাখুন।
নিয়োগকর্তার সীমা অক্ষুণ্ন রাখুন
প্রতিষ্ঠান যদি তার অফিসিয়াল ক্লায়েন্ট, ম্যানেজড ডিভাইস বা সমর্থিত ডিস্ট্রিবিউশন দাবি করে, তবে সেই দাবি মানুন বা অনুমোদিত বিকল্প চান। সার্টিফিকেট যাচাই বন্ধ করা, পোস্টচার ফলাফল নকল করা বা অন্য ক্লায়েন্টকে গৃহীত দেখাতে এন্ডপয়েন্ট নিয়ন্ত্রণ বন্ধ করা সামঞ্জস্যের সমস্যাকে নীতি লঙ্ঘনে পরিণত করে। পাসওয়ার্ড, সেশন কুকি ও প্রাইভেট কী শেল ইতিহাস ও চ্যাট ট্রান্সক্রিপ্টের বাইরে রাখুন। কাজ করা চ্যালেঞ্জ-রেসপন্স সেশন উপাদান প্রকাশের অনুমতি নয়।
অনুমোদিত নথিভুক্তির পরে Pi থেকেই প্রাইভেট DNS, নির্দিষ্ট রিসোর্স, প্রত্যাখ্যাত একটি রিসোর্স এবং পুনঃসংযোগ যাচাই করুন। লগইন করা একটি টানেল তবুও ভুল রুট করতে পারে বা অনুমোদনের অভাবে থাকতে পারে।
ফলাফল হলো নামযুক্ত মালিকসহ একটি সমর্থনযোগ্য চুক্তি: কোন ক্লায়েন্ট, কোন সংস্করণ, কোন নথিভুক্তির পথ। ভেন্ডরের কাছাকাছি ক্লায়েন্ট ইনস্টল করে বাকি দাবিগুলো ঐচ্ছিক হয়ে যাবে আশা করার চেয়ে এটি ভালো।