duplicate-cn دو آلات کو ایک شناخت دیتا ہے، دو نہیں

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

افسانہ: دوسرا سیشن دوسری شناخت ہے

مفروضہ یہ ہے کہ دو کنکشن دو کلائنٹ ہونے چاہئیں، اور دو کلائنٹ اپنے حقوق والے دو آلات ہونے چاہئیں۔ سرور اسے ایسے ماڈل نہیں کرتا۔ وہ ایک مشترکہ نام دیکھتا ہے، اور duplicate-cn فعال ہونے پر اس نام کے حامل ایک سے زیادہ زندہ سیشن قبول کرتا ہے، اور ہر ایک کو ڈیمن میں اپنی سیشن حالت ملتی ہے۔

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

جب تک سب کچھ چلتا ہے یہ فرق نظر نہیں آتا۔ جس لمحے آپ کو دونوں آلات میں تمیز کرنی پڑے یہ بہت نمایاں ہو جاتا ہے — اور عام طور پر وہی دن ہوتا ہے جب ان میں سے ایک گم ہو جاتا ہے۔

جب دو سیشن ایک نام بانٹتے ہیں تو واقعی کیا بدلتا ہے

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

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

اس پر ڈیزائن کرنے سے پہلے تصدیق کریں کہ آپ کا بلڈ واقعی کیا کرتا ہے، کیونکہ اختیار کا اثر خود اختیار طے کرتا ہے، لوک کہانیاں نہیں:

grep -n 'duplicate-cn\|client-config-dir\|username-as-common-name' /etc/openvpn/server.conf

وہ مقررہ پتہ جو آپ نے مختص کیا سمجھا تھا

فی کلائنٹ ترتیب نام سے تلاش کی جاتی ہے، اور یہیں جال ہے۔ مشترکہ نام پر نام رکھی client-config-dir فائل اس نام کو استعمال کرنے والے ہر آلے پر لاگو ہوتی ہے، اس لیے اس کے اندر کا ifconfig-push دونوں آلات کو ایک ہی ٹنل پتہ دیتا ہے۔ دوسرا سیشن یا تو قائم نہیں ہوتا، یا روٹنگ خرابی جیسا دکھنے والے انداز میں ٹکراتا ہے۔

متحرک پول اتفاق سے بہتر برتاؤ کرتا ہے، کیونکہ ہر سیشن کو پول سے آزادانہ طور پر پتہ دیا جاتا ہے۔ یہ پھر بھی آپ کو فی آلہ مستحکم پتہ نہیں دیتا، اور اس پتے سے بندھی فی آلہ پالیسی تو قطعی نہیں دیتا۔

اگر تعیناتی username-as-common-name استعمال کرتی ہے تو تلاش کی کلید سرٹیفکیٹ کے موضوع کی بجائے تصدیق شدہ صارف نام بن جاتی ہے، اور دو بار لاگ ان کرنے والے ہر شخص کو وہی ٹکراؤ پیش آتا ہے۔ ترتیب چلانے والا نام فی آلہ منفرد ہونا چاہیے، تبھی فی آلہ ترتیب کا کوئی مطلب ہے۔

ہٹانے کے وقت مشترکہ شناخت کیا نہیں کر سکتی

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

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

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

اشتراک کب درست ہے، اور اسے کیسے محدود کریں

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

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

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