একটি ত্রুটি, তিনটি গোপনীয়তা: কোন VPN লগইন তথ্য ব্যর্থ হয়েছে?
ক্লায়েন্ট প্রতিটি ধাপের জন্য একটি ত্রুটি দেখায়। যে পাসওয়ার্ড কেউ যাচাই করেনি তা রিসেট করার আগে অ্যাসোসিয়েশন, ব্যবহারকারীর বিনিময় এবং পদ্ধতিটি পড়ুন।
«প্রমাণীকরণ ব্যর্থ হয়েছে» একটি সার্ভার সার্টিফিকেট, মেশিনের পূর্ব-শেয়ার করা কী বা ব্যবহারকারীর পাসওয়ার্ডের দিকে ইঙ্গিত করতে পারে। কোনটি বোঝানো হয়েছে তা প্রোটোকলের উপর নির্ভর করে, কারণ প্রতিটি প্রোটোকল আলাদা গোপনীয়তার সেট নির্ধারণ করে। ভুলটি রিসেট করলে ত্রুটি অপরিবর্তিতই থাকে। পথ হলো, কিছু সম্পাদনা করার আগে প্রোটোকলটি কতটি প্রমাণ দাবি করে তা নির্ধারণ করা।
বিপরীত দিকে ইশারা করা দুটি প্রমাণ
একটি টানেলকে উত্তর দিতে হয় যে এটি সঠিক গেটওয়েতে পৌঁছেছে কি না, এবং আলাদাভাবে ব্যবহারকারী কে। গেটওয়ের প্রমাণ মেশিন-স্তরের: একটি সার্ভার সার্টিফিকেট, একটি পূর্ব-শেয়ার করা কী বা একটি স্থির পাবলিক কী। ব্যবহারকারীর প্রমাণ ব্যক্তি-স্তরের: একটি পাসওয়ার্ড, একটি টোকেন, একটি ক্লায়েন্ট সার্টিফিকেট, বা কিছুই না। এগুলো বিশ্বাসের বিপরীত দিক এবং ভিন্ন উপাদান ব্যবহার করে।
IKEv2 গেটওয়ের প্রমাণ IKE_AUTH-এর ভিতরে সম্পন্ন করে এবং EAP ব্যবহার করা হলে এর পরে একটি আলাদা বিনিময়ে ব্যবহারকারীর প্রমাণ চালায়। IKEv2 স্পেসিফিকেশন এগুলোকে আলাদা বিভাগ হিসেবে রাখে, যা একটি শক্তিশালী সংকেত যে একটি বার্তা যখন উভয় রাউন্ড কভার করে তখন কোথায় দেখতে হবে।
বার্তা নয়, ধাপটি পড়ুন
কোন ধাপ ব্যর্থ হয়েছে তা নির্বিশেষে ক্লায়েন্ট একটি ত্রুটির স্ট্রিং দেখায়, তাই স্ট্রিংটি নিজেই প্রায় কোনো তথ্য বহন করে না। তথ্য বহন করে সেই অবস্থাটি যা আপনি প্রতিটি ধাপে পরিদর্শন করতে পারেন: একটি অ্যাসোসিয়েশন আছে কি না, একটি ব্যবহারকারী বিনিময় শুরু হয়েছে কি না, এবং ক্লায়েন্ট গেটওয়ে যে পদ্ধতি চেয়েছিল তা অফার করেছে কি না। সারণিটি ধাপগুলোকে প্রোটোকলের নামের বদলে সেইভাবে সাজায়।
| Stage that failed | Evidence you can inspect | What a password change cannot fix |
|---|---|---|
| The machine proof | no security association in the state list | a mismatched pre-shared key or an untrusted chain |
| The user proof | an association is up while PPP or EAP reports failure | an expired token, a locked account, a missing client key |
| The client's method support | the client offers no method the gateway accepts | a client without the required EAP or key material |
| The server's policy | the gateway rejects before any user exchange starts | a policy that requires a certificate the profile lacks |
কেবল দ্বিতীয় সারিটি এমন লগইন তথ্য নিয়ে, যা ব্যবহারকারী আবার টাইপ করতে পারে। বাকি তিনটি কনফিগারেশনের তথ্য, এবং এই অসঙ্গতিই কারণ এই ধরনের অনেক প্রতিবেদন এমন পাসওয়ার্ড রিসেটে শেষ হয় যা কিছুই বদলায় না। কোনো ফিল্ড স্পর্শ করার আগে আপনার প্রমাণের সঙ্গে মেলে এমন সারিটি পড়ুন।
দুই-গোপনীয়তার প্রোটোকল নিজের হাত দেখায়
L2TP IPsec-এর উপর দিয়ে সংখ্যাটি দৃশ্যমান করে, কারণ দুটি যাচাই আলাদা প্রসেসে ঘটে। IPsec স্তরটিকে প্রথমে পূর্ব-শেয়ার করা কী বা সার্টিফিকেট নিয়ে উঠতে হয়, এবং কেবল তারপর এর ভিতরের PPP একটি ব্যবহারকারী লগইন চেষ্টা করে।
মেশিনের গোপনীয়তা ভুল হলে কোনো অ্যাসোসিয়েশন গঠিত হয় না এবং ব্যবহারকারীর লগইন তথ্য কখনো চেষ্টা করা হয় না। মেশিনের গোপনীয়তা সঠিক এবং ব্যবহারকারীর গোপনীয়তা ভুল হলে অ্যাসোসিয়েশন থাকে এবং টানেল ইতিমধ্যে উঠে যাওয়ার পরে PPP লগইন প্রত্যাখ্যান করে। দুটিই দুটি ভিন্ন ঘটনা থেকে পর্দায় একই বার্তা তৈরি করে।
sudo swanctl --list-sas
sudo ip xfrm state list
sudo journalctl -u xl2tpd -n 50 --no-pagerখালি অ্যাসোসিয়েশন তালিকা ব্যবহারকারী স্তরটিকে সঙ্গে সঙ্গে বাদ দেয়, তাই পাসওয়ার্ডের আগে এটি দেখুন। বারবার PPP ব্যর্থতাসহ প্রতিষ্ঠিত অ্যাসোসিয়েশন উল্টো দিকে, ব্যবহারকারী স্তর বা তার ভিতরের প্রমাণীকরণ প্রোটোকলের দিকে ইশারা করে। কোনো সিদ্ধান্তই ক্লায়েন্টের ত্রুটির লেখা থেকে পাওয়া যায় না।
শুধু পাসওয়ার্ড প্রকৃতপক্ষে কীসের উপর নির্ভর করে
শুধু পাসওয়ার্ড দিয়ে প্রবেশ L2TP, PPTP, SSTP এবং EAP-সহ IKEv2-এর জন্য সাধারণ। WireGuard-এ এমন কোনো বিকল্পই নেই, কারণ এর পিয়াররা ব্যবহারকারী নয়, কী। OpenVPN-এর জন্য উত্তর আসে সার্ভারের ক্লায়েন্ট-সার্টিফিকেট প্রয়োজন থেকে: যে গেটওয়ে সার্টিফিকেট ও পাসওয়ার্ড দুটোই দাবি করে সে শুধু-পাসওয়ার্ড ক্লায়েন্টকে ফিল্ডে যা-ই লেখা হোক প্রত্যাখ্যান করতেই থাকবে।
আপনার কোন উপাদান দরকার তা একই উত্তরের অনুসরণে আসে। IKEv2-এর অধীনে পাসওয়ার্ড লগইনের জন্য এমন ক্লায়েন্ট দরকার যা EAP বলে, অন্যদিকে সার্টিফিকেট লগইনের জন্য ক্লায়েন্টের প্রাইভেট কী ও সার্ভারের চেইন দরকার। ভুলটি ইনস্টল করলে ব্যর্থতাটি লগইন তথ্যের ত্রুটির মতো পড়া যায়, যদিও প্রমাণীকরণ পদ্ধতিটিই অনুপস্থিত।
একটি জিনিস বদলান, তারপর আবার পরীক্ষা করুন
প্রথমে তিনটি তথ্য নির্ধারণ করুন: কোন প্রোটোকল চলছে, এটি কতটি গোপনীয়তা নির্ধারণ করে, এবং তাদের কোনটি ব্যবহারকারীর বদলে মেশিনের। মেশিন প্রথম ধাপে ব্যর্থ হয় এবং মানুষ দ্বিতীয়টিতে ব্যর্থ হয়, এবং দুটিকে গুলিয়ে ফেলাই এই পুরো সমস্যা।
তারপর ঠিক একটি জিনিস বদলান এবং একই ক্লায়েন্ট থেকে আবার পরীক্ষা করুন। এই নিয়মানুবর্তিতা একটি বিভ্রান্তিকর ব্যর্থতাকে এমন একটি সমাধানে পরিণত করে যা আপনি পরের ব্যক্তিকে বর্ণনা করতে পারেন, যা এমন একটি কাজ করা সংযোগের চেয়ে বেশি উপকারী যা কেউ ব্যাখ্যা করতে পারে না।