OpenVPN username-as-common-name: آپ کی CN جانچ خالی کیوں ہے
common_name کا username سے موازنہ کرنے والی client-connect اسکرپٹ نام کا خود سے موازنہ کر سکتی ہے۔ تبدیلی چلنے سے پہلے سند کو اکاؤنٹ سے باندھیں۔
آپ client-connect اسکرپٹ شامل کرتے ہیں جو ہر اس کنکشن کو مسترد کرتی ہے جہاں common_name username سے مختلف ہو، اور یہ سند اور اکاؤنٹ کے درمیان بندھن جیسا لگتا ہے۔ username-as-common-name چلانے والے سرور پر اسکرپٹ چلنے تک وہ موازنہ اپنا مطلب کھو چکا ہوتا ہے۔ دونوں قدریں ایک ہی سٹرنگ ہیں، اس لیے امتحان بالکل کسی اور کو جاری کردہ سند کے لیے بھی پاس ہوتا ہے۔
جانچ اس لیے غلط نہیں کہ اسکرپٹ بری طرح لکھی گئی ہے۔ یہ اس لیے غلط ہے کہ جو قدر وہ پڑھتی ہے وہ اسی کنکشن میں پہلے بدل دی گئی تھی۔
موازنہ کیا ثابت کرتا دکھتا ہے
سند کی تصدیق اور پاس ورڈ کی تصدیق الگ الگ ثبوت ہیں، اور سرور دونوں کا مطالبہ کر سکتا ہے بغیر یہ مطالبہ کیے کہ وہ ایک ہی شخص کے ہوں۔ یہ خلا حقیقی ہے: ایک درست ڈیوائس سند اور کوئی بھی درست اکاؤنٹ مل کر اسی سند اور ایک نامزد اکاؤنٹ سے مختلف دعویٰ ہے۔ common_name کا username سے موازنہ کرنے والی اسکرپٹ دونوں کے درمیان گمشدہ کڑی کی طرح پڑھی جاتی ہے۔ یہ ایسی ہوتی، اگر common_name اب بھی وہی معنی رکھتا جو سند نے کہا تھا۔
ایسا ہے یا نہیں یہ ایک سرور آپشن پر منحصر ہے، اور وہ آپشن عام طور پر کسی غیر متعلق وجہ سے آن کیا جاتا ہے، جیسے ہر صارف کے کنفیگریشن فائلوں کے نام رکھنا آسان بنانا۔
username-as-common-name نام کے ساتھ کیا کرتا ہے
جب username-as-common-name فعال ہو، OpenVPN صارف نام اور پاس ورڈ کی تصدیق کے بعد سند کے عام نام کی جگہ تصدیق شدہ صارف نام رکھ دیتا ہے۔ اس جانچ کے دوران چلنے والا تصدیقی ہک اب بھی سند کا عام نام وصول کرتا ہے، کیونکہ تبدیلی ابھی نہیں ہوئی۔ اس کے بعد کا سب کچھ، client-connect سمیت، صارف نام دیکھتا ہے۔ اس لیے بعد والا کال بیک ایک ہی شناخت دو بار وصول کرتا ہے اور پیش کردہ سند سے اس کا موازنہ نہیں کر سکتا۔
| Stage | What common_name holds |
|---|---|
| Username and password verification hook | The certificate common name, for example bob-device |
| After the replacement | The authenticated account, alice |
| client-connect callback | The account again, alice |
ایک مثال کنکشن دیکھیں: bob-device کے لیے جاری سند، alice کے طور پر کامیاب ڈائریکٹری لاگ ان، اور آپشن فعال۔ تصدیقی مرحلہ اب بھی دو مختلف سٹرنگیں دیکھ سکتا ہے۔ کنکشن مرحلہ alice اور alice دیکھتا ہے۔
یہ مثال دکھاتی ہے کہ موازنہ خالی کیوں ہے۔ یہ نہیں دکھاتی کہ کنکشن بصورت دیگر قبول ہو جاتا، کیونکہ سند کی توثیق اور پاس ورڈ کی تصدیق اب بھی خود چلتی ہیں۔
بندھن وہاں رکھیں جہاں دونوں شناختیں اب بھی موجود ہیں
قاعدہ ایسے مرحلے پر نافذ ہونا چاہیے جو سند کی شناخت اور اکاؤنٹ کو بیک وقت دیکھے، جس کا عملی مطلب صارف نام اور پاس ورڈ کی تصدیق کا ہک یا وہاں لوڈ کردہ پلگ ان ہے۔ پہلے سے پاس ورڈ کی تصدیق کرنے والا معاون پلگ ان عام طور پر جوڑی کا قاعدہ شامل کرنے کی درست جگہ ہے، کیونکہ اسے نام کے موازنہ سے بدلنے پر پاس ورڈ کی جانچ بالکل ختم ہو جائے گی۔
کوڈ لکھنے سے پہلے نقشہ بندی متعین کریں، کیونکہ برابری شاذ و نادر ہی اصل پالیسی ہوتی ہے۔ سند اکثر ڈیوائس کی شناخت کرتی ہے جبکہ لاگ ان شخص کی، اور ایک ڈیوائس قانونی طور پر کئی لوگوں کی خدمت کر سکتا ہے۔ تعلق کو ایسی شکل میں محفوظ کریں جس کا اجرا آپ کے کنٹرول میں ہو، اور فیصلہ کریں کہ نام بدلنے، دوبارہ جاری کرنے اور ڈومین کے ساتھ قابل ناموں میں کیا ہوتا ہے۔ ڈائریکٹری کو سمجھے بغیر چھوٹے حروف میں بدلنا یا ڈومین سابقہ ہٹانا دو ایسے اکاؤنٹس کو جوڑ سکتا ہے جو الگ رہنے چاہیے تھے۔
یاد رکھیں کہ آپشن یہ بھی بدلتا ہے کہ کون سی فی کلائنٹ کنفیگریشن لاگو ہوتی ہے، کیونکہ client-config-dir عام نام سے وابستہ ہے۔
دو درست اسناد کے ساتھ جوڑی کی جانچ کریں
اس جوڑی سے شروع کریں جس کی آپ کی پالیسی اجازت دیتی ہے اور تصدیق کریں کہ یہ جڑتی ہے۔ پھر وہی درست سند کسی دوسرے مگر بصورت دیگر درست اکاؤنٹ کے ساتھ پیش کریں: وہ کوشش ناکام ہونی چاہیے، اور یہ غلط ٹائپ شدہ پاس ورڈ کی وجہ سے نہیں بلکہ جوڑی کے قاعدے کی وجہ سے ناکام ہونی چاہیے۔ غلط پاس ورڈ ثابت کرتا ہے کہ پاس ورڈ کی جانچ کام کرتی ہے اور سند اور اکاؤنٹ کے درمیان قاعدے کے بارے میں کچھ نہیں کہتا۔
غائب سند اور غلط سند کے راستے بھی جانچیں، اور تصدیق کریں کہ سرور فی کلائنٹ ترتیبات کے لیے کون سی شناخت استعمال کرتا ہے۔ اگر موازنہ چلانے کا واحد طریقہ username-as-common-name بند کرنا ہے، تو پہلے اس تبدیلی کی قیمت کا اندازہ لگائیں، کیونکہ یہ ہر کلائنٹ کی کنفیگریشن تلاش کو سند کے نام پر واپس لے جاتا ہے۔