কোন ক্লায়েন্ট AWS Client VPN SAML লগইন সম্পূর্ণ করতে পারে
AWS ক্লায়েন্টসহ Linux ডেস্কটপ SAML ব্রাউজার হ্যান্ড-অফ সম্পূর্ণ করতে পারে; সাধারণ Android OpenVPN আমদানি পারে না। তিনটি শর্ত আপনার ক্ষেত্র নির্ধারণ করে।
দুইজন মানুষ AWS Client VPN এবং SAML নিয়ে একই প্রশ্ন করেন, আর পান পরস্পরবিরোধী উত্তর। একজন প্রতি সকালে Ubuntu ল্যাপটপ থেকে সাইন ইন করেন; অন্যজনের আছে একটি ফোন, একটি ডাউনলোড করা প্রোফাইল, এবং একটি ক্লায়েন্ট যা তার একটি লাইন প্রত্যাখ্যান করে। পার্থক্যটি ভাগ্য নয়, লুকানো কোনো ড্যাশবোর্ড সুইচও নয়। বিষয়টি তিনটি শর্তে গিয়ে ঠেকে: প্ল্যাটফর্মটি কি AWS তার নিজস্ব ক্লায়েন্টের জন্য সমর্থন করে এমন একটি, আপনার হাতের টুলটি ফেডারেটেড ব্রাউজার বিনিময় চালাতে পারে কি না, এবং এন্ডপয়েন্টটি আদৌ SAML-এর জন্য কনফিগার করা কি না। তিনটির যেকোনো একটি বাদ পড়লে সাইন ইন ভিন্ন এক জায়গায় আটকে যায়।
তিনটি শর্ত ঠিক করে লগইন শেষ হতে পারবে কি না
প্ল্যাটফর্ম প্রথমে। AWS Windows, macOS এবং AMD64-এ Ubuntu-র জন্য নিজস্ব Client VPN ক্লায়েন্ট দেয়, আর 2026 সালের অক্টোবরের শেষ নাগাদ Linux প্রয়োজনীয়তার পাতায় Ubuntu 22.04, 24.04 এবং 26.04 নাম থাকে। পুনঃপ্যাকেজ করা বিল্ড, রূপান্তরিত প্যাকেজ বা ভিন্ন ডিস্ট্রিবিউশন চলতে পারে, কিন্তু এটি সমর্থিত প্ল্যাটফর্ম নয়, আর এটি ভাঙলে সাপোর্ট লাইন আপনি-ই।
ক্লায়েন্ট দ্বিতীয়ে। ফেডারেটেড সাইন ইন এমন কোনো প্রোফাইল অপশন নয় যা প্রতিটি OpenVPN-সামঞ্জস্যপূর্ণ অ্যাপ পার্স করে। প্রদত্ত ক্লায়েন্ট আপনার পরিচয় প্রদানকারীকে ব্রাউজারে খোলে, স্বাক্ষরিত প্রমাণীকরণ প্রতিক্রিয়া গ্রহণ করে, এবং সেই প্রতিক্রিয়া এন্ডপয়েন্টে জমা দেয়। যে অ্যাপ শুধু প্রোফাইল পড়ে আর টানেল তোলে, সে এই ধাপটি সম্পাদন করে না, তার সংযোগ লগ যতই পরিষ্কার দেখাক।
এন্ডপয়েন্ট তৃতীয়ে। Active Directory ক্রেডেনশিয়াল বা পারস্পরিক সার্টিফিকেট ব্যবহার করা এন্ডপয়েন্টের ব্যবস্থা সম্পূর্ণ আলাদা, আর ক্লায়েন্ট বদলালে তা বদলাবে না। অন্য কিছু ডিবাগ করার আগে প্রোফাইল যিনি দিয়েছেন তার সঙ্গে প্রমাণীকরণ মোড নিশ্চিত করুন।
একসঙ্গে নিলে তিনটি শর্ত একটি সংক্ষিপ্ত সিদ্ধান্ত সারণি দেয়:
| Platform | AWS-provided client | Completes the SAML exchange | What that means |
|---|---|---|---|
| Ubuntu 22.04 / 24.04 / 26.04, AMD64 | Yes | Yes | Normal sign-in path; debug stages, not platforms |
| Windows or macOS | Yes | Yes | Same path, different installer |
| Android | No published client | No | Needs a different access design, not a different profile |
| Other Linux distributions | No | Depends on the tool | Runs at your own support risk |
কেন OpenVPN আমদানি auth-federate-এ থেমে যায়
রপ্তানি করা AWS Client VPN প্রোফাইলে একটি নির্দেশ থাকে যা ক্লায়েন্টকে বলে যে প্রমাণীকরণ টানেলের বাইরে, ফেডারেশনের মাধ্যমে ঘটে। সাধারণ OpenVPN ক্লায়েন্ট হয় লাইনটি সরাসরি প্রত্যাখ্যান করে, নয় উপেক্ষা করে এবং তারপর দেওয়ার মতো কোনো ক্রেডেনশিয়াল থাকে না। এখানেই বেশিরভাগ Android প্রচেষ্টা শেষ হয়: প্রোফাইল আমদানি হয়, অ্যাপ আপত্তি করে, বা একটি প্যাকেটও ডিভাইস ছাড়ার আগেই সংযোগটি কনফিগারেশন ত্রুটিতে মারা যায়।
auth-federate মুছে ফেলা পরের প্রলুব্ধকর পদক্ষেপ, আর এটি একটি স্পষ্ট ব্যর্থতাকে বিভ্রান্তিকর ব্যর্থতায় বদলে দেয়। একটি নির্দেশ সরিয়ে ফেললে SAML এন্ডপয়েন্ট ব্যবহারকারীনাম-পাসওয়ার্ড প্রমাণীকরণে রূপান্তরিত হয় না। এন্ডপয়েন্ট এখনও স্বাক্ষরিত SAML প্রতিক্রিয়া প্রত্যাশা করে এবং ক্লায়েন্ট তার বদলে যা পাঠায় তা প্রত্যাখ্যান করে। আপনার অ্যাকাউন্ট পাসওয়ার্ড, ডাউনলোড করা প্রোফাইল আর কপি করা দাবি—এগুলো বিনিময়যোগ্য ক্রেডেনশিয়াল নয়।
ফোনে Chrome-এ পরিচয় প্রদানকারীতে সাইন ইন করা শুধু প্রমাণ করে যে পরিচয় প্রদানকারী ব্যবহারকারীকে গ্রহণ করেছে। এটি সেই প্রতিক্রিয়া এমন ক্লায়েন্টের কাছে পৌঁছাবে কি না সে বিষয়ে কিছুই বলে না যে তা এন্ডপয়েন্টে ফেরত পাঠাতে পারে। ফেডারেটেড প্রমাণীকরণের প্রয়োজনীয়তা ঠিক সেই কারণেই প্রদত্ত ক্লায়েন্টকে প্রবাহের অংশ করে: ব্রাউজার ধাপটি প্রয়োজনীয়, যথেষ্ট নয়।
সমর্থিত Linux ডেস্কটপ পথটি কেমন দেখায়
আপনার সিস্টেম প্যাকেজ ম্যানেজার দিয়ে AWS যে প্যাকেজটি Ubuntu AMD64-এর জন্য প্রকাশ করে তা ইনস্টল করুন, তারপর প্রোফাইলটি সাধারণ VPN অ্যাপে আমদানি না করে সেই ক্লায়েন্ট থেকেই সংযোগ খুলুন। আপনার প্রশাসক এই এন্ডপয়েন্টের জন্য যে প্রোফাইল রপ্তানি করেছেন তা ব্যবহার করুন; পুরোনো কোনো নির্দেশিকার callback URL বা ক্লায়েন্ট শনাক্তকারী দিয়ে তা বদলাবেন না, ক্লায়েন্ট তা গ্রহণ করলেও।
সংযোগ শুরু করুন, যে ব্রাউজার খোলে তাতে সাইন ইন ও যেকোনো MFA প্রম্পট সম্পূর্ণ করুন, এবং ব্রাউজার-থেকে-ক্লায়েন্ট ফেরার প্রবাহ শেষ হতে দিন। তারপর আপনার সত্যিই প্রয়োজনীয় প্রাইভেট ঠিকানাটি নতুন করে চান। সফল সাইন ইন ঘোষণা করা একটি পাতা টানেল উঠেছে তার প্রমাণ নয়।
Linux ক্লায়েন্ট SAML প্রতিক্রিয়ার জন্য 8096 থেকে 8115 পর্যন্ত স্থানীয় TCP পোর্ট সংরক্ষিত রাখে। পরিচয় প্রদানকারী আপনাকে গ্রহণ করার পরেও হ্যান্ড-অফ আটকে গেলে, ওই পরিসরে ইতিমধ্যে কী শুনছে তা দেখুন:
ss -ltnp | grep -E ":809[6-9]|:81(0[0-9]|1[0-5])"
একটি দখলকৃত পোর্ট, বা এন্ডপয়েন্ট সিকিউরিটি সফটওয়্যার যা লুপব্যাক শ্রোতাকে ব্লক করে, এমন সাইন ইন তৈরি করে যা সম্পূর্ণ হওয়ার মতো দেখায় আর তারপর কখনও সংযোগ করে না। ওই পরিসরটি স্থানীয় রাখুন। এটি ক্লায়েন্ট-পাশের ফেরার পথ, EC2 সিকিউরিটি গ্রুপে বা গেটওয়ে ফায়ারওয়াল নিয়মে খোলার মতো কিছু নয়, আর এটি ইন্টারনেটে খুললে কিছু না ঠিকিয়ে ঝুঁকি বাড়ায়।
কিছু বদলানোর আগে ব্যর্থ ধাপটি পড়ুন
ক্লায়েন্টকে দোষ দেওয়া স্বাভাবিক প্রতিক্রিয়া, কিন্তু প্রতিটি ব্যর্থতার বিন্দু ভিন্ন মালিকের। প্রথমে নির্ধারণ করুন আপনি আসলে কোথায় আছেন।
- কোনো ব্রাউজার উইন্ডো খোলে না। প্রোফাইলের প্রমাণীকরণ মোড, আপনি যে সংযোগ বেছেছেন, এবং ডেস্কটপের ডিফল্ট-ব্রাউজার ইন্টিগ্রেশন দেখুন।
- পরিচয় প্রদানকারী অ্যাকাউন্টটি প্রত্যাখ্যান করে। অ্যাকাউন্ট বরাদ্দ, MFA নিবন্ধন বা SAML অ্যাপ্লিকেশন কনফিগারেশন, সবই প্রশাসকের এলাকা।
- ব্রাউজার শেষ হয় কিন্তু ক্লায়েন্ট কখনও সংযোগ করে না। মেয়াদোত্তীর্ণ বা অব্যবহারযোগ্য প্রমাণীকরণ প্রতিক্রিয়া, ব্লক করা ফেরার পোর্ট, বা ব্যর্থ হ্যান্ড-অফ।
- টানেল উঠেছে কিন্তু অ্যাপ্লিকেশনটি পৌঁছানোর বাইরে। এন্ডপয়েন্ট রুট, অনুমোদন নিয়ম, সিকিউরিটি গ্রুপ, DNS। ব্রাউজার লগইন পুনরাবৃত্তি করলে অনুপস্থিত নেটওয়ার্ক অনুমতি যোগ হয় না।
এস্কেলেট করার সময় ক্লায়েন্টের ত্রুটি পাঠ ও প্রচেষ্টার সময় রাখুন। SAML ভাঙা—এই বক্তব্য আর ক্লায়েন্ট কখনও বৈধ প্রমাণীকরণ প্রতিক্রিয়া পায়নি—এই বক্তব্য মানুষকে সম্পূর্ণ ভিন্ন জায়গায় পাঠায়।
প্রয়োজনটি তবুও Android হলে
Android এমন প্ল্যাটফর্ম নয় যার জন্য AWS নিজের ক্লায়েন্ট প্রকাশ করে, তাই সৎ উত্তর হলো ইনস্টল করার মতো কোনো সমর্থিত মোবাইল ক্লায়েন্ট নেই। এটি একটি নকশা-সীমাবদ্ধতা, ফোনে প্রোফাইল সম্পাদনা করে কিছু সংযোগ না হওয়া পর্যন্ত সমাধান করার ধাঁধা নয়।
যা বদলাতে পারে তা হলো এর পেছনের অ্যাক্সেস নকশা, আর সেই সিদ্ধান্ত প্রশাসকের: ফোনটির প্রয়োজনীয় একমাত্র অভ্যন্তরীণ সেবায় একটি অনুমোদিত অ্যাপ্লিকেশন-অ্যাক্সেস পথ, সংস্থা ইতিমধ্যে চালায় এমন একটি মোবাইল-সক্ষম VPN পণ্য, বা শুধু SAML ব্যবহার করা এন্ডপয়েন্টের জন্য একটি সমর্থিত ডেস্কটপ। প্রতিটি বিকল্প নিজের এন্ডপয়েন্ট কনফিগারেশন, পরিচয় নিবন্ধন ও অনুমোদন নিয়ম নিয়ে আসে, যার কোনোটিই ব্যবহারকারী ডাউনলোড করা প্রোফাইল থেকে বানাতে পারেন না।
যে তৃতীয় পক্ষের টুল দাবি করে ফাঁকটি বন্ধ করে, তাদের MFA, প্রতিক্রিয়া পরিচালনা, ডিভাইস নীতি ও আপডেটের ছন্দ কভার করে স্পষ্ট সমর্থন ও নিরাপত্তা পর্যালোচনা দরকার। তাদের অস্তিত্ব তাদের AWS-প্রদত্ত Android ক্লায়েন্ট বানায় না, আর কোনো একটি চালু করতে পুনর্ব্যবহারযোগ্য প্রমাণীকরণ উপাদান ফোনে সরাবেন না।
নির্দেশ নিয়ে দীর্ঘ আলোচনার বদলে প্রশাসককে তিনটি তথ্য দিন: এন্ডপয়েন্টের প্রমাণীকরণ মোড, ফোনটিকে যে প্রাইভেট সম্পদে পৌঁছাতে হবে, এবং সময়সীমা। ডেস্কটপ, অ্যাপ্লিকেশন-অ্যাক্সেস পথ আর নতুন VPN পণ্যের মধ্যে বেছে নিতে এটুকুই যথেষ্ট।
আরেকটি টিকিট খোলার আগে শর্তগুলো ক্রমে যাচাই করুন: প্ল্যাটফর্ম প্রদত্ত-ক্লায়েন্ট তালিকায় আছে কি না, ব্রাউজার বিনিময় সম্পূর্ণ করতে পারে এমন টুল, সত্যিই ফেডারেশনের জন্য কনফিগার করা এন্ডপয়েন্ট, এবং Linux-এ লুপব্যাক পোর্ট পরিসর। যে প্রথমটি ব্যর্থ হয় সেটিই ঠিক করার বিষয়। তার পরের সবই অনুমান।