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 الٹ ثابت ہونے تک حالت کا مسئلہ ہے۔ ڈیمن صاف کرنا دوبارہ بوٹ سے تیز ہے، اور یہ وہ لاگ شواہد بچاتا ہے جو دوبارہ بوٹ پھینک دیتا۔