হাফ-ম্যানেজড VPN: লেবেলটি বলে না কে নজরদারিতে থাকে

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

যে সংযোগটি বিচ্ছিন্ন হয়েছে সেখান থেকেই শুরু করুন

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

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

সেটিংসের আগে দুটি এন্ডপয়েন্ট ঠিক করুন

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

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

শেয়ার করা বস্তুর মালিক ঠিক একজন

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

ধ্রুপদী ব্যর্থতা হলো একই সপ্তাহে এক পক্ষে সিলেক্টর পরিবর্তন আর অন্য পক্ষে NAT পরিবর্তন। কোনো ইঞ্জিনিয়ারই ভুল করেননি, তবুও টানেলটি অ্যাপ্লিকেশন বহন করা বন্ধ করে দিয়েছে।

প্রথম রিপোর্ট কে নেয়

আগেই ঠিক করুন প্রথমে কাকে ডাকা হবে, কোন পক্ষ কী পড়ার অনুমতি পাবে, এবং কোন মুহূর্তে কেসটি হাত বদলাবে। এন্ডপয়েন্ট, চেষ্টার সময় এবং অনুমোদিত প্রবাহ দিন, যাতে উভয় পক্ষ একই ঘটনা মিলিয়ে দেখতে পারে।

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

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

লেবেল যা কখনোই বলে না

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

পরিধিতে স্বাভাবিক অপারেটর এবং প্রতিটি নির্ভরতার জন্য এস্কেলেশন পথের নাম থাকা উচিত। কোটেশন সেবাটিকে যা-ই বলুক, বাস্তবে এর অর্থ ওই তালিকাই।