مقررہ VPN IP: RADIUS Framed-IP-Address یا پول میں مختص کردہ پتہ

VPN کلائنٹ کے لیے مستقل اندرونی پتہ تین جگہوں پر رکھا جا سکتا ہے، اور ان میں سے صرف ایک ہی اس کا مالک ہونا چاہیے۔ RADIUS پتہ Access-Accept میں واپس دے سکتا ہے، گیٹ وے اکاؤنٹ کے لیے مستقل میپنگ رکھ سکتا ہے، اور کلائنٹ اڈاپٹر ہاتھ سے ترتیب دیا جا سکتا ہے۔ پہلے دو پالیسی ہیں اور تیسرا مقامی اندازہ ہے جسے گیٹ وے نظر انداز یا اوپر لکھنے کے لیے آزاد ہے۔ پہلے دو میں سے انتخاب ہی اصل فیصلہ ہے، اور یہ اس پر منحصر ہے کہ نیٹ ورک رسائی سرور واقعی کیا نافذ کرتا ہے۔

تین جگہیں جہاں مستقل پتہ ہو سکتا ہے

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

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

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

RADIUS کا جواب کیا وعدہ کر سکتا ہے اور کیا نہیں

RFC 2865Framed-IP-Address کو اس IPv4 پتے کے طور پر بیان کرتا ہے جو صارف کے لیے ترتیب دینا ہے، اور یہ Access-Accept میں آتا ہے۔ Access-Request میں وہی خصوصیت صرف ایک اشارہ ہے جسے سرور نظر انداز کر سکتا ہے، اور یہ اس وقت اہم ہے جب کلائنٹ یا گیٹ وے کوئی پسندیدہ پتہ پیش کرے۔ پروٹوکول میں کوئی چیز گیٹ وے کو جواب کی تعظیم پر مجبور نہیں کرتی، کیونکہ نیٹ ورک رسائی سرور ہی وہ جزو ہے جو اسے سیشن پر لاگو کرتا ہے۔

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

گیٹ وے جس جواب کو نظر انداز کرتا ہے وہ بالکل ایسا ہی دکھتا ہے جیسا کبھی نہ بھیجا گیا جواب۔ Access-Accept اور سیشن کے پتے کو ساتھ ساتھ پڑھنا ہی دونوں صورتوں کو الگ کرنے کا واحد طریقہ ہے۔

پتہ اسی پول کے اندر مخصوص کریں جسے آپ پہلے ہی روٹ کرتے ہیں

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

فیصلہ کریں کہ دوسرے ہم وقت سیشن کو کیا کرنا چاہیے۔ ایک پتہ دو بار تفویض کرنا آلہ انتظام نہیں ہے، اور اس سے پیدا ہونے والا تصادم دونوں سیشنز کے لیے رک رک کر کنیکٹیویٹی کے طور پر ظاہر ہوتا ہے۔ یا تو ہر آلے کے لیے الگ شناخت جاری کریں، یا الگ تفویضات، یا کسی معاون جانچ کے ساتھ ہم وقتی نافذ کریں، مثلاً Simultaneous-Use، اس امید کے بجائے کہ کلائنٹ پرانے سیشن کی معیاد ختم ہونے سے پہلے کبھی دوبارہ نہیں جڑے گا۔

واپسی راستے تفویض جتنی ہی توجہ کے مستحق ہیں۔ گیٹ وے کو پول تک راستہ درکار ہے، اندرونی راؤٹرز کو گیٹ وے تک واپسی راستہ درکار ہے، اور مستقل پتہ دونوں ورثے میں پاتا ہے۔ ایک کلائنٹ کا کام کرنا جبکہ باقی سب ناکام ہوں عام طور پر یہ معنی رکھتا ہے کہ پول کا راستہ موجود ہے مگر مخصوص پتے کے لیے ہوسٹ راستہ نہیں۔

ریزرویشن پر بھروسا کرنے سے پہلے جواب جانچیں

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

Authenticated member: survey-tablet-17
Reply attribute:      Framed-IP-Address = 172.28.4.77

survey-tablet-17  Cleartext-Password := "REPLACE_ME"
                  Framed-IP-Address = 172.28.4.77

radtest survey-tablet-17 REPLACE_ME 127.0.0.1 0 testing123

خصوصیت کے بغیر Access-Accept کا مطلب ہے کہ سرور نے اندراج سے میل نہیں کھایا یا وہ خصوصیت اس صارف پر لاگو نہیں ہوئی۔ خصوصیت کے ساتھ Access-Accept اور ایسا کلائنٹ جو اب بھی پول کا پتہ لے رہا ہے، کا مطلب ہے کہ گیٹ وے نے اسے نظر انداز کیا۔ Access-Reject آپ کو اسناد یا گروپ پالیسی کی طرف واپس بھیجتا ہے، اور ان میں سے کسی نتیجے کو کلائنٹ اڈاپٹر میں ترمیم کر کے ڈی بگ نہیں کرنا چاہیے۔

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

ایک مالک منتخب کریں اور اسے لکھیں

اگر گیٹ وے فریم شدہ پتے قابلِ اعتماد طریقے سے لاگو کرتا ہے تو تفویض کا مالک RADIUS کو رہنے دیں اور اسی اکاؤنٹ کے لیے کوئی بھی مستقل میپنگ ہٹا دیں۔ اگر نہیں، تو گیٹ وے کو اس کا مالک رہنے دیں اور جواب سے خصوصیت ہٹا دیں، تاکہ دونوں ذرائع اختلاف نہ کر سکیں۔ دونوں کو اس لیے رکھنا کہ ہر ایک تقریباً کام کرتا ہے، مستقبل کے سیشن کو غلط پتے کے ساتھ اور بغیر واضح وجہ کے یقینی بنا دیتا ہے۔

منتخب مالک، مخصوص پتہ اور وہ پول جس سے یہ آیا، اکاؤنٹ ریکارڈ میں لکھیں۔ اگلا شخص جو آلہ شامل کرے گا وہ دونوں میں سے کوئی بھی بدلنے سے پہلے دیکھ سکے گا کہ پتہ AAA پالیسی ہے یا گیٹ وے میپنگ۔