OpenVPN کی اسناد کی فائل یا مینجمنٹ ساکٹ: کسے اسکرپٹ کریں

جو اسکرپٹ OpenVPN شروع کرتا ہے اور کبھی جڑتا نہیں وہ عام طور پر نیٹ ورک کا مسئلہ نہیں ہوتا: کلائنٹ ایک پرامپٹ پر بیٹھا ہوتا ہے جسے بنانے کے لیے کوئی ٹرمینل نہیں۔ OpenVPN کے پاس انسان کے بغیر اس پرامپٹ کا جواب دینے کے ٹھیک دو معاون طریقے ہیں، auth-user-pass کے پیچھے اسناد کی فائل اور مینجمنٹ ساکٹ، اور یہ ایک دوسرے کی جگہ نہیں لے سکتے۔ فائل ایک ہدایت کا خرچ کرتی ہے اور ایک پرامپٹ کا جواب دیتی ہے؛ ساکٹ ہر پرامپٹ کا جواب دیتا ہے اور loopback پورٹ کھول سکنے والی ہر چیز کو بغیر تصدیق شدہ کنٹرول چینل دیتا ہے۔ آپ کی تعیناتی میں کون سا آتا ہے یہ اس بات پر منحصر ہے کہ واقعی کون سا پرامپٹ روک رہا ہے، اور کون سا راز آپ سکون سے چھوڑ سکتے ہیں۔

میکانزم چننے سے پہلے پرامپٹ کا نام رکھیں

چار پرامپٹ ٹرمینل پر ایک جیسے دکھتے ہیں۔ اکاؤنٹ کا جوڑا سرور کی PAM یا auth-user-pass-verify ترتیب سے آتا ہے اور اس کا جواب auth-user-pass دیتا ہے۔ نجی کلید کا پاس فریز کلید کی فائل سے تعلق رکھتا ہے اور --askpass سے پڑھا جاتا ہے یا ہاتھ سے ٹائپ ہوتا ہے۔ PKCS#12 بنڈل اپنا پاس ورڈ مانگتا ہے۔ پراکسی توثیق اکاؤنٹ کی اسناد نہیں، --http-proxy کی لی گئی auth فائل استعمال کرتی ہے۔

جب OpenVPN systemd، PHP یا Node کے بچے کے طور پر چلتا ہے تو کوئی ٹرمینل نہیں ہوتا، اس لیے ان میں سے کوئی بھی خاموشی سے روکتا ہے۔ عمل وہیں بیٹھا رہتا ہے، سائفر لائن کے بعد لاگ رک جاتا ہے اور یونٹ آخر میں وقت سے گزر جاتا ہے؛ یہی خاموشی سبب ہے کہ لوگ یہ دیکھنے کے بجائے کہ کون سا پرامپٹ زیر التوا ہے، دوبارہ کوشش کا لوپ یا sleep شامل کر دیتے ہیں۔ چاروں کا جواب صرف مینجمنٹ ساکٹ دے سکتا ہے۔ اسناد کی فائل پہلے کا جواب دیتی ہے اور کسی اور کا نہیں۔

auth-user-pass: ایک فائل، ایک پرامپٹ

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

دو تفصیلیں صحیح فائل کو پرامپٹ بنا دیتی ہیں۔ CRLF محفوظ کرنے والا ایڈیٹر پاس ورڈ سے چپکا ہوا کیرج ریٹرن چھوڑ دیتا ہے، اس لیے سرور ایسا پاس ورڈ مسترد کرتا ہے جو فائل میں صحیح دکھتا ہے؛ آنکھ سے نہیں، cat -A یا od -c سے جانچیں۔ اور پروفائل کے اندر بغیر دلیل والا auth-user-pass ڈیزائن کے مطابق «صارف سے پوچھو» کا مطلب دیتا ہے، جسے کمانڈ لائن پر دوسری ہدایت شاید اوور رائی نہ کر سکے، کیونکہ پروفائل وہیں تجزیہ ہوتا ہے جہاں وہ ہے۔

اختیارات کی ترتیب تیسرا جال ہے، اور یہ ورژن پر منحصر ہے۔ کچھ OpenVPN 2.4 بلڈز --config سے پہلے آنے پر --auth-user-pass کو نظر انداز کرتے ہیں، اس لیے وہی دو اختیارات الٹی ترتیب میں جڑتے ہیں۔ ہدایت کو پروفائل کے اندر یا کمانڈ لائن پر --config کے بعد رکھیں، اور کچھ اور بدلنے سے پہلے پروفائل میں ہر واقعہ کو grep کریں۔

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

مینجمنٹ ساکٹ: ہر پرامپٹ، زیادہ سطح

کلائنٹ کو سننے والے کے ساتھ شروع کریں اور واضح طور پر اعلان کریں کہ پرامپٹ اس پر رپورٹ ہوں گے، OpenVPN 2.6 کے دستی میں دستاویزی ہدایات استعمال کرتے ہوئے:

management 127.0.0.1 3030
management-query-passwords

