VPN সংযোগের সময় মেইল জমা ব্যর্থ হয়: পর্যায়টি খুঁজুন

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

ধাপ 1: শংসাপত্র স্পর্শ করার আগে ব্যর্থতাটি শ্রেণিবদ্ধ করুন

অ্যাপ্লিকেশনটি আসলে যে ত্রুটি তৈরি করেছে তা পড়ুন, তারপর সেটিকে তিনটি ঝুড়ির একটিতে রাখুন। টাইমআউট বা সংযোগ রিসেট মানে TCP পথ ব্যর্থ হয়েছে; TLS বা সার্টিফিকেট ত্রুটি মানে পথ কাজ করেছে কিন্তু হ্যান্ডশেক করেনি; কোডসহ SMTP প্রতিক্রিয়া মানে একটি মেইল সার্ভার উত্তর দিয়েছে এবং সিদ্ধান্ত নিয়েছে। প্রতিটি ঝুড়ি ভিন্ন এক মালিকের দিকে ইঙ্গিত করে।

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

VPN-এর বাইরে ব্যর্থতাটি পুনরুৎপাদন করতে না পারলে এখানেই থামুন। একটি মেশিনে একটি অ্যাপ্লিকেশনে যে সমস্যা দেখা যায়, তা এখনো নেটওয়ার্ক সমস্যা নয়।

ধাপ 2: এন্ডপয়েন্ট এবং TLS মোড নিশ্চিত করুন

বার্তা জমা দেওয়া একটি স্বতন্ত্র পরিষেবা, সার্ভার-থেকে-সার্ভার রিলের সঙ্গে একই জিনিস নয়। জমা দেওয়ার জন্য প্রদানকারীর ডকুমেন্টেশন থেকে হোস্টনেম, পোর্ট এবং TLS মোড নিশ্চিত করুন, কারণ অন্য মেইল সেটআপ থেকে ধার করা পরিচিত পোর্ট কোনো প্রমাণ নয়। পোর্ট 587 প্লেইনটেক্সট অভিবাদন এবং তারপর STARTTLS প্রত্যাশা করে, আর পোর্ট 465 প্রথম বাইট থেকেই TLS প্রত্যাশা করে।

openssl s_client -connect smtp.example.com:465 -servername smtp.example.com -quiet
openssl s_client -starttls smtp -connect smtp.example.com:587 -servername smtp.example.com -quiet
nc -vz smtp.example.com 587

ঐ দুটি প্রোবের মধ্যে ভুলটি চালানো ঠিক সেই ভুল যা ক্লায়েন্ট করে যখন এটি অন্য মোডের জন্য কনফিগার করা থাকে। যদি ইমপ্লিসিট-TLS প্রোব 587-এ আটকে যায়, বা STARTTLS প্রোব 465-এ ব্যর্থ হয়, তাহলে পোর্ট ও মোড মিলছে না। সার্টিফিকেট যাচাই বন্ধ করার বদলে ক্লায়েন্টে মোডটি ঠিক করুন, কারণ এটি একটি কনফিগারেশন ত্রুটিকে যাচাইহীন সংযোগে পরিণত করে। বিভাজনটি এত পুরোনো যে এটি মানক হয়ে গেছে: পোর্ট 465-এ ইমপ্লিসিট TLS হলো RFC 8314-এ বর্ণিত ব্যবস্থা।

এখানে সার্টিফিকেট ত্রুটি বাধা নয়, তথ্য। এটি সার্ভার যে পরিচয় উপস্থাপন করেছে এবং ক্লায়েন্ট যে পরিচয় প্রত্যাশা করেছে তা নাম দেয়, আর দুটোই সংযোগ দুর্বল না করেই ঠিক করা যায়।

ধাপ 3: অ্যাকাউন্ট না বদলে পথ তুলনা করুন

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

ip route get smtp.example.com
curl -v --ssl-reqd --url smtp://smtp.example.com:587 --user "$SMTP_USER" \
  --mail-from [email protected] --mail-rcpt [email protected] --upload-file msg.txt

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

টানেল যদি ইন্টারনেট ট্র্যাফিক বহন করার কথা হয়, তবে তার রাউটিং এবং তার ইগ্রেস নীতি উভয়কেই এই গন্তব্য অনুমোদন করতে হবে। যে টানেল কেবল প্রাইভেট রুট বহন করে, সেটি মেইল সংযোগকে স্থানীয় পথে রাখে, যা ভিন্ন একটি তুলনা।

ধাপ 4: একটি নিরীহ বার্তা পাঠান এবং প্রতিক্রিয়া লিপিবদ্ধ করুন

ব্যর্থ হওয়া পর্যায়টি ঠিক করুন, তারপর ওয়েবমেইল পৃষ্ঠার বদলে একই অ্যাপ্লিকেশন দিয়ে একটি নিরীহ বার্তা জমা দিন। আপনি অ্যাপ্লিকেশনের নিজের পাঠানোর পথটিই পরীক্ষা করছেন, তার সংরক্ষিত সেটিংস ও TLS মোডসহ। ওয়েবমেইল সেশন এ সম্পর্কে কিছুই প্রমাণ করে না।

প্রতিক্রিয়া, পোর্ট, TLS মোড এবং আপনার ব্যবহৃত পথ লিপিবদ্ধ করুন, যাতে পরের ব্যক্তি ফলাফলটি পুনরুৎপাদন করতে পারেন। একটি কাজ করা ব্রাউজার এবং একটি সবুজ VPN আইকন অন্য বিষয়ের পর্যবেক্ষণ। বার্তাটি পৌঁছালে, বাকি কাজ হলো এই অ্যাকাউন্ট দিয়ে পাঠানো প্রতিটি মেশিনের জন্য সেই কনফিগারেশনকে ডিফল্ট করা।

চেকলিস্ট সম্পূর্ণ হয় যখন আপনি ব্যর্থ হওয়া পর্যায়, ক্লায়েন্টের ব্যবহৃত পোর্ট ও TLS মোড, বার্তার নেওয়া পথ এবং সার্ভারের ফেরত দেওয়া প্রতিক্রিয়া নাম বলতে পারেন। এই চারটি তথ্য একটি অস্পষ্ট প্রেরণ-বাক্স সমস্যাকে এমন পরিবর্তনে পরিণত করে যা কেউ পর্যালোচনা করতে পারে।