Mac VPN একবার সংযোগ করে, তারপর সময় শেষ: IKE ডেমন সাফ করুন

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

macOS-এ সেই কিছুটি সাধারণত IKE ডেমন।

ধরনটি: একবার সংযোগ, তারপর সময় শেষ

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

এটি একটি লগ খোলার আগেই তদন্তকে সংকুচিত করে। প্রশ্নটি হয় কোন প্রসেসটি IKE পোর্টের মালিক এবং এটি নিজেকে কী করছে বলে ভাবে।

দুটি ডেমন, একটি পোর্ট

সিস্টেম চালায় racoon যখন একটি সংযোগ IKE সংস্করণ 1-এ কথা বলে। বর্তমান রিলিজগুলোও নিয়ে আসে iked IKEv2 এবং নতুন IPsec স্ট্যাকের জন্য। দুটোই UDP 500 এবং UDP 4500 বাঁধতে পারে, এবং দুটোই পাসওয়ার্ড প্রম্পটে একটি সংযোগের চেষ্টা বাতিল হলে বা নেটওয়ার্ক পরিবর্তনে বাধাগ্রস্ত হলে একটি অর্ধ-খোলা নিরাপত্তা অ্যাসোসিয়েশন ধরে রাখতে পারে।

এমন হলে পরের চেষ্টাটি পরিষ্কারভাবে শুরু হয় না। পুরোনো অ্যাসোসিয়েশন যখন পিয়ারের অবস্থা দখল করে থাকে তখনই এটি আলোচনার চেষ্টা করে, এবং বিনিময়টি স্পষ্ট ত্রুটিতে ব্যর্থ হওয়ার বদলে আটকে যায়। ব্যবহারকারী একটি ঘূর্ণায়মান চিহ্ন দেখেন, তারপর সময় শেষ।

কিছু হত্যার আগে মালিককে খুঁজুন, কারণ উত্তরটিই ঠিক করে কোন পরিষেবা রিস্টার্ট করবেন এবং পরে কোন লগ পড়বেন।

sudo lsof -i :500 -i :4500
ps -ef | grep -E "racoon|iked"

আউটপুটটি দুটি তথ্য হিসেবে পড়ুন: কোন প্রসেস পোর্টটি ধরে আছে, এবং তাদের একাধিক উপস্থিত কি না। একই সকেটের জন্য প্রতিদ্বন্দ্বিতারত দুটি IKE ডেমন অস্থির সার্ভারের মতো দেখতে অনেক অনিয়মিত আচরণ ব্যাখ্যা করে।

প্রসেস নয়, জব রিস্টার্ট করুন

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

sudo launchctl stop com.apple.racoon
sudo launchctl start com.apple.racoon

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

তারপর একবার সংযোগ করুন এবং ক্লায়েন্ট লগটি শুরু থেকে পড়ুন। যে আলোচনা ধাপ 1 পেরিয়ে তারপর ট্রান্সমিট ব্যর্থতার কথা জানায়, সেটি স্থানীয় সকেট সমস্যাটিরই পুনরাবৃত্তি করছে; পিয়ার যে আলোচনা প্রত্যাখ্যান করে তা সম্পূর্ণ ভিন্ন একটি টিকিট।

যখন সার্ভারই প্রত্যাখ্যান করছে

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

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

আবার ক্লায়েন্ট বদলানোর আগে পিয়ারের লগ পড়ুন। প্রত্যাখ্যান, নীতি অমিল আর নীরব বাদ দেওয়া তিনটি ভিন্ন কারণ, যেগুলো সবই Mac-এর পর্দায় “সংযোগ হচ্ছে” বলে দেখায়।

পুরোনো ক্লায়েন্ট এবং 64-বিট কার্নেল

পুরোনো Cisco IPSec ক্লায়েন্ট 32-বিট এবং PowerPC সিস্টেমের জন্য তৈরি একটি কার্নেল এক্সটেনশন লোড করে। 64-বিট কার্নেলে বুট করা Mac-এ সেই এক্সটেনশনটি লোড হতে পারে না, এবং ক্লায়েন্ট ত্রুটি 51 নিয়ে শুরুতেই ব্যর্থ হয়, কারণ এটি VPN সাবসিস্টেমে আদৌ পৌঁছাতে পারে না। ভুল আর্কিটেকচারের কার্নেল এক্সটেনশন কোনো পরিমাণ ডেমন রিস্টার্টে ঠিক হয় না।

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

• একবার পুনরুৎপাদন করুন, তারপর প্রোফাইলে হাত দেওয়ার আগে কোন ডেমন UDP 500-এর মালিক তা দেখুন।
• ধাপ 1-এর পরের প্রথম ব্যর্থতাটি পড়ুন: ট্রান্সমিট ত্রুটি স্থানীয় সকেটের দিকে ইঙ্গিত করে।
• কেবল প্রসেস নয়, launchd জবটি রিস্টার্ট করুন এবং নিশ্চিত করুন পোর্টটি মুক্ত।
• সার্ভার-পক্ষীয় পুনঃপ্রমাণীকরণ উইন্ডোকে ক্লায়েন্ট ত্রুটি থেকে আলাদা করতে একটি দ্বিতীয় অ্যাকাউন্ট চেষ্টা করুন।
• ক্লায়েন্টকে দোষ দেওয়ার আগে কার্নেল আর্কিটেকচারটি লিখে রাখুন।

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