Mac پر VPN میں سرٹیفکیٹ سے لاگ ان: شناخت، کلید کا استعمال یا گیٹ وے پر اعتماد؟
سرٹیفکیٹ سے لاگ ان کے پیچھے تین فیصلے ہیں: کون سی شناخت منتخب ہوتی ہے، VPN جزو اپنی کلید استعمال کر سکتا ہے یا نہیں، اور گیٹ وے قابلِ اعتماد ہے یا نہیں۔
سرٹیفکیٹ پر مبنی VPN لاگ ان Mac سے پاس ورڈ سے زیادہ تنگ چیز مانگتے ہیں: یہی مخصوص نجی کلید، اسی عمل آوری کے سیاق میں، اُس گیٹ وے کے سامنے شناخت ثابت کرنے کے لیے استعمال کرو۔ جب یہ ناکام ہوتا ہے، پیغام عموماً صرف آخری غلط بات بیان کرتا ہے، اور وہی سبب ہونا کم ہی ہوتا ہے۔ نظام جس ترتیب سے تینوں فیصلے کرتا ہے اسی ترتیب سے ان پر چلنا تشخیص کو دیانت دار رکھتا ہے، اور مقامی اجازت کے مسئلے کو زنجیر کی تصدیق کی ناکامی سمجھنے سے روکتا ہے۔
لاگ ان اسی ترتیب سے طے کرو جس ترتیب سے Mac کرتا ہے
پہلے کلائنٹ ایک شناخت منتخب کرتا ہے: قابلِ استعمال نجی کلید کے ساتھ جوڑا گیا سرٹیفکیٹ، جو معاون اسٹور یا اسناد فراہم کرنے والے کے ذریعے دستیاب ہوتا ہے۔ پھر VPN جزو اُس کلید سے ایک خفیہ نگاری کا عمل کرنے کی درخواست کرتا ہے، اور مقامی اجازت کا نمونہ جواب دیتا ہے۔ دونوں کے کامیاب ہونے کے بعد ہی دور دراز مصافحہ ہوتا ہے، جہاں Mac گیٹ وے کا جائزہ لیتا ہے اور گیٹ وے کلائنٹ کے ثبوت کا جائزہ لیتا ہے۔
| Decision | Typical symptom | Where to look |
|---|---|---|
| Identity selection | No valid identity, wrong certificate offered | Profile and which identity the client picked |
| Local key use | Signing or interaction error before any handshake | Execution context and key access rules |
| Remote authentication | Chain, name or client-admission rejection | Gateway identity and what it accepts |
جدول اوپر سے نیچے پڑھو اور پہلی ناکام سطر پر رک جاؤ۔ ناکامی کے نیچے سب کچھ غیر ثابت ہے، اسی لیے «سرٹیفکیٹ قابلِ اعتماد نہیں» اتنا عام اور اتنا ناقابلِ بھروسا نتیجہ ہے۔
مقامی اجازت دراصل کیا محیط ہے
macOS کے کلیدوں کے گچھے کے نمونے میں، محفوظ اشیاء عمل کے مخصوص رسائی قواعد اور قابلِ اعتماد اطلاقیوں کی فہرست رکھتی ہیں۔ نجی کلید سے دستخط کرنا ایسے ہی عملوں میں سے ایک ہے، اور قواعد اُس قابلِ عمل فائل پر لاگو ہوتے ہیں جو یہ کرتی ہے، دستاویز کے طور پر سرٹیفکیٹ پر نہیں۔ Apple کا رسائی کنٹرول حوالہ اس نمونے اور iCloud کے کلیدوں کے گچھے اور رسائی گروہ کے انتظامات کے درمیان بھی لکیر کھینچتا ہے، اس لیے ایک کے لیے لکھا گیا مشورہ دوسرے پر منتقل نہیں ہوتا۔
اس سے دو نتائج برآمد ہوتے ہیں۔ فہرست میں نظر آنے والا عوامی سرٹیفکیٹ یہ ثابت نہیں کرتا کہ VPN کا پس منظر جزو اُس کلید تک پہنچ ہی سکتا ہے۔ اور سامنے والے اطلاقیے کو دی گئی اجازت الگ مددگار یا نیٹ ورک توسیع کے بارے میں کچھ نہیں کہتی، کیونکہ وہ مختلف شناختوں والا مختلف کوڈ ہے۔
پرانے کلائنٹ سے قابلِ عمل فائل کا راستہ نقل کرنے کے بجائے اصل عمل آوری اور اُس کا معاون اسناد بانٹنے کا طریقہ پہچانو۔ پہلے یقینی کرو کہ نظام کون سی شناخت پیش کرے گا:
security find-identity -v -p ssl-clienterrSecInteractionNotAllowed کو پڑھنا
یہ حالت Security Server کے ساتھ نا منظور شدہ تعامل کی اطلاع دیتی ہے، اور سرٹیفکیٹ زنجیروں کے بارے میں کچھ نہیں کہتی۔ اسے اُس عمل کے ساتھ پڑھو جس نے اسے پیدا کیا: ایسے سیاق سے بھیجی گئی دستخط کی درخواست جو سوال نامہ نہیں دکھا سکتا، اسی طرح ناکام ہوگی، اگرچہ کلید اور سرٹیفکیٹ دونوں مکمل طور پر درست ہوں۔ آغاز وہ عمل ہے جس نے اسے درج کیا، سرٹیفکیٹ اسٹور نہیں۔ اعتماد کے لنگر پر تم جو بھی بدلو گے، غلطی کو ٹھیک وہیں چھوڑ دے گا جہاں وہ تھی۔
اس لیے کوڈ کو عمل آوری کے سیاق اور اجازت جانچنے کی وجہ سمجھو۔ اسے اس ثبوت کے طور پر لینا کہ گیٹ وے کا CA قابلِ اعتماد نہیں، تمہیں مسئلے کے غلط آدھے حصے میں بھیجتا ہے، اور وہاں کی گئی تمہاری تبدیلی غلطی پر بالکل اثر نہیں ڈالے گی۔
تنگ جگہ درست کرو، وسیع نہیں
رابطے کے مالک کی اندراج یا درآمد کی ہدایات سے شروع کرو۔ کلائنٹ کا نسخہ، پروفائل کا دائرہ، منتخب شناخت اور پہلی متعلقہ مقامی غلطی درج کرو، کیونکہ یہی چار حقائق معاونت کے حوالے کرنے کو درکار ہیں اور بعد کا موازنہ انہی پر منحصر ہے۔ زیرِ انتظام پروفائل یا ہارڈویئر کی تائید والی شناخت کے لیے منتظم یا فراہم کنندہ کو حوالگی درست کرنی پڑ سکتی ہے، اور مقامی کلکس کی کوئی مقدار اُس کا بدل نہیں بنتی۔
جہاں مصنوع صارف کی منظوری کی توقع کرتا ہے، وہاں یقینی کرو کہ کون سا جزو مانگ رہا ہے اور معاون بہاؤ کے ذریعے صرف اُسی رسائی کی منظوری دو۔ جہاں جزو کے پاس جس سیاق میں وہ چلتا ہے وہاں سوال نامہ اٹھانے کا کوئی راستہ نہیں، وہاں تیاری کو فروش کے دستاویزی راستے کی پیروی کرنی ہوگی، کسی دوسری ٹرمینل کھڑکی سے کھینچے گئے مکالمے کی نہیں۔
پرانے مشوروں میں دو تبدیلیاں ایک ساتھ باندھ دی جاتی ہیں، اور دونوں بہت وسیع ہیں۔ ہر اطلاقیے کو نجی کلید تک رسائی دینا مقامی کلید کے استعمال کو ضرورت سے بہت آگے پھیلا دیتا ہے، اور سرٹیفکیٹ کو Always Trust پر رکھنا مشین کی ہر چیز کے لیے سرٹیفکیٹ کا جائزہ بدل دیتا ہے۔ ان میں سے کوئی بھی «یہ منظور شدہ VPN عمل آوری، یہی ارادی شناخت استعمال کرتے ہوئے» نہیں کہتی۔
گیٹ وے پڑھنے سے پہلے مقامی طور پر جانچو
مرمت کے بعد یقینی کرو کہ مقامی عمل کامیاب ہوتا ہے اس سے پہلے کہ دوسری طرف سے آنے والے کسی جواب کی تعبیر دو۔ اگر دستخط اب کام کرتے ہیں، تو بعد میں نام، زنجیر یا کلائنٹ کے داخلے کی نامنظوری نیا نتیجہ ہے، تکرار نہیں، اور یہ الگ ذمہ دار والے الگ فیصلے کا حصہ ہے۔
مفید حوالگی یہ بتاتی ہے کہ تینوں فیصلوں میں کون سا ناکام ہوا اور وہیں رک جاتی ہے۔ اس میں کبھی نجی کلید شامل نہیں ہوتی، اور صاف حالت مدد کرے گی کی اُمید میں کبھی غیر متعلق کلیدوں کے گچھے کی اشیاء ری سیٹ نہیں کرتی۔ یہ دو عادتیں واقعے کے دوران نہیں، بلکہ اُس سے پہلے طے کرو، کیونکہ سب کچھ ایک ساتھ آزمانے کا لالچ اُس وقت سب سے زیادہ ہوتا ہے۔ «کلیدوں کا گچھا دوبارہ بنایا گیا» کہنے والی ٹکٹ اگلے قاری کو اصل خرابی کے بارے میں تقریباً کچھ نہیں بتاتی۔