এমন একটি VPN নকশা ব্রিফ লিখুন যা কেউ সত্যিই পর্যালোচনা করতে পারে
পর্যালোচনাযোগ্য নকশা প্রবাহ, মালিক ও ব্যর্থতার চুক্তির নাম দেয়। ছয়টি যাচাই একটি অস্পষ্ট প্রশ্নকে এমন প্রশ্নে পরিণত করে যার উত্তর সিদ্ধান্ত দিয়ে দেওয়া যায়।
বেশিরভাগ নকশা পর্যালোচনা প্রথম প্রশ্নেই আটকে যায়, কারণ অনুরোধটি সিদ্ধান্ত নয়, একটি পণ্য বর্ণনা করে। যে ব্রিফ প্রবাহ, মালিক ও ব্যর্থতার আচরণের নাম দেয়, তার উত্তর এক বৈঠকেই দেওয়া যায়। যে ব্রিফ বলে একটি নিরাপদ VPN তৈরি করুন, তার উত্তরই দেওয়া যায় না। কিছু পাঠানোর আগে নিচের ছয়টি যাচাই সম্পন্ন করুন, তাহলে পর্যালোচনা বিতর্কের বদলে তুলনায় পরিণত হয়।
প্রথমত, প্রশ্নটি কি সিদ্ধান্ত নাকি ইচ্ছা
সিদ্ধান্তের বিকল্প থাকে এবং তাদের মধ্যে বাছাই করার একটি পর্যবেক্ষণ থাকে। যদি একটি বাছাই করতে আপনি কী দেখবেন তা বলতে না পারেন, প্রশ্নটি এখনও ইচ্ছা। বিকল্পগুলো আগে লিখুন, তালিকায় দুটি জিনিস থাকলেও। তারপর যে বিনিময় তাদের আলাদা করে তা লিখুন।
ইচ্ছা শ্রোতাকেও লুকিয়ে রাখে। ডিজাইন কে অনুমোদন করবে তা বলুন, কারণ একই ব্রিফ নেটওয়ার্ক মালিক, নিরাপত্তা পর্যালোচক ও অর্থ অনুমোদনকারীর কাছে ভিন্নভাবে পড়া হয়।
উত্তর যদি কেউ না হয় তবে এখানেই থামুন, কারণ মালিকহীন সিদ্ধান্ত যে সবচেয়ে জোরে অভিযোগ করে সে আবার বানাবে। এটি নকশার সমস্যা নয়, শাসনের সমস্যা।
দ্বিতীয়ত, প্রবাহ ও অস্বীকৃতির নাম দিন
যে প্রতিটি প্রবাহ কাজ করতেই হবে তার উৎস, গন্তব্য ও অ্যাপ্লিকেশন তালিকা করুন। তারপর যে প্রবাহগুলো ব্যর্থ হয়েই থাকতে হবে সেগুলো তালিকা করুন, কারণ যে নকশা নিঃশব্দে সেগুলোকে অনুমতি দেয় সে না বলে প্রয়োজনীয়তা বদলে ফেলেছে। ঠিকানা ওভারল্যাপ ও উজানে পৌঁছানোর সক্ষমতা এই তালিকায় বিস্ময় নয়, সীমাবদ্ধতা হিসেবে থাকে।
দিক সম্পর্কে সুনির্দিষ্ট হোন। যে সাইট সদর দপ্তরে সংযোগ শুরু করতে পারে, তার নকশা তার থেকে আলাদা যে সংযোগ গ্রহণ করতে পারে, এবং পার্থক্যটি পরবর্তীতে লেখা প্রতিটি নিয়মে দেখা যায়।
ক্লায়েন্ট ও তাদের ব্যবস্থাপনা অবস্থাও লক্ষ করুন, কারণ এজেন্টসহ ব্যবস্থাপিত ডিভাইস এমন কাজ করতে পারে যা নিজের আনা ল্যাপটপ করতে পারে না।
তালিকাটি পরীক্ষার মতো যথেষ্ট ছোট রাখুন। যে দশটি প্রবাহ যাচাই করতে পারেন তা সেই চল্লিশটির চেয়ে ভালো যা পারেন না।
যাচাই 3: তথ্য ও অনুমান আলাদা করুন
আপনি যাচাই করেছেন এমন প্রতিটি বিবৃতি চিহ্নিত করুন, এবং যেগুলো যাচাই করেননি সেগুলোও চিহ্নিত করুন। পাবলিক ঠিকানা, প্রাপ্য থ্রুপুট ও প্রশাসক প্রবেশাধিকার সেই তিনটি অনুমান যা প্রায়ই উত্তর বদলায়। এর একটি অজানা হলে বলুন, যেদিকেই পরিণত হোক নকশা কীভাবে বদলাবে।
একটি দৃষ্টান্তমূলক নেটওয়ার্ক ঠিক আছে, যতক্ষণ তা চিহ্নিত থাকে। সমস্যা হলো এমন একটি কাল্পনিক শাখা যা নিঃশব্দে দ্বিতীয় আপলিংক বা পাবলিক ঠিকানা ব্লক পায় যা তার কখনও ছিল না।
পর্যালোচনার আগে যে অনুমান যাচাই করতে পারেন তা যাচাই করুন, কারণ একটি মাপা তথ্য আলোচনার একটি সম্পূর্ণ শাখা সরিয়ে দেয়।
ip route get 10.50.0.10
traceroute -n -m 6 10.50.0.10
nc -vz 10.50.0.10 443চতুর্থত, ব্যর্থতার চুক্তি লিখুন
টানেল বন্ধ থাকলে কী হয় তা বলুন, এবং দুটি ভিন্ন প্রতিশ্রুতি সম্পর্কে স্পষ্ট থাকুন। পুনঃসংযোগের পরে নতুন সংযোগ পুনরুদ্ধার করা সহজ প্রতিশ্রুতি। ব্যর্থতা জুড়ে ইতিমধ্যে প্রতিষ্ঠিত সেশন সংরক্ষণ করা অনেক শক্তিশালী দাবি, এবং এটি প্রযুক্তির পছন্দকে সীমাবদ্ধ করে।
তারপর ফলব্যাক ঠিক করুন: ট্রাফিক ব্লক করুন, অন্য অনুমোদিত পথে পাঠান, বা প্রতিটি অ্যাপ্লিকেশনের জন্য আলাদা কিছু করুন। সরাসরি পথে নিঃশব্দ প্রত্যাবর্তন একটি নকশা সিদ্ধান্ত, এমনকি কেউ তা লিখে না রাখলেও।
পুনরুদ্ধারের লক্ষ্য সহজ ভাষায় যোগ করুন, যেমন একটি সাইট কতক্ষণ অবনত অবস্থায় চলতে পারে এবং কে ঘটনাটি ঘোষণা করে।
যাচাই 5 ও 6: সিম বেছে নিন এবং পরিবর্তন নথিবদ্ধ করুন
তর্কের জন্য একটি সিম বেছে নিন, কারণ সবকিছু মিটমাট করতে চাওয়া পর্যালোচনা কিছুই মিটমাট করে না। রাউটিং, অনুমোদন ও এনক্রিপশন তিনটি ভিন্ন সিম, এবং ব্রিফের বলা উচিত প্রশ্নটি কোনটি নিয়ে। RFC 4301 এখানে দরকারি স্মারক, কারণ এটি নীতি সিদ্ধান্ত, সুরক্ষিত ট্রাফিক ও নিরাপত্তা সংযোগকে একটি বস্তু হিসেবে না দেখে আলাদা করে।
তারপর সিদ্ধান্তের পরে কী বদলেছে তা নথিবদ্ধ করুন, সংশোধিত অনুমানসহ। সেই নথিই পরের পর্যালোচনাকে ছোট করে।
git diff --stat design/vpn-brief.md
grep -n 'assumption' design/vpn-brief.md
ip route get 10.50.0.10যে ব্রিফ ছয়টি যাচাই পেরোয় তা উত্তরসহ প্রশ্ন তৈরি করে: নকশা উল্লিখিত প্রবাহ ও ব্যর্থতার চুক্তি পূরণ করে, অথবা একটি নামকৃত সীমাবদ্ধতা তা ঠেকায়। পরে সীমাবদ্ধতা বদলালে নথি দেখায় কোন সিদ্ধান্ত আবার দেখতে হবে আর কোনটি থাকতে পারে। এটাই অনুশীলনটিকে এককালীন বিতর্ক নয়, পুনরায় ব্যবহারযোগ্য করে তোলে।