vpn.persistent চেষ্টা চালিয়ে যায়, কিন্তু আপনাকে সংযুক্ত রাখে না

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

সেটিংটি আসলে কী প্রতিশ্রুতি দেয়

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

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

প্রপার্টিটিকে একটি প্রচেষ্টা হিসেবে দেখা পরীক্ষার জন্যও সঠিক প্রত্যাশা তৈরি করে। আপনি যাচাই করছেন না ফ্ল্যাগ সেট আছে কি না; আপনি যাচাই করছেন লিঙ্ক পড়ে যাওয়ার সময় কিছু ঘটেছে কি না। এগুলো ভিন্ন পরীক্ষা, এবং তার মধ্যে কেবল একটি একটি দুপুরের সময়ের যোগ্য।

চারটি প্রশ্ন যা একটিতে মিলিয়ে দেওয়া হয়

অ্যাক্টিভেশন জিজ্ঞেস করে প্রথমেই VPN-কে কী উঠিয়ে আনে। একটি NetworkManager প্রোফাইল একটি বেস সংযোগের সাথে যুক্ত হতে পারে, আলাদাভাবে পরিচালিত OpenVPN পরিষেবার নিজস্ব স্টার্টআপ থাকে, এবং সেই ব্যবস্থায় তৃতীয় একটি লঞ্চার যোগ করলে আপনি দুজন মালিক পান যাদের কে দায়িত্বে তা নিয়ে ভিন্ন ধারণা। আরেকটি ট্রিগার যোগ করার আগে কোন উপাদান স্টার্টআপের মালিক তা ঠিক করুন।

পুনরুদ্ধার জিজ্ঞেস করে লিঙ্ক পরিবর্তিত বা অদৃশ্য হলে কী হয়, আর এটাই সেই সংকীর্ণ প্রশ্ন যা vpn.persistent সম্বোধন করে। সজীবতা জিজ্ঞেস করে ক্লায়েন্ট বুঝতে পারে কি না যে প্রান্তটি উত্তর দেওয়া বন্ধ করেছে, এবং OpenVPN-এর keepalive বা পুনরায় চালু করার আচরণ তার উত্তর দেয়; দুটি প্রক্রিয়াকে প্রায়ই একই শব্দে বর্ণনা করা হয় এবং ভিন্ন জায়গায় বাস্তবায়িত হয়। সেগুলো আলাদাভাবে, ভিন্ন সরঞ্জাম দিয়ে পরীক্ষা করুন, নইলে একটির আচরণ অন্যটির উপর আরোপ করবেন।

অভিপ্রায় জিজ্ঞেস করে পুনঃসংযোগ আদৌ চাওয়া হচ্ছে কি না, এবং এটাই সেই প্রশ্ন যার উত্তর স্ট্যাটাস পোলিং দিতে পারে না। ইচ্ছাকৃত বন্ধ এবং বিভ্রাট একই নিষ্ক্রিয় অবস্থা তৈরি করে, তাই অনুপস্থিতিতে পুনঃসংযোগ করা যে কোনো কিছু মানবিক সিদ্ধান্ত নিয়ে অনুমান করছে। অনুমান ঠিক ততক্ষণ ভালো যতক্ষণ তা কাউকে অগ্রাহ্য না করে।

একটি চেকলিস্ট যা সেগুলোকে আলাদা রাখে

কনফিগারেশন পড়ে তা নিয়ে যুক্তি করার বদলে ঘটনাগুলো ক্রমানুসারে চালান, এবং প্রতিটি কী দেখায় তা টাইমস্ট্যাম্পসহ লিখে রাখুন।

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

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

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

প্রমাণীকরণ পুনরুদ্ধারের অংশ

পুনঃসংযোগ নিছক নেটওয়ার্কিং কাজ নয়। অনুমোদিত প্রবাহের যদি নতুন চ্যালেঞ্জ, এককালীন কোড, বা এমন একটি গোপন তথ্য দরকার হয় যা অ্যাক্টিভেশন প্রসঙ্গ পৌঁছাতে পারে না, কোনো স্থায়িত্ব সেটিং তা শূন্য থেকে তৈরি করতে পারে না।

এটি একটি পরিচিত ধাঁচ ব্যাখ্যা করে: সংযোগ একটি আনলক করা কী-রিংযুক্ত মেশিনে পুনরুদ্ধার হয় এবং পুনরায় চালু করার পর একই মেশিনে ব্যর্থ হয়। নেটওয়ার্কিং স্তর ঠিক যা চাওয়া হয়েছিল তা করেছে এবং শংসাপত্র স্তরের দেওয়ার মতো কিছু ছিল না।

পুনরায় চেষ্টার ব্যবধান কমানোর বদলে শংসাপত্র কর্মপ্রবাহ ঠিক করুন। এমন প্রম্পটের বিরুদ্ধে দ্রুততর পুনরায় চেষ্টা যা কেউ উত্তর দিতে পারে না, লগে শব্দ এবং কিছু চেষ্টা হচ্ছে এমন একটি মিথ্যা ধারণা তৈরি করে।

স্থায়িত্ব কোনো kill switch নয়

প্রপার্টিটি VPN সম্পর্ক ধরে রাখতে বা পুনরুদ্ধার করতে চায়। VPN বন্ধ থাকাকালীন অ্যাপ্লিকেশন কী করতে পারে তা এটি ঠিক করে না, এবং নিজে থেকে কিছুই ব্লক করে না।

যদি প্রয়োজন হয় যে টানেলের বাইরে কোনো ট্র্যাফিক না যায়, তবে সেটি নিজস্ব প্রক্রিয়া, নিজস্ব পরীক্ষা এবং নিজস্ব ব্যর্থতার ধরনসহ একটি আলাদা নীতি। স্থায়িত্ব এটি ঢেকে দেয় ধরে নিলে একটি নিরাপত্তা সিদ্ধান্ত দুর্ঘটনায় পরিণত হয়।

পুনরুদ্ধার নোটে দুই অংশই লিখুন: VPN কী চেষ্টা করেছে, এবং প্রচেষ্টা চলাকালীন কোন অ্যাপ্লিকেশন ট্র্যাফিক অনুমোদিত ছিল।