strongSwan EAP: IKE شناخت اور متوقع AAA نام

strongSwan EAP کلائنٹ دو سرور ناموں کی تصدیق کر سکتا ہے۔ remote.id IKE گیٹ وے اور local.aaa_id EAP سرور کا احاطہ کرتا ہے؛ یہ ایک ہی فیلڈ نہیں ہیں۔

IKEv2 پر EAP تصدیق کلائنٹ سے ایک ہی کنکشن میں دو مختلف سرور ناموں کی تصدیق کا مطالبہ کر سکتی ہے۔ IKE ختم کرنے والا گیٹ وے ایک شناخت پیش کرتا ہے، اور اندرونی TLS تبادلہ ختم کرنے والا EAP بیک اینڈ دوسری پیش کر سکتا ہے۔ strongSwan میں یہ الگ الگ کنفیگریشن بلاکس میں رہتے ہیں، اور غلط بلاک میں نام رکھنے سے ایسی ناکامی ہوتی ہے جو سرٹیفکیٹ کے مسئلے جیسی لگتی ہے۔ یہ پڑھنا کہ کون سی تصدیق ناکام ہوئی، ہی بتاتا ہے کہ کون سا بلاک تبدیل کرنا ہے۔

ایک کنکشن، دو سرور شناختیں

پہلی شناخت IKE تبادلے کی ہے۔ کلائنٹ ایک پتہ ڈائل کرتا ہے اور توقع کرتا ہے کہ سامنے والا فریق ایک مخصوص شناخت، عام طور پر گیٹ وے سرٹیفکیٹ میں موجود نام، ثابت کرے۔

دوسری EAP کی ہے۔ PEAP یا TTLS کے ساتھ، کلائنٹ IKE SA کے اندر تصدیق سرور تک TLS سرنگ بناتا ہے، اور وہ اندرونی سرور اپنا سرٹیفکیٹ پیش کرتا ہے۔ جب بیک اینڈ الگ ہوسٹ ہو، اس کا نام گیٹ وے کے نام سے مختلف ہوتا ہے۔ جو کلائنٹ صرف پہلا نام جانچتا ہے وہ دوسرے کے ہر دعوے کو قبول کر لیتا ہے۔ اور دونوں جگہوں پر ایک ہی نام کے ساتھ ترتیب دیا گیا کلائنٹ اسی لمحے ناکام ہوتا ہے جب وہ دونوں واقعی مختلف ہوں۔

دونوں نام آپریٹر کی کنفیگریشن سے آتے ہیں، اس سرٹیفکیٹ سے نہیں جو خرابی دور کرتا ہے۔ آپریٹر سے تعیناتی کی تفصیلات پوچھنا دو ہوسٹ نام اندازہ لگانے سے تیز ہے۔

کون سا فیلڈ کس پرت کا ہے

swanctl میں پتہ اور IKE شناخت الگ ترتیبات ہیں، اور EAP شناخت تیسری ہے۔

دور کا پتہ چنتا ہے کہ پیکٹ کہاں جائیں، اور دور کی شناخت بتاتی ہے کہ سامنے والے فریق کو کیا ثابت کرنا ہے۔ EAP توقع local بلاک کے نیچے لکھی جاتی ہے، کیونکہ یہ سامنے والے فریق کے IKE رویے کی نہیں، اس کلائنٹ کے EAP تبادلے کی وضاحت کرتی ہے۔ یہی مقام لوگ غلط پڑھتے ہیں۔ نام کلائنٹ کی کنفیگریشن میں ہے جبکہ سرور کی وضاحت کرتا ہے، اور اسی لیے یہ غلط جگہ پر لگتا ہے۔

connections {
    office {
        remote_addrs = vpn.example.com
        local {
            auth = eap-peap
            aaa_id = auth.example.com
        }
        remote {
            auth = pubkey
            id = vpn.example.com
        }
    }
}

یہ ٹکڑا مکمل کنکشن نہیں ہے؛ اعتماد کا مواد، اسناد اور چائلڈ کنکشن کی پالیسیاں اب بھی موجود ہونی چاہئیں۔ اسے لفظ بلفظ کسی فعال فائل میں نقل کرنا ان ترتیبات کو بدل دے گا جن کی آپ کو اب بھی ضرورت ہے۔

aaa_id local کے نیچے کیوں رہتا ہے