bash سے کنکشن کو ایک اضافی فائل ڈسکرپٹر پر رکھیں اور مقام کے بجائے پرامپٹ کے نام سے جواب دیں، کیونکہ دوبارہ جڑنا کسی اور ترتیب میں پوچھ سکتا ہے:

exec 3<>/dev/tcp/127.0.0.1/3030
while read -r -u 3 line; do
  case "$line" in
    *"Need 'Auth' username/password"*)
      echo 'username "Auth" alice' >&3
      echo 'password "Auth" secret' >&3 ;;
    *"Need 'Private Key' password"*)
      echo 'password "Private Key" secret' >&3 ;;
  esac
done

حد نقل و حمل ہے۔ مینجمنٹ پروٹوکول loopback پر TCP کے اوپر سادہ متن ہے، اس لیے سننے والے کو LAN یا سرنگ کے پتے پر شائع نہیں کرنا چاہیے تاکہ دور کا کنٹرولر اس تک پہنچ سکے؛ دور کا کنٹرولر SSH فارورڈنگ ہے، وسیع بائنڈ نہیں۔ کمیونٹی ڈیمن بھی ایک وقت میں صرف ایک مینجمنٹ کلائنٹ قبول کرتا ہے، اس لیے GUI یا مانیٹر آپ کی اسکرپٹ کے ساتھ ساکٹ شریک نہیں کر سکتے۔ دوسرا کنکشن قطار میں رکھے بغیر مسترد ہوتا ہے، اور ناکامی بہرے ہو چکے اسکرپٹ جیسی لگتی ہے۔

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

تعیناتی کے لیے کون موزوں ہے

اسناد کی فائل چنیں جب واحد پرامپٹ اکاؤنٹ کا جوڑا ہو، کلائنٹ مستحکم مالک کے ساتھ سروس کے طور پر چلے، اور آپ 600 فائل کو ایسے بیک اپ سے باہر رکھ سکیں جنہیں آپ کنٹرول نہیں کرتے۔ مینجمنٹ ساکٹ چنیں جب کلید کا پاس فریز یا PKCS#12 پاس ورڈ شامل ہو، جب ریپر پہلے سے عمل کی نگرانی کر رہا ہو، یا جب دوبارہ جڑنے کو ڈیبگ کرتے ہوئے حالت اور پرامپٹ دیکھنے ہوں۔

دو شرطیں فیصلہ بدلتی ہیں۔ اگر ریپر /bin/sh ہو، بائنری کو سیدھا بلانے والا systemd یونٹ ہو، یا کم سے کم کنٹینر ہو، تو صرف-bash ساکٹ گوند دستیاب نہیں اور فائل سستا جواب ہے۔ اگر راز اکثر گھومتا ہو، کوئی بھی فائل اس کے لیے اچھا گھر نہیں: چھوٹے ریپر سے کلید کی انگوٹھی پوچھیں اور یونٹ کو ریپر بلانے دیں، جو گردش ایک جگہ رکھتا ہے اور پاس ورڈ کو شیل کی تاریخ سے باہر۔

عمل کی جگہ لینا دونوں کے درمیان ہے اور کسی کا نہیں۔ نیچے کی ایک سطر کام کرتی ہے کیونکہ bash اسے openvpn شروع ہونے سے پہلے پھیلاتا ہے، اس لیے نہیں کہ کلائنٹ نحو سمجھتا ہے:

openvpn --config client.ovpn --auth-user-pass <(printf "%s
%s
" "$USER" "$PASS")

یہ /bin/sh کے تحت، شیل کو بائی پاس کرنے والے یونٹ میں، اور bash یا /dev/fd کے بغیر امیجز میں ٹوٹ جاتی ہے۔ اسے انٹرایکٹو جانچ کے لیے رکھیں، کبھی اس معاہدے کے طور پر نہیں جس پر سروس منحصر ہے۔

راز کی حفاظت کریں، پھر لاگ سے تصدیق کریں

دونوں میکانزم OpenVPN عمل کے لیے پڑھنے کے قابل راز چھوڑتے ہیں۔ پاس ورڈ کبھی کمانڈ لائن پر یا یونٹ فائل میں نہ رکھیں، جہاں ps اور systemctl اسے ہر مقامی صارف کو دکھاتے ہیں؛ فائل کا راستہ دیں، اندر کی قدر نہیں۔ جہاں سرٹیفکیٹ اکاؤنٹ کا جوڑا بدل سکتے ہیں، وہاں یہ پرامپٹ کی قسم کو چھپانے کے بجائے ہٹا دیتا ہے۔

صحیح چلنا پرامپٹ کی ترتیب مکمل ہونا اور سیشن کا «Initialization Sequence Completed» تک پہنچنا دکھاتا ہے۔ اگر کلائنٹ اسی پرامپٹ پر رک جائے تو ملاپ ناکام ہوا: ساکٹ کی بھیجی ہوئی عین سطریں چھاپیں، اقتباسات اور پرامپٹ کا نام جانچیں، اور sleep شامل کرنے کے بجائے نمونہ درست کریں۔ جو سرنگ کامیابی بتاتی ہے اور کچھ نہیں ڈھوتی وہ روٹنگ یا push کا مسئلہ ہے، اسناد کا نہیں۔

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