OpenConnect লগইন ভুল পাতায় যাচ্ছে? আগে পথটি যাচাই করুন

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

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

ফর্ম দেখার আগে ক্লায়েন্ট কী পাঠায়

https://vpn.example.net/partners-এর মতো ঠিকানায় ক্লায়েন্টের প্রথম কাজ হলো খালি হোস্টে নয়, বরং সেই পথে একটি HTTPS অনুরোধ। ফেরত আসে সাধারণত সাইন-ইন এন্ডপয়েন্টে একটি রিডাইরেক্ট, অথবা ফর্মটিই। শুধু vpn.example.net দেওয়া ক্লায়েন্ট ডিফল্ট ল্যান্ডিং পেজ যা-ই হোক সেখান থেকেই শুরু করে, যা অন্য পোর্টাল, অন্য গ্রুপ তালিকা, বা সম্পূর্ণ ভিন্ন প্রোটোকল প্রত্যাশা করা পাতা হতে পারে। পার্থক্যটি কোনো ক্রেডেনশিয়াল টাইপ করার অনেক আগেই রেসপন্স হেডারেই দেখা যায়।

এই কারণেই একটি কাজ করা ব্রাউজার ট্যাব আর একটি ব্যর্থ ক্লায়েন্ট প্রোফাইল একই গেটওয়ে উল্লেখ করেও ভিন্ন হতে পারে। ব্রাউজার পথটি অনুসরণ করেছিল; প্রোফাইলে সেটি কখনোই ছিল না।

দুটি ইনপুট যা বিনিময়যোগ্য মনে হয়, কিন্তু নয়

OpenConnect প্রাথমিক HTTPS পথটি --usergroup হিসেবে প্রকাশ করে, এবং ম্যানুয়াল পৃষ্ঠা সেই পথসহ সম্পূর্ণ URL-কে একই অনুরোধের ভিন্ন লেখা হিসেবে গণ্য করে। --authgroup আলাদা অপশন: এটি লগইন ফর্মের ভেতরে গেটওয়ে যে তালিকা দেখায় সেখান থেকে একটি এন্ট্রি বেছে নেয়। কিছু প্রোটোকল সেই এন্ট্রিকে গ্রুপ বলে, কিছু ডোমেইন বা গেটওয়ে বলে, আর ঠিক সেখানেই দুটি ফ্ল্যাগ গুলিয়ে যায়।

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

অপারেটরের কাছে প্রতিটি মান আলাদা লাইনে চান: প্রবেশ পথ, ফর্ম নির্বাচন, এবং দুটিই আবশ্যক কি না। লেবেলগুলো একই রকম শোনায় বলে একটি থেকে অন্যটি অনুমান করবেন না।

পথ ছাঁটলে ফলাফল কেন বদলায়

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

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

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

অন্য কিছু সম্পাদনার আগে প্রবেশবিন্দু নিশ্চিত করুন

আপনাকে দেওয়া পথটির হেডার পড়ুন। curl -sS -o /dev/null -D - https://vpn.example.net/partners-এর মতো অনুরোধ রিডাইরেক্ট অনুসরণ না করেই স্ট্যাটাস লাইন ও যেকোনো Location হেডার ছাপে। নামযুক্ত সাইন-ইন এন্ডপয়েন্টে নির্দেশ করা একটি 302 নিশ্চিত করে পথটি আছে এবং কোথায় যায় দেখায়; একটি 404 বোঝায় অপারেটরের ঠিকানা পুরোনো।

তারপর অনুমোদিত ক্লায়েন্টে একই প্রবেশবিন্দু পুনরুৎপাদন করুন, যেমন openconnect --usergroup=partners vpn.example.net, এবং দেখুন কোন ফর্ম আসে। যদি ফর্মটি সঠিক হয় আর টানেল তবুও ব্যর্থ হয়, তবে পথটি কখনোই সমস্যা ছিল না এবং পরের গন্তব্য নীতি বা রাউটিং।

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