local بلاک بیان کرتا ہے کہ تصدیق کے دوران یہ سرا کیا کرتا ہے، بشمول وہ طریقہ جو استعمال کرے گا اور وہ شناخت جس کی اس طریقے کے لیے دوسرے سرے سے توقع کرتا ہے۔ اس میں کچھ بھی یہ دعویٰ نہیں کرتا کہ AAA سرور اسی مشین پر چلتا ہے۔

طے شدہ قدر جال کو مزید تیز کرتی ہے۔ جب کوئی واضح قدر مقرر نہ ہو، متوقع AAA شناخت دور کی شناخت کی پیروی کرتی ہے، اس لیے ایک نام والی تعیناتی کام کرتی ہے اور فرق چھپا دیتی ہے۔ واضح قدر صرف اسی وقت اہم ہے جب EAP تعیناتی واقعی کہیں اور ختم ہو۔ اس وجہ کے بغیر اسے دوسرے نام پر مقرر کرنا ایسی ناکامی پیدا کرتا ہے جو آپریٹر دوبارہ نہیں بنا سکتا۔ دوسرا نام ایجاد کرنے سے پہلے تعیناتی پڑھیں۔

قدر کو اسی کے برابر رکھیں جو بیک اینڈ سرٹیفکیٹ واقعی دعویٰ کرتا ہے، بشمول نام کی شکل۔ آخر میں نقطہ یا ہوسٹ کو نہ ڈھکنے والا وائلڈ کارڈ جانچ کی ناکامی کے لیے کافی ہے۔

ایسے فرنٹ اینڈ جو تقسیم بیان نہیں کر سکتے

NetworkManager پروفائل swanctl جیسا وہی کنفیگریشن انٹرفیس نہیں ہے۔ اس کے پیچھے پلگ ان شناخت کے کنٹرولز کا ایک تنگ مجموعہ فراہم کرتا ہے، اور کون سے موجود ہیں یہ نصب شدہ ورژن پر منحصر ہے۔

یہ اس وقت اہم ہے جب تعیناتی کو واقعی دو نام درکار ہوں۔ سرور شناخت کے طور پر لیبل شدہ فیلڈ ایک پرت ترتیب دے سکتا ہے اور دوسری نہیں، اس لیے پروفائل درست دکھ سکتا ہے اور پھر بھی اندرونی جانچ میں ناکام ہو سکتا ہے۔ یہ فرض کرنے سے پہلے کہ پروفائل یہ ترتیب بیان کر سکتا ہے، دیکھیں کہ نصب شدہ پلگ ان کیا معاونت کرتا ہے۔ اگر نہیں کر سکتا، تو انتخاب آپریٹر کا ہے: مختلف پروویژننگ راستہ، یا درست شدہ سرور شناخت کا ڈیزائن۔ PEAP کو کمزور کرنا یا کوئی بھی نام قبول کرنا تصدیق کی پالیسی کو ٹھیک کرنے کے بجائے بدل دیتا ہے۔

متبادل کلائنٹ پر ایجاد کرنے کی چیز نہیں ہے۔ معاون ترتیب تحریری طور پر طلب کریں، پھر وہ جواب پروفائل کے ساتھ رکھیں۔

شناخت کی عدم مطابقت کو میعاد ختم شدہ سرٹیفکیٹ سے الگ پہچانیں

نام کی عدم مطابقت اور میعاد ختم شدہ سرٹیفکیٹ الگ ناکامیاں ہیں، اور لاگ ان میں فرق کرتا ہے۔ کون سا فیلڈ بدلنا ہے یہ طے کرنے سے پہلے پیغام پڑھیں۔

swanctl --list-conns
swanctl --list-sas
journalctl -u strongswan -n 50 --no-pager

مقصود AAA شناخت مقرر کرنا سرٹیفکیٹ کی تجدید نہیں کرتا اور نہ اس کے جاری کنندہ پر اعتماد قائم کرتا ہے، اور سرٹیفکیٹ کی تجدید غلط متوقع نام کو درست نہیں کرتی۔ دوسرا شناخت فیلڈ تبدیل کرنے سے پہلے پڑھیں کہ کون سی تصدیق ناکام ہوئی۔ پھر کنفیگریشن دوبارہ لوڈ کریں اور تصدیق کریں کہ لوڈ شدہ کنکشن وہ قدر دکھاتا ہے جو آپ نے مقرر کی، کیونکہ کبھی لوڈ نہ کی گئی تبدیل شدہ فائل کچھ نہیں بدلتی۔ دونوں نام اور ان کی پرتیں تعیناتی نوٹس میں لکھیں۔

متعلقہ مضامین