Pi VPN সার্ভার: রেসিপি নয়, ফোনের অ্যাপ থেকে শুরু করুন

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

যে ক্রমটি পুনর্নির্মাণ বাঁচায়

Pi-তে কিছু ইনস্টল করার আগে ফোনের অপারেটিং সিস্টেম ও সঠিক VPN অ্যাপটি লিখে ফেলুন। এই জোড়াটিই ঠিক করে কোন প্রোটোকল আদৌ সম্ভব। প্রোফাইলে পরিচিত কোনো ফিল্ড থাকলেই একটি ক্লায়েন্ট অ্যাপ ভিন্ন ক্লায়েন্ট হয়ে যায় না।

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

অ্যাপ ঠিক হয়ে গেলে সার্ভারের পছন্দ সংকুচিত হয় এবং বাকি নির্মাণের একটি লক্ষ্য থাকে।

ফোনের অ্যাপটি আসলে কী বাস্তবায়ন করে

প্রকাশিত ক্লায়েন্ট তালিকা একটি অ্যাপ্লিকেশন বর্ণনা করে, কোনো সেবা নয়। Android-এর জন্য OpenVPN Connect অ্যাপ একটি OpenVPN সার্ভার প্রত্যাশা করে; এটি সার্ভারের দিকটি সরবরাহ করে না। প্রোফাইল একই রকম দেখালে এটিও IPsec বা L2TP ক্লায়েন্ট হয়ে যায় না।

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

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

চার অংশের চুক্তি

চারটি বিষয় লিখে একসঙ্গে রাখুন: ফোনের অপারেটিং সিস্টেম ও অ্যাপ সংস্করণ, Pi-তে সার্ভার বাস্তবায়ন, প্রমাণীকরণ ও বিশ্বাস নীতি এবং বাহ্যিক এন্ডপয়েন্ট। চারটির প্রত্যেকটিই বাকি তিনটিকে অকার্যকর করতে পারে।

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

শংসাপত্রের আলাদা দায়িত্ব আছে

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

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

হাতে প্রোফাইল জোড়া দেওয়ার বদলে সেবার সমর্থিত রপ্তানি ও আমদানি প্রবাহ ব্যবহার করুন। হাতে তৈরি প্রোফাইলে সাধারণত শুধু ডেস্কটপের জন্য নির্দেশনা থাকে যা মোবাইল অ্যাপ উপেক্ষা বা প্রত্যাখ্যান করে।

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

পৌঁছানো একটি আলাদা চুক্তি

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

তারপর ঠিক করুন সংযুক্ত হওয়ার পর ক্লায়েন্ট কী পৌঁছাতে পারবে: প্রাইভেট প্রিফিক্স নাকি পূর্ণ ইন্টারনেট প্রস্থান, সেগুলোর ফরওয়ার্ডিং ও উত্তর পথ, DNS আচরণ, আর IPv6 পরিসরে আছে কি না। সফল লগইন এগুলোর কোনোটিই প্রমাণ করে না।

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