مستقل OpenVPN پتے شناخت کی پیروی کریں، ماخذ IP کی نہیں

پتہ منصوبے جو کہتے ہیں 'یہ لیپ ٹاپ 10.90.0.10 حاصل کرتا ہے' درحقیقت شناخت کے بارے میں بیانات ہیں: کون سا تصدیق شدہ آلہ اس پتے کا حامل ہو سکتا ہے۔ اس آلے کا موجودہ عوامی IP اس سے تقریباً بے تعلق ہے، کیونکہ NAT اور رویمنگ اسے بدل دیتے ہیں بغیر یہ بدلے کہ صارف کون ہے۔ ماخذ پتے پر منصوبہ بنانا ایسے قواعد پیدا کرتا ہے جو پہلے ہوٹل نیٹ ورک پر ہی ٹوٹ جاتے ہیں۔ تصدیق شدہ شناخت پر اسے بنانا ایسا منصوبہ پیدا کرتا ہے جو سفر میں قائم رہتا ہے۔

وہیں سے شروع کریں جو سرور تصدیق کر سکتا ہے، پھر فیصلہ کریں کہ پتہ کس لیے ہے۔

پتے سے پہلے شناختی کلید منتخب کریں

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

duplicate-cn کے ساتھ کئی بیک وقت سیشن ایک ہی عام نام پیش کر سکتے ہیں، اس لیے ایک پن شدہ پتہ انہیں الگ الگ شناخت نہیں کر سکتا۔ یہ شناخت کے ماڈل کی خاصیت ہے، ایسی چیز نہیں جسے بہتر پتہ منصوبہ درست کر سکے۔

پتے متحرک رینج سے باہر محفوظ رکھیں

10.90.0.0/24 جیسے سب نیٹ ٹوپولوجی والے نیٹ ورک میں کم پتے نامزد ارکان کے لیے رکھیں اور متحرک پول کو الگ رینج میں رکھیں۔ پن شدہ رکن کے لیے تفویض اس فائل میں ifconfig-push 10.90.0.10 255.255.255.0 جیسی نظر آتی ہے جو سرور اس شناخت کے لیے منتخب کرتا ہے۔ دوسری دلیل net30 کے تحت کچھ اور معنی رکھتی ہے، اس لیے یہ مثال ٹوپولوجی کے لحاظ سے غیر جانبدار نہیں۔ نقل کرنے سے پہلے ٹوپولوجی پڑھیں۔

پول کی برقراری حالیہ لیز ریکارڈ کرتی ہے اور عموماً وہی پتہ واپس دیتی ہے، جو سہولت ہے تحفظ نہیں۔ برقراری فائل کو ملکیت کا ریکارڈ بننے نہ دیں، کیونکہ یہ پالیسی کے بجائے کنکشن کی تاریخ کے ساتھ بدلتی ہے۔

تفویض کی ترجیح طے کرتی ہے کہ کون جیتے گا

دستور ایک ترتیب درج کرتا ہے: client-connect کے دوران پیدا ہونے والی واضح تفویض client-config-dir اندراج سے پہلے اثر انداز ہو سکتی ہے، جو بدلے میں عام پول مختص سے پہلے آتا ہے۔ یہی ترتیب 'پن شدہ پتہ لاگو نہیں ہوا' کی زیادہ تر شکایات کی وضاحت کرتی ہے۔ اس کا مطلب یہ بھی ہے کہ فی سیشن کنفیگریشن لکھنے والا متحرک مختص کنندہ اس مستقل فائل کو خاموشی سے زیر کر سکتا ہے جسے آپ مستند سمجھتے تھے۔

تفویضات کا مالک ایک ہی پرت منتخب کریں اور باقی کو صرف پڑھنے کے لیے رکھیں۔ دو پرتیں جو دونوں فیصلہ کرنے کا دعویٰ کریں، ایسی تفویضیں پیدا کرتی ہیں جو وقت پر منحصر ہوں۔

متحرک مختص کنندہ کو بھی وہی ماڈل درکار ہے

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

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

فیصلہ کریں کہ پتہ پالیسی ہے یا سہولت

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

منصوبہ ایسی فہرست کے طور پر لکھیں جس میں ہر اندراج کا مالک ہو، پھر جب کوئی آلہ ریٹائر ہو تو اس کا جائزہ لیں۔ غیر استعمال شدہ تحفظ ہی وہ ہے جو حادثاتی طور پر دوبارہ استعمال ہوتا ہے۔