সংযোগ প্রত্যাখ্যান সার্টিফিকেটের সমস্যা নয়: একটি VPN রানবুক

আপনি CRL পুনরায় তৈরি করার ঠিক পরেই ক্লায়েন্ট বলে সংযোগ প্রত্যাখ্যাত, তাই CRL-ই দোষী মনে হয়। তা নয়। প্রত্যাখ্যান পরিবহন স্তরের উত্তর, আর সার্টিফিকেট যাচাই হয় পরে, টানেল হ্যান্ডশেকের ভেতরে। সময়ের মিল প্রমাণ নয়, প্রসঙ্গ।

দুটি পরীক্ষা এক মিনিটেরও কম সময়ে কেসগুলো আলাদা করে, এবং এর কোনোটিই ট্রাস্ট সেটিংস স্পর্শ করে না।

যে স্তর ত্রুটিটি তৈরি করেছে, সেই স্তরেই পড়ুন

connect থেকে ECONNREFUSED মানে পরিবহন প্রচেষ্টা প্রত্যাখ্যাত হয়েছে: কিছু একটি reset দিয়ে উত্তর দিয়েছে, বা স্ট্যাক একটি অপ্রাপ্য পোর্ট রিপোর্ট করেছে। সার্টিফিকেটের সমস্যা এই ত্রুটি তৈরি করতে পারে না, কারণ পরিবহন সংযোগ ছাড়া TLS হ্যান্ডশেক কখনো শুরু হয় না। প্রত্যাখ্যান দেখলে বোঝা যায়, ক্লায়েন্ট সার্টিফিকেট উপস্থাপন করার পর্যায়েই পৌঁছায়নি। এই একক তথ্য কারণ হিসেবে প্রত্যাহারকে বাদ দেয়।

উল্টোটাও সত্য। প্রত্যাহৃত সার্টিফিকেট সম্পূর্ণ TCP সংযোগ ও ব্যর্থ হ্যান্ডশেক তৈরি করে, যা সার্ভারে যাচাই ত্রুটি হিসেবে লগ হয়।

TCP প্রত্যাখ্যান: কেউ শুনছে না

TCP-র জন্য দেখুন উদ্দিষ্ট ইনস্ট্যান্স চলছে কি না এবং প্রোফাইলের ঠিকানা ও পোর্টে বাঁধা আছে কি না। ss -lntp শ্রবণকারীদের দেখায়, আর তাদের অনুপস্থিতিই সাধারণ ব্যাখ্যা। যে ফায়ারওয়াল বাতিল না করে প্রত্যাখ্যান করে, সেটিও ক্লায়েন্টের দিকে একই বার্তা দেয়, তাই দুটোই পরীক্ষা করুন।

ঠিকানার পরিবারও দেখুন। 127.0.0.1 বা কেবল IPv6-তে বাঁধা সার্ভিস অন্যটিতে রিজলভ হওয়া ক্লায়েন্টকে প্রত্যাখ্যান করবে।

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

UDP-তে প্রত্যাখ্যান করার মতো হ্যান্ডশেক নেই

UDP-তে OpenVPN TCP অর্থে সংযোগ প্রতিষ্ঠা করে না, তাই connect-এর সময় প্রত্যাখ্যান করার কিছু নেই। Linux-এ UDP সকেটের দেখানো ত্রুটি আগের ডেটাগ্রাম থেকে তৈরি ICMP port-unreachable থেকেও আসতে পারে। udp(7) ম্যান পেজ এই অ্যাসিঙ্ক্রোনাস আচরণ বর্ণনা করে।

এজন্যই UDP ক্লায়েন্ট প্রত্যাখ্যান ছাপতে পারে যখন সার্ভার প্রসেস চলছে কিন্তু প্রত্যাশিত ঠিকানায় বাঁধা নেই।

CRL আসলে কোথায় যাচাই হয়

CRL পরামর্শ করা হয় TLS হ্যান্ডশেকের সময়, প্রতিপক্ষ তার সার্টিফিকেট উপস্থাপন করার পরে, এবং কেবল যদি সার্ভার কনফিগারেশন তা সক্রিয় করে। OpenVPN-এর crl-verify অপশন ফাইলটির দিকে ইঙ্গিত করে, আর ব্যর্থতা সার্ভার লগে সার্টিফিকেটের নাম উল্লেখ করে যাচাই ত্রুটি হিসেবে দেখা যায়।

তাই প্রত্যাহৃত ক্লায়েন্ট পরিবহন স্তরে সংযোগ করে, তারপর প্রমাণীকরণে ব্যর্থ হয়। একই সার্ভার, একই পোর্ট, সম্পূর্ণ ভিন্ন বার্তা।

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

পরের বারটির জন্য সংক্ষিপ্ত রানবুক

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

পরিবহন, রিজলভ হওয়া গন্তব্য, পোর্ট ও সঠিক ত্রুটি লেখাটি লিখে রাখুন। ক্লায়েন্ট পুনরায় ইনস্টল করলে সেই প্রমাণ নষ্ট হয় এবং সাধারণত কিছুই বদলায় না।