অবৈধ সিক্রেট কনটেইনারের সমস্যা, পাসওয়ার্ড নিয়মের নয়
প্রত্যাখ্যাত ক্রেডেনশিয়াল হয়তো গেটওয়েতে পৌঁছায়ইনি। আগে ইনপুট কনটেইনার, প্রমাণীকরণের ধাপ ও অ্যাকাউন্টটি তুলনা করুন।
«অবৈধ সিক্রেট» দেখলে সাধারণত একটি সিদ্ধান্তে পৌঁছানো হয়: ভিপিএন যতিচিহ্ন পছন্দ করে না। সেই সিদ্ধান্ত সাধারণত ভুল, কারণ বার্তাটি প্রায়ই স্থানীয় প্রক্রিয়াকরণ থেকে আসে, কোনো গেটওয়ে অ্যাকাউন্টটি দেখার আগেই। দুটি নকশা একই পাসওয়ার্ড পাঠায়, একটি গ্রাফিক্যাল ফিল্ড ও একটি ক্রেডেনশিয়াল ফাইল, এবং তারা আলাদা জায়গায় ব্যর্থ হয়। যে পাসওয়ার্ড সবসময় ঠিক ছিল, তা সরল করার আগে কনটেইনারগুলো তুলনা করুন।
ত্রুটি গেটওয়ের আগেই আসে
স্থানীয় যাচাই, তালাবদ্ধ সিক্রেট স্টোর, অনুপস্থিত এজেন্ট এবং বিকৃত ক্রেডেনশিয়াল ফাইল—সবই এমন ব্যর্থতা তৈরি করে যা ব্যবহারকারী একটি প্রত্যাখ্যান হিসেবে অনুভব করেন। এদের কোনোটিতেই প্রমাণীকরণ সার্ভার জড়িত নয়। গেটওয়ের নিজের প্রত্যাখ্যান আলাদা ঘটনা, এবং এটি সাধারণত ভিন্ন বার্তা ও ভিন্ন সময়ে আসে। এটি ঘটে টানেল তৈরি হওয়ার এবং ক্রেডেনশিয়াল পাঠানোর পরে।
তাই প্রথম প্রশ্ন কোন অক্ষর বৈধ তা নয়, বরং প্রচেষ্টাটি কোথায় থেমেছে তা। যে ক্লায়েন্ট কখনো সংযোগ খোলেনি, তাকে কেউ প্রত্যাখ্যান করেনি। আপনি যে ধাপটি দেখেছেন তা লিখে রাখুন, কারণ পরের প্রতিটি পদক্ষেপ এই শ্রেণিবিন্যাসের উপর নির্ভর করে।
এই পার্থক্য কে ঠিক করবে তাও বদলে দেয়। কনটেইনারের সমস্যা ডিভাইস ও তার মালিকের, আর অ্যাকাউন্ট প্রত্যাখ্যান প্রমাণীকরণ ব্যাকএন্ড চালানো ব্যক্তির।
অক্ষর নয়, কনটেইনার তুলনা করুন
একটি গ্রাফিক্যাল পাসওয়ার্ড ফিল্ড, একটি কীচেইন এন্ট্রি, দুই লাইনের ক্রেডেনশিয়াল ফাইল এবং একটি অটোমেশন সিক্রেট—প্রতিটি একই মান ভিন্ন খামে বহন করে। খামের নিজস্ব নিয়ম আছে, আর সাধারণত সেই নিয়মগুলোই ভাঙে। মান খুব কমই সমস্যা; মানটির পরিবহনই সমস্যা। দুটি ধারণা আলাদা রাখুন, রোগনির্ণয় ছোট হয়ে যাবে।
| Where the value stops | What you see | What you check | Who owns the fix |
|---|---|---|---|
| GUI field or managed profile | A validation message before any connection opens | The selected authentication mode and whether the field holds the secret or the username | The device owner or the profile author |
| Keychain or secret agent | A prompt that keeps reappearing, or an agent error | Whether the agent is unlocked and holds an entry for this profile | The user who owns the keychain |
| Two-line credential file | A prompt for a password that was already supplied | Line count, line order and whether a trailing newline is present | Whoever generated the file |
| Shell argument or environment | Works interactively but fails in automation | Whether the shell expanded, trimmed or logged the value | Whoever wrote the automation |
OpenVPN 2.6 কমিউনিটি ক্লায়েন্ট অপশন ওই দুই লাইনের ফাইলটি auth-user-pass-এর জন্য বর্ণনা করে, যার মধ্যে পাসওয়ার্ড লাইন অনুপস্থিত থাকলে কী আচরণ হয় তাও রয়েছে: তখন ক্লায়েন্ট নিজেই জিজ্ঞাসা করে। এই একটি বিবরণ «আমি আগেই যে পাসওয়ার্ড দিয়েছি, সেটাই আবার চাইছে» ধরনের অভিযোগের একটি শ্রেণি ব্যাখ্যা করে। এটি আপনাকে এটাও বলে যে খালি দ্বিতীয় লাইন একটি অর্থবহ অবস্থা, নিরীহ ফরম্যাটিং পছন্দ নয়।
উদ্ধৃতি আবার আলাদা একটি স্তর: সাধারণ ক্রেডেনশিয়াল ফাইলের ভেতরের উদ্ধৃতি চিহ্ন ডেটা হিসেবে সংরক্ষিত হয়, অথচ শেল প্রোগ্রামটি কিছু দেখার আগেই সেগুলো সরিয়ে দেয়। একই অক্ষর এক জায়গায় নিরীহ, অন্য জায়গায় গঠনগত। কোন কনটেইনার আপনার ক্লায়েন্ট ব্যবহার করেছে, তা টেবিল বলতে পারে না, তাই সারি বাছার আগে ক্লায়েন্টের নিজের কনফিগারেশন পড়ুন।
লাইন বিরতিও গঠনগত। লাইন-বিভক্ত ফিল্ডযুক্ত ফাইল নতুন লাইনযুক্ত মান বহন করতে পারে না, এবং এটি ফরম্যাটের সীমাবদ্ধতা, পাসওয়ার্ডের শক্তি সম্পর্কে বিচার নয়। তাৎক্ষণিক বানানো ফাইলে সিক্রেট ছোট করে বসানোর বদলে ডিপ্লয়মেন্টের সমর্থিত সরবরাহ ব্যবস্থা ব্যবহার করুন।
শেলের ক্ষতি ছাড়াই ক্রেডেনশিয়াল ফাইল তৈরি করুন
সবচেয়ে নিরাপদ স্থানীয় পথ সিক্রেটকে শেল ইতিহাস ও প্রসেস আর্গুমেন্ট তালিকার বাইরে রাখে। দুটি ফিল্ডই ইন্টারঅ্যাকটিভভাবে পড়ুন, তারপর ক্লায়েন্ট যে দুই লাইন আশা করে তা লিখুন। বাকি সব সহজে পর্যালোচনাযোগ্য কনফিগারেশন ফাইলে থাকতে পারে।
read -r VPN_USER
read -rs VPN_PASS
printf '%s\n%s\n' "$VPN_USER" "$VPN_PASS" > /etc/openvpn/client/creds
chmod 600 /etc/openvpn/client/creds
openvpn --config /etc/openvpn/client/office.conf --auth-user-pass /etc/openvpn/client/credsপ্রথম দুটি কমান্ড ব্যবহারকারীর নাম ও তারপর পাসওয়ার্ড না দেখিয়ে পড়ে, তৃতীয়টি দুই লাইন লেখে, চতুর্থটি ফাইলটি সীমিত করে, আর শেষটি ওই ফাইল দিয়ে ক্লায়েন্ট চালু করে। লক্ষ্য করুন read -r ব্যাকস্ল্যাশ সংরক্ষণ করে, এবং এটিই ঠিক সেই ধরনের বিবরণ যা বাদ পড়লে কাজ করা পাসওয়ার্ডকে ব্যর্থ পাসওয়ার্ডে বদলে দেয়।
উদ্ধৃতিহীন ভেরিয়েবল বা শেল সম্প্রসারণে ভরা here-document দিয়ে ফাইল তৈরি করা এড়িয়ে চলুন। দুটোই ফাইলে পৌঁছানোর আগে অক্ষর বদলে দিতে পারে, এবং ফলাফল ব্যর্থতা ভিপিএন প্রত্যাখ্যানের মতো দেখায়, কারণ ডিস্কে থাকা পাসওয়ার্ড সত্যিই আপনার জানা পাসওয়ার্ড থেকে আলাদা। সন্দেহ হলে সিক্রেট নিজে না ছেপে ফাইলের বাইট দৈর্ঘ্য প্রত্যাশিত মানের সঙ্গে তুলনা করুন। এক-দুই বাইটের পার্থক্যই উদ্ধৃতি দুর্ঘটনার স্বাক্ষর।
প্রথম ত্রুটি থেকেই ধাপটি পড়ুন
একটি প্রচেষ্টার প্রথম নির্দিষ্ট বার্তাটি ধরে রাখুন, তারপর সেটি শ্রেণিবদ্ধ করুন। স্থানীয় যাচাই ত্রুটি, অনুপস্থিত প্রাইভেট কী, অনুপলব্ধ সিক্রেট এজেন্ট এবং গেটওয়ে প্রমাণীকরণ ব্যর্থতা—এগুলো চারটি ভিন্ন ফলাফল, চারজন ভিন্ন মালিক। এদের মধ্যে কেবল একটি অ্যাকাউন্ট সম্পর্কে।
যদি গেটওয়ে সত্যিই সঠিকভাবে পাঠানো ক্রেডেনশিয়াল প্রত্যাখ্যান করে, অ্যাকাউন্ট, প্রমাণীকরণ ব্যাকএন্ড এবং প্রয়োজনীয় যেকোনো চ্যালেঞ্জ যাচাই করুন প্রশাসকের সঙ্গে। সাধারণ প্রমাণীকরণ ব্যর্থতা কোনো নিষিদ্ধ অক্ষরের নাম বলে না।
সঠিক ব্যবস্থার মাধ্যমে অনুমোদিত মানটি পুনরুদ্ধার করুন, তাকে অক্ষর ও ডিজিটে নামিয়ে আনবেন না। পাসওয়ার্ড নীতি অপারেটরের, আর চুপচাপ তা ভেঙে দেওয়া কোনো সমাধান নয়। এটি পরের ব্যক্তির কাছ থেকে আসল ত্রুটিটিও লুকিয়ে রাখে, যিনি দুর্বলতর পাসওয়ার্ড ও আরও খারাপ ধারণা নিয়ে একই ত্রুটির মুখোমুখি হবেন।