পার্টনারদের একীভূত না করেই পার্টনার VPN অ্যাক্সেস কেন্দ্রীভূত করুন

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

প্রতিটি পার্টনার আগে যে চুক্তিতে সই করেছে সেখান থেকেই শুরু করুন

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

ওই নথিটিই প্রকৃত ফলাফল। একটি পার্টনারের জন্য যদি এটি লিখতে না পারেন, তবে সেই পার্টনার কেন্দ্রীভূত হওয়ার জন্য প্রস্তুত নয়।

শুধু গন্তব্য দিয়ে নয়, প্রসঙ্গ দিয়ে রুট করুন

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

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

যেখানে উত্তর হ্যাঁ, সেখানে রাউটিং প্রসঙ্গই সেই জিনিস যা আপনাকে নথিভুক্ত ও পরীক্ষা করতে হবে, কারণ traceroute-এ এটি অদৃশ্য।

কর্মী কী টাইপ করে আর পার্টনার কী লগ করে তা ঠিক করুন

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

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

পার্টনার থেকে পার্টনারে ট্রানজিট স্পষ্টভাবে অস্বীকার করুন

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

অনুমতিগুলোর পাশে পার্টনারের নথিতেই অস্বীকৃতিটি লিখুন, যাতে অভিপ্রায়টি কর্মী বদলেও টিকে থাকে।

এটি বড় ল্যাপটপ নয়, শেয়ার করা সেবা হিসেবে চালান

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

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

পার্টনার, প্রসঙ্গ, অনুমোদিত রেঞ্জ ও মালিক নিয়ে একটি ছোট টেবিল রাখুন। কোনো ঘটনার সময় সবার আগে এটিই চাওয়া হবে।