راؤٹر پر OpenVPN کی ترتیبات ری بوٹ کے بعد واپس آ جاتی ہیں: جنریٹر ٹھیک کریں
ہر بوٹ پر اپنی OpenVPN کنفیگریشن دوبارہ بنانے والا فرم ویئر آپ کی ترامیم کو پھینک دیتا ہے۔ جنریٹر کا ہک پیچ کریں، پھر ایک ری بوٹ کے بعد بنائی گئی فائل کا موازنہ کریں۔
صارفین کے راؤٹر یا NAS پر فرم ویئر اکثر ہر آغاز پر اپنی OpenVPN کنفیگریشن دوبارہ بناتا ہے، اسی لیے آپ جو ہدایت شامل کرتے ہیں ٹھیک اگلے بوٹ تک ہی رہتی ہے۔ یہی بات ویب فارم میں لکھی گئی کلیدوں پر بھی لاگو ہوتی ہے، جہاں محفوظ شدہ قدر محفوظ کرنے کے بعد خراب ہو کر واپس آ سکتی ہے۔ ان میں سے کوئی بھی علامت یہ نہیں بتاتی کہ تبدیلی مسترد ہوئی۔ اس کا مطلب یہ ہے کہ ترمیم ایسی فائل میں پہنچی جسے فرم ویئر آؤٹ پٹ سمجھتا ہے، اور مستقل جگہ بوٹ کی ترتیب میں ایک قدم پہلے ہے۔
ترمیم شدہ فائل دوبارہ کیوں بنتی ہے
اسٹارٹ اسکرپٹ ٹیمپلیٹ سے سرور کنفیگریشن جوڑتی ہے اور پھر ڈیمون شروع کرتی ہے، جس سے پیش کردہ فائل ماخذ کے بجائے بلڈ آرٹیفیکٹ بن جاتی ہے۔ آغاز کے بعد شامل کی گئی کوئی بھی چیز اس اسکرپٹ کے اگلے رن کو نظر نہیں آتی۔ دوسرا نمونہ زیادہ باریک ہے: ویب انٹرفیس میں کلید اور سرٹیفکیٹ کے اندراجات escape شدہ شکل میں محفوظ ہوتے ہیں، اور فارم محفوظ کرنا اس escape شدہ متن کو اس فائل میں دھکیل سکتا ہے جسے ڈیمون پڑھتا ہے۔ بہرحال، پیش کردہ کنفیگریشن مستقل تبدیلی کے لیے غلط جگہ ہے۔
دیکھیں کہ بوٹ کی ترتیب کیا لکھتی ہے اور کب۔ جواب تقریباً ہمیشہ فرم ویئر کی init یا آٹو رن ڈائریکٹری میں موجود اسکرپٹ ہوتا ہے۔
ہدایت وہیں درج کریں جہاں اسکرپٹ فائل بناتی ہے
QTS آلات ڈیمون شروع کرنے والی init اسکرپٹ کے اندر OpenVPN سرور کنفیگریشن دوبارہ بناتے ہیں، اس لیے ترمیم وہیں ہونی چاہیے۔ بنائی گئی فائل میں ترمیم کرنے کے بجائے اسٹارٹ اپ کمانڈ سے عین پہلے اضافہ شامل کریں۔
sed -i '/daemon_mgr/i echo client-config-dir clientconfig >>/etc/openvpn/server.conf' /etc/init.d/vpn_openvpn.sh
grep -c client-config-dir /etc/openvpn/server.confاضافے کو ایسی کمانڈ پر لنگر انداز کریں جو ہلے گی نہیں، کیونکہ بلڈز کے درمیان سطر کے نمبر بدلتے ہیں۔ چونکہ init اسکرپٹ خود بوٹ کے دوران بدلی جاتی ہے، اس لیے ہر بار نظام شروع ہونے پر فرم ویئر کے آٹو رن ہک سے تبدیلی دوبارہ جاری کرنی ہوگی۔ ایک ری بوٹ کے بعد بنائی گئی فائل میں وقوعات گنیں: ایک سطر کا مطلب پیچ کام کر گیا، جبکہ دو کا مطلب ہک ایک سے زیادہ بار چل رہا ہے۔ دوہرے رن کی علیحدہ جانچ کریں، کیونکہ یہ غائب ہونے والی تبدیلی جیسی وہی خرابی نہیں ہے۔
ایسا فارم ٹھیک کریں جس نے escape شدہ کلیدیں محفوظ کیں
Asus طرز کے صفحات پر سرٹیفکیٹ اور کلید کے اندراجات escape شدہ متن دکھاتے ہیں، اور غیر متعلقہ ردوبدل کے بعد محفوظ کرنا ان ہستیوں کو دوبارہ ڈسک پر لکھ سکتا ہے۔ ڈی کوڈ شدہ نقل سے کام کریں اور تمام ترامیم تیار ہونے کے بعد صرف ایک بار محفوظ کریں۔
openssl dhparam -out dh2048.pem 2048
grep -n "BEGIN DH PARAMETERS" dh2048.pemنیا پیرامیٹر سیٹ بدلتے وقت، اگر لیبل کلید کا جسم مانگے تو صرف base64 پے لوڈ چسپاں کریں، اور جب فیلڈ مکمل PEM بلاک کی توقع رکھے تو صرف کوچ لائنیں رکھیں۔ پہلے سے escape شدہ شکل میں محفوظ صفحے کی بحالی عام طور پر متاثرہ اندراجات کو خالی کرکے لاگو کرنا ہوتا ہے، جس سے فرم ویئر انہیں دوبارہ بنا سکتا ہے۔ 2048 بٹ سے زیادہ کچھ بھی ورک اسٹیشن پر بنائیں، کیونکہ راؤٹر کی اینٹروپی سپلائی کام کو سست اور کبھی کبھار ناقابل بھروسہ بناتی ہے۔ پیرامیٹر فائل کو ایسی جگہ رکھیں جہاں فیکٹری ری سیٹ کے بعد بھی پہنچ سکیں۔
اپ گریڈ کے بعد دوبارہ جانچیں
فرم ویئر اپ ڈیٹس init اسکرپٹس بدلتی ہیں اور آٹو رن ڈائریکٹری مٹا سکتی ہیں، اس لیے پیچ دوبارہ انسٹال کرکے دوبارہ جانچنا ہوگا۔ دوبارہ بنائی گئی فائل کا موازنہ اپنی رکھی ہوئی نقل سے کریں اور تصدیق کریں کہ ہدایت عین ایک بار موجود ہے۔ ویب انٹرفیس میں نظر آنے والی قدر اس بات کا ثبوت نہیں کہ ڈیمون نے اسے حاصل کیا، کیونکہ صفحہ محفوظ شدہ فیلڈز پڑھتا ہے۔ پیچ کمانڈ اور فرم ویئر ورژن دیکھ بھال کے نوٹس میں لکھیں تاکہ اگلی اپ ڈیٹ انہیں آگے لے جائے۔
پھر ایک کلائنٹ منسلک کریں اور بھیجے گئے آپشن کے لیے سرور لاگ پڑھیں۔ وہ ترتیب جو کبھی صرف فارم میں موجود تھی ایسی ترتیب ہے جسے کسی نے جانچا نہیں۔