آپریٹنگ گائیڈ: دو OpenVPN گاہکوں کو الگ الگ شامل کرنا

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

ہر گاہک کے لیے مکمل وسائل کارڈ مختص کریں

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

کارڈ کو ترتیب کے پاس رکھیں اور جب بھی کوئی قدر بدلے اسے اپ ڈیٹ کریں۔ حقیقت سے دور ہوتی دستاویز نہ ہونے سے بھی بری ہے۔

اعتماد کا مواد ہر گاہک کے اندر رکھیں

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

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

عمل کی طرح نیٹ ورک بھی الگ کریں

دو پورٹوں پر دو عمل الگ نہ کرنے تک اب بھی ایک میزبان اور ایک روٹنگ ٹیبل مشترک رکھتے ہیں۔ ڈیزائن پر بھروسہ کرنے سے پہلے تصدیق کریں کہ کیا سن رہا ہے۔

ss -lunp | grep -E '1194|1195'
openssl verify -CAfile customer-a/ca.crt customer-a/client.pem

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

حوالگی سے پہلے منسوخی پہنچائیں

منسوخی کا ترسیلی راستہ بننے تک سرٹیفکیٹ کی تعیناتی نامکمل ہے۔ شمولیت کے حصے کے طور پر CRL کے جاری کنندہ اور اعتبار کی مدت کی جانچ کریں۔

openssl crl -in customer-a/crl.pem -noout -lastupdate -nextupdate
systemctl status openvpn@customer-a

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

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