ٹوکن کوڈ کا انتظار کرنے والے VPN لاگ اِن کو خودکار کیسے بنائیں
ٹرمینل میں پوچھنے والا CLI VPN کلائنٹ ایسی اسکرپٹ کو روک دیتا ہے جو صرف پاس ورڈ پائپ کرتی ہے۔ expect کی طرف جانے سے پہلے یہ پانچ جانچیں مکمل کریں۔
وینڈر کے VPN کلائنٹ کو شروع کرنے والی اسکرپٹ وقت ختم ہونے تک لٹکتی رہتی ہے، اور لاگ بتاتا ہے کہ کلائنٹ ایسا تصدیقی کوڈ مانگ رہا ہے جو کسی نے ٹائپ نہیں کیا۔ پاس ورڈ دیا جا چکا تھا، اس لیے ظاہر نتیجہ یہ ہے کہ پاس ورڈ غلط ہے۔ ایسا نہیں ہے۔ کوڈ کی درخواست الگ چینل پر الگ گفتگو ہے، اور آپ کی اسکرپٹ نے اسے کبھی نہیں کھولا۔
نیچے دی گئی پانچ جانچیں ترتیب سے کریں۔ پہلی ناکام جانچ پر رکیں، کیونکہ ہر اگلا قدم پچھلے کے درست ہونے کو فرض کرتا ہے۔
جانچ 1: کیا کلائنٹ معیاری اِن پٹ پڑھتا ہے؟
کوئی بھی خودکاری لکھنے سے پہلے آزمائیں: پائپ کے ذریعے کلائنٹ کو جعلی راز بھیجیں اور دیکھیں کیا ہوتا ہے۔ اگر وہ اپنی درخواست چھاپ کر پھر انتظار کرے، تو وہ پائپ نہیں پڑھ رہا۔
بہت سے کلائنٹ ٹرمینل ڈیوائس سیدھا کھولتے ہیں، یا غیر ٹرمینل اسٹریم سے راز لینے سے انکار کرتے ہیں، تاکہ بھٹکی ہوئی پائپ پاس ورڈ لیک نہ کر سکے۔ OpenVPN دستاویزی استثنا ہے، کیونکہ --auth-user-pass فائل کا راستہ لیتا ہے۔ ایک بار کے کوڈ مانگنے والے وینڈر کلائنٹس میں عام طور پر مساوی اختیار نہیں ہوتا، اور ان کی درخواست ایسے ٹرمینل کا انتظار کرتی ہے جو آپ کی اسکرپٹ نے کبھی فراہم نہیں کیا۔
جانچ 2: کیا چائلڈ پروسیس کے پاس ٹرمینل ہے؟
pty چائلڈ کو ٹرمینل مختص کرتا ہے، جو درخواستوں کو پڑھنے کے قابل آؤٹ پٹ میں بدل دیتا ہے جس کا جواب آپ ترتیب سے دے سکتے ہیں۔
import pexpect
child = pexpect.spawn("openconnect vpn.example.net", encoding="utf-8", timeout=30)
child.expect("GROUP:")
child.sendline("staff")
child.expect("USERNAME:")
child.sendline("alice")
child.expect("PASSWORD:")
child.sendline(PASSWORD)
child.expect("Connected as", timeout=60)اوپر دیے گئے درخواست کے رشتے مثالیں ہیں؛ وہ عین متن نقل کریں جو آپ کا کلائنٹ چھاپتا ہے، حروف کے سائز اور رموزِ اوقاف سمیت۔ ہر توقع کی ایک وقت حد ہوتی ہے، اور بند چائلڈ حالت واپس کرنے کے بجائے استثنا پھینکتا ہے، اس لیے ترتیب کو لپیٹیں اور فائل کے اختتام کو ناکامی مانیں۔ غور کریں یہ بلاک کیا نہیں کرتا: چائلڈ اسکرپٹ کے ساتھ مر جاتا ہے، کیونکہ pty الگ کرنے کا طریقہ نہیں ہے اور disown شیل کا اندرونی حکم ہے جو آپ کی اسکرپٹ کے بنائے ہوئے پروسیس تک نہیں پہنچ سکتا۔
جانچ 3: کیا کوئی معاون غیر تعاملی اِن پٹ ہے؟
اسکرین کھرچنا کلائنٹ اپ گریڈ پر ٹوٹ جاتا ہے، اس لیے پہلے دستاویزی اختیار تلاش کریں۔
مدد کے آؤٹ پٹ میں ٹوکن یا ایک بار کے کوڈ کا اختیار دیکھیں، اور دیکھیں کہ سروس پاس ورڈ فیلڈ میں شامل کوڈ قبول کرتی ہے یا نہیں۔ جہاں کلائنٹ اسناد کی فائل پڑھتا ہے، وہاں درخواست کے بجائے اسے فائل دیں:
openvpn --config office.ovpn --auth-user-pass <(printf "%s\n%s\n" "$USER_NAME" "$PASSWORD")پروسیس کی جگہ لینا /dev/fd فراہم کرنے والے نظاموں میں کلائنٹ کو پڑھنے کے قابل راستہ دیتا ہے۔ راز کلائنٹ کی نظر میں اب بھی راز ہے، اس لیے اسے لاگز، شیل تاریخ اور پروسیس فہرستوں سے دور رکھیں۔ اگر کلائنٹ /dev/fd رد کرے یا اسناد کے راستے کو ایک سے زیادہ بار کھولے، تو سخت اجازتوں کے ساتھ اصلی فائل لکھیں اور اسی اسکرپٹ میں اسے حذف کریں۔
جانچ 4: کیا سرنگ اسکرپٹ سے زیادہ زندہ رہے گی؟
بطور طے شدہ سرنگ اپنے والد کے ساتھ مر جاتی ہے، جو بوٹ اسٹریپ اسکرپٹ کی ضرورت کے بالکل برعکس ہے۔
disown -h صرف اس وقت مدد کرتا ہے جب آپ نے کلائنٹ کو شیل جاب کے طور پر شروع کیا ہو، کیونکہ یہ اسی شیل کی جاب ٹیبل میں ترمیم کرتا ہے اور آپ کی اسکرپٹ کے pty کے ذریعے بنائے گئے پروسیس تک نہیں پہنچتا۔ ہر اس چیز کے لیے سروس مینیجر بہتر ٹھکانہ ہے جسے بغیر نگرانی دوبارہ جڑنا ہو، کیونکہ یہ کلائنٹ کو دوبارہ شروع کرتا ہے اور وجہ لکھتا ہے کہ وہ کیوں مرا۔ بہرحال، ہر دوبارہ رابطے کے بعد نیا کوڈ متوقع رکھیں: ایک بار کا ٹوکن پہلی کامیاب توثیق میں خرچ ہو جاتا ہے۔
دیکھیں sudo ترتیب کے ساتھ کیا کرتا ہے۔ sudo کا پاس ورڈ پرامپٹ VPN کا پرامپٹ نہیں ہے، اور اسے VPN پاس ورڈ سے جواب دینا ہی وہ عام ترین طریقہ ہے جس سے بصورتِ دیگر درست توقعات کی ترتیب ناکام ہوتی ہے۔
جانچ 5: کیا کسی شخص کا کوڈ اسکرپٹ میں ہونا چاہیے؟
یہ وہ جانچ ہے جسے لوگ چھوڑ دیتے ہیں۔ ٹوکن کسی شخص کا ہوتا ہے، جبکہ وہ سرنگ جو شیڈول کے مطابق اوپر آنی ہو مشین کی ہوتی ہے۔
اگر کسی کام کو بغیر نگرانی دوبارہ جڑنا ہو، تو پوچھیں کیا مشین سرٹیفکیٹ یا سروس اکاؤنٹ تعاملی لاگ اِن کی جگہ لے سکتا ہے۔ کسی کے ایک بار کے کوڈ کو خودکار بنانا دوسرے عامل کو محفوظ راز میں بدل دیتا ہے، جو پالیسی کی تبدیلی ہے نہ کہ اسکرپٹ کی سہولت۔ جہاں سروس دونوں کو معاون ہو، وہاں ایسی اسناد چنیں جو اس سے میل کھاتی ہوں کہ کام واقعی کیسے چلتا ہے۔ جواب لکھیں، کیونکہ اگلا شخص پوچھے گا کہ اسکرپٹ ٹوکن کیوں رکھتی ہے۔
کام کرنے والی اسکرپٹ کیسی دکھتی ہے
اسکرپٹ وہ مرحلہ چھاپتی ہے جہاں پہنچی، راز کبھی نہیں، اور کسی بھی ناکام توقع پر غیر صفر کوڈ کے ساتھ باہر نکلتی ہے۔
جان بوجھ کر توڑ کر آزمائیں: غلط پاس ورڈ، غلط گروپ، میعاد ختم شدہ ٹوکن۔ ہر ناکامی کو لٹکنے کے بجائے نامزد مرحلے پر رکنا چاہیے۔ پھر اصلی سروس کے سامنے اسے ایک بار چلائیں اور سرنگ کو اسکرپٹ کے باہر سے جانچیں، اندر سے نہیں۔