OpenVPN client-connect ہک: آپ کا پتہ دراصل کہاں جاتا ہے

client-connect اسکرپٹ سے پتہ واپس دینا ایسا لگتا ہے کہ اسے کلائنٹ کا IP سیٹ کرنا چاہیے۔ لیکن ایسا نہیں ہوتا: ہک کا سرور تک واحد راستہ ایک عارضی فائل ہے جس کا راستہ اسکرپٹ کی آخری دلیل کے طور پر آتا ہے، اور پتہ وہاں ifconfig-push نحو میں لکھا جانا چاہیے۔ جو اسکرپٹ پتہ پرنٹ کرتی ہے یا کچھ لکھے بغیر صفر کے ساتھ باہر نکلتی ہے، وہ پول سے ملے پتے والا منسلک کلائنٹ بناتی ہے، اور سرور لاگ بالکل صحت مند دکھائی دیتا ہے۔

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

ہک فائل لکھتا ہے، واپسی قدر نہیں

اعلان دو سطروں کا ہے: کال کی اجازت کے لیے script-security 2، پھر client-connect /etc/openvpn/server/assign-address.sh۔ جب کلائنٹ تصدیق کرتا ہے تو سرور وہ اسکرپٹ بنائی گئی فائل کا راستہ آخری دلیل کے طور پر شامل کر کے چلاتا ہے، جو $1 صرف اس وقت ہوتا ہے جب اعلان اپنی کوئی اضافی دلیل نہ بھیجے۔ اس کلائنٹ پر لاگو ہونے والی ہر چیز اس فائل میں عام ہدایات کے طور پر، ہر سطر میں ایک، بالکل ویسے ہی لکھی جاتی ہے جیسے وہ ترتیب میں دکھائی دیتی ہیں۔ اپنے پیرامیٹر شامل کرنے والا ریپر مقام کو ہٹا دیتا ہے، اور کلاسیک علامت وہ اسکرپٹ ہے جو --verbose جیسے دکھنے والے راستے پر لکھتی ہے۔

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

دو ہدایات توجہ کے قابل ہیں کیونکہ وہ باقی سب کے ساتھ تعامل کرتی ہیں۔ ifconfig-push پتہ مقرر کرتا ہے، جبکہ بھیجا گیا route کلائنٹ کو بتاتا ہے کہ سرنگ کے ذریعے کیا قابل رسائی ہے؛ پہلا واپس کریں اور دوسرا بھول جائیں تو آپ کو پتہ تو ہے مگر جانے کی جگہ نہیں والا کلائنٹ ملتا ہے۔ فائل کے اندر ترتیب اہم نہیں، مگر مکمل ہونا اہم ہے۔ جو ہک ایسے سابقے کے لیے راستہ بھیجتا ہے جہاں کوئی ہم منصب نہیں پہنچ سکتا، وہ دوسرے سرے سے دیکھی گئی وہی غلطی ہے۔

ان پٹ ماحولیاتی متغیرات کے ذریعے آتا ہے: common_name، trusted_ip، ifconfig_pool_remote_ip اور باقی۔ ان سب کو سرور سے باہر کی تاروں کے طور پر سمجھیں، کبھی شیل کے ٹکڑوں کے طور پر نہیں۔

پتوں کی نقشہ بندی ایک پالیسی ہے، ریاضی نہیں

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

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

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

ٹوپولوجی طے کرتی ہے کہ ifconfig-push کا کیا مطلب ہے

10.77.0.0/24 پر topology subnet کے ساتھ، ifconfig-push 10.77.0.20 255.255.255.0 ایک پتہ اور اس کا نیٹ ماسک ہے۔ topology net30 کے تحت دوسری دلیل نیٹ ماسک نہیں بلکہ ہم منصب کا پتہ ہے، اس لیے سب نیٹ کی شکل net30 سرور پر کاپی کرنے سے آپ کو ایسا کلائنٹ ملتا ہے جو جڑتا ہے مگر ٹریفک منتقل نہیں کر سکتا۔ ٹوپولوجی جان بوجھ کر بدلیں، کبھی اس لیے نہیں کہ مثال ہم آہنگ دکھے۔ جو سرور پہلے سے net30 چلا رہا ہے اس کے پرانے پتہ بندی پر زندہ کلائنٹ ہیں، اس لیے تبدیلی دیکھ بھال کی کھڑکی والی منتقلی ہے، ایک سطر کی ترمیم نہیں۔

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

اس پر بھروسہ کرنے سے پہلے چار صورتیں آزمائیں

وہی جانچیں نقشہ شدہ شناخت، بغیر نقشہ شناخت، دوبارہ کنکشن اور نقلی رجسٹری ناکامی پر چلائیں۔ openvpn --config client.ovpn --verb 4 مختص کیا گیا پتہ پش جواب میں دکھاتا ہے، اور سرور پر grep -A2 PUSH_REPLY /var/log/openvpn/openvpn.log تصدیق کرتا ہے کہ واقعی کیا بھیجا گیا۔ بغیر نقشہ شناخت کے لیے متوقع نتیجہ مسترد شدہ کنکشن ہے، پول کا پتہ نہیں۔

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

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