Mac IKEv2 ECDSA: کون سی سند کی قسم کلائنٹ کی ہے؟
Mac پر، IKEv2 ترتیبات میں ECDSA256 مقامی شناختی سند بیان کرتا ہے، گیٹ وے یا جاری کنندہ کے دستخط نہیں۔ انتخاب سے پہلے ہر کردار پڑھیں۔
macOS پر، IKEv2 کلائنٹ ترتیب میں ECDSA کا انتخاب ایک تنگ سوال کا جواب دیتا ہے: کون سی سند Mac کی شناخت ثابت کرتی ہے۔ یہ گیٹ وے کی سند، کلائنٹ سند جاری کرنے والے دستخط، یا ٹنل کی خفیہ کاری کی تجویز بیان نہیں کرتا۔ ان چار کرداروں کو ایک ہی مطابقت کا سوال سمجھنا ہی وہ راستہ ہے جس سے درست مقامی ترتیب کو سرور کی طرف عدم مطابقت کا ذمہ دار ٹھہرایا جاتا ہے۔ فیصلہ چھوٹا ہے، مگر اس کے لیے استعمال ہونے والے شواہد درست ہونے چاہئیں۔
یہ فیلڈ ایک سند کا نام دیتا ہے: مقامی شناخت
Apple کا Network Extension API کلائنٹ اسناد کے لیے سند کی قسم فراہم کرتا ہے، جس میں NEVPNIKEv2CertificateType.ECDSA256 شامل ہے، جو ECDSA p-256 سند کی قسم کے طور پر دستاویزی ہے۔ یہ خصوصیت identityReference یا identityData کے ذریعے فراہم کردہ سند پر لاگو ہوتی ہے۔
اس کا مطلب ہے کہ فیصلہ اس سند اور اس کے ساتھ آنے والی نجی کلید کے بارے میں ہے جو Mac پیش کرتا ہے۔ اس پتے کی سند کی عوامی کلید سے میل کھانے والی قسم منتخب کریں اور شناخت معاون طریقے سے فراہم کریں۔ اگر Mac کے پاس شناخت کے لیے قابل استعمال نجی کلید نہ ہو تو قسم کا انتخاب رابطہ نہیں بچا سکتا۔
منظم پروفائلز IKEv2 پے لوڈ کے CertificateType کے ذریعے وہی فیصلہ کرتے ہیں، ساتھ PayloadCertificateUUID جیسی سند حوالہ کے ساتھ۔ ان فیلڈز کی ہدف OS ورژن کے لیے پیشگی شرائط اور اسکیما ہیں؛ پروفائل میں نقل کیا گیا ننگا قسم مالیت نصب نہیں ہو سکتا، اور ترتیبات کی ونڈو ہر API اختیار نہ دکھا سکے۔ تعیناتی سے پہلے اس ورژن کے لیے پے لوڈ کی پیشگی شرائط جانچیں۔
سند کے لیبل سے نہیں، کردار سے فیصلہ کریں
جس فیلڈ کو آپ بدلنے والے ہیں اسے پڑھیں اور پوچھیں کہ یہ کس سند کی طرف اشارہ کرتا ہے۔ سند دیکھنے والے میں لیبل موضوع، جاری کنندہ اور دستخط الگورتھم کو ملا دیتے ہیں، اور ان میں سے صرف ایک کلائنٹ شناخت کے انتخاب سے متعلق ہے۔
| What you inspected | What it controls | Does it choose the Mac certificate type? |
|---|---|---|
| Client leaf public key | The identity the Mac presents | Yes, this is the field's subject |
| Issuer signature algorithm | How the client certificate was signed | No |
| Gateway certificate | What the Mac validates as the peer | No, check it separately |
| IKE and ESP proposals | Algorithms for the tunnel | No, separate proposal settings |
اگر سند دیکھنے والا CA کی طرف سے ECDSA دستخط دکھائے تو یہ جاری کنندہ کی دستخط کلید بیان کرتا ہے۔ کلائنٹ کی اپنی کلید اب بھی RSA ہو سکتی ہے، اور قسم کا فیلڈ دستخط کی سطر کے بجائے کلائنٹ کلید کی پیروی کرنا چاہیے۔ یہی ایک الجھن "ECDSA تشکیل شدہ ہے مگر رابطہ ناکام ہوتا ہے" جیسی کئی رپورٹوں کی وضاحت کرتی ہے۔ کچھ بدلنے سے پہلے پتے میں کلید کی قسم کا پروفائل میں منتخب قسم سے موازنہ کریں۔
پتہ شناخت ہونے کے بعد فیصلہ آسان ہو جاتا ہے: p-256 کلائنٹ کلید کے لیے ECDSA256، مختلف کلید کے لیے دوسری معاون قسم۔ اگر کلائنٹ سند اور اس کی کلید میل نہ کھائیں تو VPN پروفائل بدلنے سے پہلے اس جوڑی کو درست کریں۔
گیٹ وے کی سند الگ فیصلہ ہے
گیٹ وے اپنی سند پیش کرتا ہے اور Mac اسے اعتماد لنگر اور متوقع نام کے خلاف تصدیق کرتا ہے۔ یہ کہ وہ سند ECDSA، RSA یا کوئی اور کلید قسم استعمال کرتی ہے، سرور کی خصوصیت ہے، کلائنٹ شناخت ترتیب کی نہیں۔
ECDSA کلائنٹ سند کے لیے مقامی معاونت یہ ثابت نہیں کرتی کہ ہر گیٹ وے سند، منحنی یا سرور توثیق ترتیب باہم کام کرے گی۔ سرور کی شناخت، اس کی زنجیر اور IKE توثیق کا طریقہ الگ الگ ان پٹ کے طور پر جانچیں، اور اسی پروفائل سے آزمائیں جو واقعی تعینات ہوگا۔
اگر گیٹ وے سند ہی مسئلہ ہو، تو علامت عام طور پر ساتھی کی توثیق کے دوران ظاہر ہوتی ہے، شناخت کے انتخاب کے وقت نہیں۔ کلائنٹ کی قسم بدلنے سے پہلے ناکامی کا مرحلہ پڑھیں، کیونکہ اعتماد کی ناکامی اور کلائنٹ کلید کی عدم مطابقت کا حل ایک جیسا نہیں۔
جاری کنندہ کے دستخط اور کلید معاہدہ گروپ کلائنٹ کی قسم نہیں
X.509 موضوع کی عوامی کلید اور جاری کنندہ کے دستخط کو الگ فیلڈز میں رکھتا ہے۔ موضوع کی عوامی کلید کی معلومات سند میں موجود کلید بیان کرتی ہے؛ دستخط الگورتھم CA کی کلید اور دستخط عمل بیان کرتا ہے۔ سند قسم کی ترتیب سے صرف پہلا میل کھاتا ہے۔
IKE اور Child SA تجاویز دوسرا محور ہیں۔ ECDSA سند کی قسم ESP خفیہ کاری کا انتخاب نہیں ہے، اور کلید معاہدہ گروپ بدلنے سے سند کی قسم منتخب نہیں ہوتی۔ پروفائل میں درست تجاویز اور غلط شناخت قسم ہو سکتی ہے، یا درست شناخت قسم اور ایسی تجویز جو ساتھی مسترد کرے۔
تبدیلی کے ریکارڈ میں تین سطریں الگ رکھیں: شناخت سند اور کلید، گیٹ وے اعتماد ان پٹ، اور تجاویز کے الگورتھم۔ انہیں ایک ہی "کرپٹو ترتیبات" نوٹ میں ملانا اگلی ناکامی کی نسبت ناممکن بنا دیتا ہے۔
جن فیلڈز کو آپ نے تشکیل دیا ان سے فیصلہ جانچیں
پروفائل واقعی جس شناخت کا حوالہ دیتا ہے اسے جانچیں، پھر تصدیق کریں کہ اس حوالہ کی سند میں متوقع عوامی کلید اور قابل استعمال نجی کلید موجود ہے۔ UI میں دکھائی گئی قسم، حوالہ شدہ سند اور ڈیوائس کی کلید، تینوں کو میل کھانا چاہیے۔
پھر گیٹ وے کے ان پٹ کی تصدیق کریں: متوقع سرور نام، اعتماد لنگر اور IKE توثیق کا طریقہ۔ آخر میں جڑیں اور دیکھیں کہ مصافحہ کہاں رکتا ہے۔ شناخت کے تبادلے سے پہلے کی ناکامی اس ترتیب سے دور اشارہ کرتی ہے؛ ساتھی کی توثیق میں ناکامی گیٹ وے کی طرف اشارہ کرتی ہے۔
منتخب قسم، شناخت حوالہ اور گیٹ وے سند کا موضوع تعیناتی نوٹس میں درج کریں۔ اگلی پروفائل تازہ کاری ان میں سے کوئی بھی بدل سکتی ہے، اور تین نامزد اقدار کا موازنہ ترتیبات پینل کے اسکرین شاٹ سے زیادہ تیزی سے کیا جا سکتا ہے۔