IKE شناخت یا اینڈ پوائنٹ ایڈریس: انہیں آپس میں نہ ملائیں
FQDN قسم کی IKE شناخت ایک لفظی توثیقی قدر ہے، ریورس-DNS تلاش نہیں۔ اینڈ پوائنٹ ایڈریس، مقامی شناخت اور متوقع peer کو الگ رکھیں۔
FQDN شناخت کے طور پر لیبل شدہ فیلڈ کو لفظی سٹرنگ کے طور پر پڑھیں، اپنے عوامی ایڈریس کے ریورس-DNS نام کی درخواست کے طور پر نہیں۔ strongSwan کے پارسر میں یہ بالکل یہی ہے، ایک سٹرنگ، اور اسے پڑھنا اسے کبھی اینڈ پوائنٹ میں حل نہیں کرتا۔ یہی حقیقت peer کے لیے شناخت کنندگان چنتے وقت سب سے عام توجہ ہٹانے والی بات ختم کرتی ہے۔ نیچے دیے گئے معائنے تینوں متعلقہ قدروں کو ایک میں ضم ہونے سے روکتے ہیں۔
لیبل کوئی تلاش نہیں
وینڈر انٹرفیس FQDN اور hostname جیسے الفاظ ڈھیلے طریقے سے استعمال کرتے ہیں، اور باکس پر لگا لیبل اس کے پیچھے کی انکوڈنگ کے بارے میں کچھ نہیں بتاتا۔ جو آلہ کسی فیلڈ کو Client FQDN کہتا ہے وہ FQDN، ای میل کی شکل کی سٹرنگ یا ننگا ایڈریس بھیج سکتا ہے۔ متن اور قسم کو دو الگ فیصلے سمجھیں اور دونوں درج کریں۔
لفظی شناخت میں کچھ بھی DNS کا مطالبہ نہیں کرتا۔ یہ ایک دعویٰ ہے جسے دوسرا سرا جانچتا ہے، ایسا نام نہیں جسے نیٹ ورک کو حل کرنا ہو۔
تین الگ قدریں، الگ لکھی گئیں
ایک کنفیگریشن اسکرین کے پیچھے تین کام ہیں، اور انہیں یکجا کرنا مہنگا نقصان ہے۔ ایک قدر اینڈ پوائنٹ ایڈریس ہے جو طے کرتا ہے کہ پیکٹ کہاں جائیں گے۔ دوسری وہ مقامی شناخت ہے جو یہ peer پیش کرتا ہے، اور تیسری وہ شناخت ہے جس کی آپ توثیق سے پہلے دور سرے سے توقع کرتے ہیں۔ انہیں تبدیلی ٹکٹ میں تین سطروں کے طور پر لکھیں، کیونکہ اس سے کم کچھ رشتہ نہیں، VPN بیان کرتا ہے۔
| Job | Example | What it decides |
|---|---|---|
| Where the packets go | 198.51.100.7 | The endpoint address |
| What this peer claims | gw.branch.internal | The local IKE identity |
| Who should answer | ike.hub.internal | The expected remote identity |
نمونہ شناختیں تعیناتی کے حصے کے طور پر منتخب اور مجاز کی جانی چاہئیں۔ یہ ایسے دعوے ہیں جنہیں توثیق جانچتی ہے، ایسی اسناد نہیں جو کسی بھی peer کو قابلِ اعتماد بنائیں، لہٰذا قابلِ اعتماد دکھنے والی سٹرنگ کچھ بھی مجاز نہیں کرتی۔
قسم قدر کا حصہ ہے
strongSwan شناخت حوالہ FQDN، ای میل کی شکل کی قدروں، IP ایڈریسوں اور دیگر انکوڈنگوں کو الگ کرتا ہے، اس لیے انکوڈنگ حروف جتنی اہم ہے۔ دو آلات ایک ہی متن مختلف قسموں کے تحت قبول کر کے بھی ایک دوسرے کو مسترد کر سکتے ہیں۔ قسم کے بغیر قدر درج کرنے والا نوٹ آدھی کنفیگریشن ہے۔
وینڈر سے پوچھیں کہ آلہ واقعی کون سی قسم بھیجتا ہے، اور انٹرفیس لیبل کی بجائے ڈیکوڈ سے تصدیق کریں۔ اندازہ لگائی گئی قسم اگلی تبدیلی کے انتظار میں ایک عدم مطابقت ہے۔
ہر فریق کو دوسرے کو مطمئن کرنا ہے
ہر فریق کی مقامی شناخت کو دوسرے فریق کی توثیقی پالیسی سے گزرنا ہوگا۔ یہ دونوں آلات کے ہر شناختی خانے میں ایک ہی سٹرنگ چپکانے جیسا نہیں، وہ شارٹ کٹ ایسی کنفیگریشن بناتا ہے جسے کوئی ڈیبگ نہیں کر سکتا۔
سرٹیفکیٹ سے توثیق اپنی شرائط شامل کرتی ہے، کیونکہ سرٹیفکیٹ کی شناخت اور اعتماد کی شرائط آپ کی ٹائپ کردہ IKE شناخت کے ساتھ بیٹھتی ہیں۔ صرف IKE شناخت کا میل سرٹیفکیٹ والے peer کو مجاز نہیں کرتا۔
DNS کہاں اہم ہے، اور آپ کا ورژن کیا لازمی کرتا ہے
دریافت کے لیے استعمال ہونے والا گیٹ وے hostname واقعی کام کرنے والا DNS مانگتا ہے، اور یہ شرط اینڈ پوائنٹ ڈھونڈنے کی ہے، ٹائپ کردہ شناخت کی کسی ریورس تلاش کی نہیں۔ ٹکٹ میں دونوں کو الگ رکھیں، کیونکہ دریافت کی ناکامی اور شناخت کی عدم مطابقت کلائنٹ لاگ میں یکساں پڑھی جاتی ہیں اور مختلف جگہوں پر ٹھیک ہوتی ہیں۔
قسم کو لازمی کرنے والا نحو نقل کرنے سے پہلے اس پروڈکٹ اور ورژن کا پارسر پڑھیں جو آپ واقعی چلاتے ہیں، کیونکہ پرانے strongSwan ورژن مختلف برتاؤ کرتے تھے اور دیگر وینڈر اپنی قیودیں شامل کرتے ہیں۔ جب آپ دونوں سروں کا موازنہ کریں تو چار چیزیں ساتھ رکھیں: متوقع شناخت، پیش کردہ شناخت، قسم اور توثیق کی غلطی۔ یہ مجموعہ عدم مطابقت کو رائے کے بجائے ثبوت بناتا ہے۔