AWS Client VPN: লগইন সফল, কিন্তু সাবনেটে পৌঁছানো যাচ্ছে না

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

লগইন সফল হয়েছে; নিয়মটি মেলেনি

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

শুরু করুন নিশ্চিত করে যে endpoint-এ এমন একটি অনুমোদন নিয়ম আছে যার গন্তব্যে ব্যর্থ ঠিকানাটি আছে। মিলে যাওয়া নিয়ম না থাকলে সংযোগটি ঠিকঠাক আচরণ করছে; নীতি অনুপস্থিত।

গ্রুপের মান আসলে কোথা থেকে আসে

Active Directory-তে access-group ফিল্ডে গ্রুপের প্রদর্শন নাম নয়, গ্রুপের SID থাকে। SAML ফেডারেশনে থাকে সেই গ্রুপ আইডি বা নাম যা কনফিগার করা SAML গ্রুপ অ্যাট্রিবিউট সত্যিই বহন করে। মানটি assertion বা ডিরেক্টরি লুকআপ থেকে কপি করুন, উইকি পেজ থেকে নয়।

IAM গ্রুপ ভিন্ন একটি নিয়ন্ত্রণ সমতল। Client VPN endpoint পরিচালনার অনুমতি একটি IAM গ্রুপকে ব্যবহারকারীর VPN গ্রুপ বানায় না, আর access-group ফিল্ডে IAM গ্রুপের নাম পেস্ট করলে তা AD SID বা SAML অ্যাট্রিবিউট মানে রূপান্তরিত হয় না।

অন্য ডিরেক্টরিতে একই রকম নামের গ্রুপ কিছুই প্রমাণ করে না। endpoint-এর প্রমাণীকরণ পদ্ধতি এবং সেই একই সিস্টেমে ব্যবহারকারীর সদস্যপদ বা assertion যাচাই করুন।

সবচেয়ে দীর্ঘ প্রিফিক্স জেতে, 0.0.0.0/0 সহ

সবচেয়ে দীর্ঘ প্রিফিক্স মিলের ভিত্তিতে অনুমোদন মূল্যায়ন হয়, এবং সব-গন্তব্য নিয়মটি প্রথমে নয়, শেষে মূল্যায়ন হয়। Engineering-এর জন্য 10.46.0.0/16 নিয়ম এবং সবার জন্য 0.0.0.0/0 নিয়ম যোগ করুন; Engineering-এর বাইরের ব্যবহারকারী তবুও বিস্তৃত নিয়ম দিয়ে 10.46.20.10-এ পৌঁছাতে পারবেন না।

এখানেই একটি সমাধান ভুল হতে পারে। সংকীর্ণ নিয়মটি মুছে দিলে ব্যবহারকারীর অ্যাক্সেস ফিরে আসে এবং বিস্তৃত নিয়মের আওতাভুক্ত প্রতিটি পরিচয়কেও সেই সাবনেট দেওয়া হয়। কিছু মুছার আগে গ্রুপ-থেকে-নেটওয়ার্ক ম্যাট্রিক্স তৈরি করুন এবং কোন গ্রুপ কোন রেঞ্জে পৌঁছানোর কথা তা লিখে রাখুন। এই নিয়মগুলো কেবল অনুমতি দেয়; বিস্তৃত অনুমতি থেকে ব্যতিক্রম কাটার জন্য কোনো deny এন্ট্রি নেই।

পরিবর্তন ঠিকভাবে বিচার করতে নতুন সংযোগও দরকার। নিয়ম সম্পাদনার পর ক্লায়েন্ট আবার সংযুক্ত করুন, তারপর আবার পরীক্ষা করুন।

অনুমোদনকে ডেটা পথ থেকে আলাদা করুন

মিলে যাওয়া নিয়ম কোনো রুট নয়. endpoint-এর একটি সংযুক্ত সাবনেট এবং গন্তব্যের জন্য রুট টেবিল এন্ট্রি দরকার, আর লক্ষ্য রিসোর্সের সিকিউরিটি গ্রুপকে ট্রাফিক গ্রহণ করতে হবে। ফেরত ট্রাফিক ও DNS-ও কাজ করতে হবে।

এমন একজন ব্যবহারকারী পরীক্ষা করুন যার সফল হওয়া উচিত এবং এমন একজন যার বাদ থাকা উচিত। দুজনেই লগইন করতে পারেন, কিন্তু কেবল একজনই সাবনেটে পৌঁছান, আর সেই পার্থক্যই আপনার কাঙ্ক্ষিত প্রমাণ।

যদি IP ঠিকানা কাজ করে কিন্তু হোস্টনেম না করে, অনুমোদনে হাত দেওয়ার আগে resolver দেখুন। কোনো রুট ঠিকানাটি কভার না করলে সংযুক্তি বা রুট টেবিল ঠিক করুন। প্যাকেট এসে পৌঁছালে সার্ভিস তা প্রত্যাখ্যান করলে পরবর্তী গন্তব্য সেই সার্ভিসের নীতি। সব ব্যবহারকারীর জন্য অনুমোদন ম্যাট্রিক্স প্রশস্ত করলে কোন স্তরটি সত্যিই ভাঙা ছিল তা ঢাকা পড়ে যায়।

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