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

একবার রিবুটে কী থেমে যায়

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

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

রক্ষণাবেক্ষণের মালিকানাও গুনুন। আরেকটি যন্ত্র কনফিগারেশন, মনিটরিং, ব্যাকআপ আর দ্বিতীয় পুনরুদ্ধার পদ্ধতি নিয়ে আসে, আর এসবের কিছুই বিনামূল্যে নয়।

প্রতিটি নিয়ম কোথায় প্রয়োগ হয় তা চিহ্নিত করুন

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

ip route get 10.20.30.40
traceroute -n 10.20.30.40
conntrack -L -p tcp --dport 443

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

থামুন যদি বলতে না পারেন কোন যন্ত্রটি গুরুত্বপূর্ণ নিয়ম প্রয়োগ করে। ওই ফাঁকই হলো অনুসন্ধান, পরে মেটানোর মতো খুঁটিনাটি নয়।

নিয়ন্ত্রণ একটি সীমানা, চ্যাসি নয়

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

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

বিচ্ছেদ যদি প্রবাহ বদলাতে নয়, বরং একটি কমপ্লায়েন্স লাইন মেটাতে থাকে, তবে রেকর্ডে তা বলুন। যে নিয়ন্ত্রণ কেউ ব্যাখ্যা করতে পারে না, চাপে সেটিই প্রথম সরানো হয়।

যেখানে সত্যিই পৌঁছাতে পারেন তা পুনরুদ্ধার করুন

জিজ্ঞাসা করুন কোন পুনরুদ্ধার পথ টিকে থাকে যখন দুই ভূমিকার যেকোনোটি মারা যায়। যখন একটি ভাঙা VPN গেটওয়েতে পৌঁছানোর একমাত্র পথ সেই গেটওয়ের মধ্য দিয়েই যায়, তখন অন্য জায়গার অতিরিক্ত যন্ত্র সেই প্রশাসককে সাহায্য করে না যার এটি ঠিক করতে হয়। আউট-অব-ব্যান্ড পথ, একটি কনসোল আর নথিভুক্ত রোলব্যাক—এই অংশগুলোই নকশাকে পুনরুদ্ধারযোগ্য করে।

systemctl status strongswan
nft list ruleset
ip -brief address

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

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

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