کلائنٹ ہک یا سرور ہک؟ OpenVPN اسکرپٹ کہاں چلتی ہے

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

دو مشینیں، پہلے جواب دینے کے لیے دو سوال

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

ان دو سوالوں کا الٹی ترتیب میں جواب دینا ہی وہ راستہ ہے جس سے لوگ Windows لیپ ٹاپ پر بیچ فائل push کرنے کی کوشش کرتے ہیں۔ سرور جانتا ہے کون جڑا؛ لیپ ٹاپ جانتا ہے کہ اس کا اپنا نیٹ ورک اسٹیک کیسا دکھتا ہے۔ کسی کے پاس دوسرے کی معلومات نہیں، اور کوشش عام طور پر واضح خرابی کے بجائے خاموشی سے ناکام ہو جاتی ہے۔

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

سرور کی طرف کا انتخاب: ہر کنکشن کے لیے ایک واقعہ

client-connect اسکرپٹ سرور کے عمل کے سیاق میں چلتی ہے جب تصدیق شدہ کلائنٹ جڑتا ہے، اور اسے دستاویزی کنکشن تفصیلات ملتی ہیں جیسے common name اور تفویض کردہ پتہ۔ فی کلائنٹ کنفیگریشن کا ٹکڑا لکھنے، پالیسی فیصلہ نافذ کرنے یا سرور کی ملکیت والی حالت درج کرنے کے لیے یہی درست جگہ ہے۔

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

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

کلائنٹ کی طرف کا انتخاب: وہ کام جو مقامی طور پر چلنا ضروری ہے

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

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

نام دینا بھی اہم ہے۔ up ہک ڈیوائس بننے سے مطابقت رکھتا ہے اور route-up راستے نصب ہونے سے، لیکن جس کام کو نجی نیٹ ورک تک رسائی درکار ہو اسے یہ ماننے کے بجائے کہ ڈیوائس بننے کا مطلب ہر راستہ، resolver اندراج اور ایپلیکیشن تیار ہے، رسائی کی جانچ کرنی چاہیے۔

چلنے کے قابل کوڈ push کرنا اختیارات میں کیوں نہیں

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

مقامی طور پر اسکرپٹ چلانا فعال کرنے سے یہ نہیں بدلتا۔ آپ کی script-security ترتیب آپ کے منتخب کردہ مقامی اسکرپٹ کی اجازت دیتی ہے؛ یہ سرور کو نئی فراہم کرنے کا اختیار نہیں دیتی۔

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

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

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

جس اکاؤنٹ کے تحت یہ واقعی چلے گا اسی کے تحت، اسی لمحے جانچیں جب یہ واقعی چلے گا۔ openvpn(8) دستی دونوں ہک خاندانوں اور push حدود کی دستاویز کرتا ہے؛ آپ جس پلیٹ فارم پر تعینات کر رہے ہیں وہ دستاویز کرتا ہے کہ کیا یہ انہیں بالکل فراہم کرتا ہے۔ انٹرایکٹو ایڈمنسٹریٹر ٹرمینل میں کامیاب ہونے والی اسکرپٹ ایک مفروضہ ہے، تصدیق نہیں۔