scutil --nc کے ساتھ ٹرمینل سے محفوظ شدہ Mac VPN شروع کریں

آپ کے پاس سسٹم سیٹنگز میں محفوظ شدہ VPN سروس ہے، اور آپ چاہتے ہیں کہ ٹرمینل اسے شروع کرے۔ macOS پر معاون راستہ scutil --nc ہے، لیکن صرف ان سروسز کے لیے جو نظام کے اپنے نیٹ ورک کنکشن مینیجر کی ملکیت ہیں۔ مینو بار API نہیں ہے: تیسرے فریق کے کلائنٹس کے عموماً اپنے آٹومیشن ہوتے ہیں، اور انتظامی سروس کا بھیجا ہوا پروفائل مقامی آغاز سے انکار کر سکتا ہے۔ یہ میری عمل کی جانچ فہرست ہے: درست سروس تلاش کریں، اس کی حالت پڑھیں، اسے شروع کریں، حالت بدلنے کا انتظار کریں، اور پھر ثابت کریں کہ ٹریفک واقعی ٹنل استعمال کرتی ہے۔ پہلے نہ ملنے والے مرحلے پر رکیں، کیونکہ ہر اگلا حکم سمجھتا ہے کہ پچھلا کامیاب ہوا۔

شروع کرنے کی کوشش سے پہلے سروس تلاش کریں

یاد رہنے والے پروفائل نام کی بجائے فہرست سے شروع کریں:

scutil --nc help
scutil --nc list

ہر سطر ایک حالت کو سروس شناخت کنندہ، قسم اور ظاہری نام کے ساتھ جوڑتی ہے۔ شناخت کنندہ وہ قدر ہے جس پر اسکرپٹ لکھی جاتی ہے، کیونکہ ظاہری نام دہرائے جاتے ہیں اور تبدیل کیے جا سکتے ہیں۔ ایپل کا scutil دستی نیٹ ورک کنکشن موڈ کی دستاویز کرتا ہے، جبکہ نصب شدہ --nc help اس Mac پر ذیلی احکامات کی مستند فہرست ہے؛ یہ نہ سمجھیں کہ پرانی گائیڈ کا کوئی فلیگ آپ کے macOS ورژن میں اب بھی موجود ہے۔

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

موجودہ حالت پڑھیں اور منتخب کنندہ کی تصدیق کریں

شروع کرنے سے پہلے سروس سے حالت پوچھیں، تاکہ معلوم ہو کہ کامیاب آغاز کو کیا بدلنا چاہیے:

scutil --nc status "Office VPN"

اگر دو سروسز ایک ہی ظاہری نام رکھتی ہیں تو نام مبہم ہے۔ اس کی بجائے شناخت کنندہ دیں؛ حکم دونوں قبول کرتا ہے، لیکن ایک سروس منتخب کرنے کی ضمانت صرف شناخت کنندہ کو ہے۔ اسکرپٹ میں تجزیہ کرنے سے پہلے جانچیں کہ حالت کا لفظ آپ کے مانوس الفاظ میں سے ہے — عموماً Connected, Disconnected, Connecting یا Disconnecting۔ یہ بھی جانچیں کہ پروفائل زیرِ انتظام ہے یا نہیں، کیونکہ مقفل ترتیب حکم قبول کر کے بھی اسے نظر انداز کر سکتی ہے یا تصدیق طلب کر سکتی ہے۔

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

کنکشن شروع کریں اور حالت کے مستحکم ہونے کا انتظار کریں

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

scutil --nc start "Office VPN"
n=0
while [ "$n" -lt 30 ]; do
  state=$(scutil --nc status "Office VPN" | head -n 1)
  [ "$state" = "Connected" ] && break
  [ "$state" = "Disconnected" ] && { echo "start failed"; exit 1; }
  sleep 2
  n=$((n + 1))
done

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

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

ثابت کریں کہ ٹنل ٹریفک لے جاتی ہے، صرف Connected کہنا نہیں

Connected کنکشن بیان کرتا ہے، روٹنگ کا فیصلہ نہیں۔ مقامی PPP اور IKEv2 سروسز ppp یا utun انٹرفیس بناتی ہیں اور روٹس نصب کرتی ہیں، جبکہ منقسم ٹنل جان بوجھ کر ڈیفالٹ روٹ کو اچھوتا چھوڑ دیتی ہے۔ انٹرفیس اور دونوں ایڈریس خاندانوں کا معائنہ کریں:

ifconfig -l
netstat -rn -f inet
netstat -rn -f inet6
scutil --dns

نمبر کا اندازہ لگانے کی بجائے سروس کے بنائے ہوئے انٹرفیس کو تلاش کریں، پھر روٹنگ ٹیبل سے پوچھیں کہ کوئی مخصوص منزل کون سا انٹرفیس استعمال کرتی ہے: route -n get 10.0.0.10، اس کی جگہ اندرونی ہوسٹ رکھ کر۔ اگر یہ جسمانی انٹرفیس بتائے تو ٹنل چالو ہے مگر وہ بہاؤ نہیں لے جا رہی۔ منقسم ٹنل کے روٹس، ریزولور ترتیب اور کوئی بھی مقامی فائر وال قاعدہ جانچیں جو ٹنل انٹرفیس کو اجازت دیتا ہے مگر عمل کو نہیں۔

ناموں کا حل عام غلط منفی ہے۔ اندرونی نام غلط ریزولور کے ذریعے حل ہو سکتے ہیں جبکہ ٹنل مکمل صحت مند ہو، جو VPN خرابی جیسا لگتا ہے اور نہیں ہے۔ scutil --dns وہ ترتیب دکھاتا ہے جو macOS استعمال کرے گا؛ ریزولور تبدیلی کے بعد dscacheutil -flushcache اور sudo killall -HUP mDNSResponder سے کیش خالی کریں۔

اسناد اور اختیارات کو کمانڈ لائن سے باہر رکھیں

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

sudo کے ساتھ حکم چلانا متعامل لاگ ان کو بغیر نگرانی کا نہیں بناتا۔ یہ موثر صارف بدلتا ہے، GUI پرامپٹ، ہارڈ ویئر ٹوکن یا لاگ ان کی چین کی دستیابی نہیں۔ صارف کے لاگ ان کرنے اور کی چین کھلنے کے بعد LaunchAgent سروس شروع کر سکتا ہے؛ LaunchDaemon عموماً صارف سیشن کے ان حصوں تک نہیں پہنچتا۔ اگر کوئی ادارہ سروس کا انتظام کرتا ہے تو اس کے زندگی چکر کے قواعد کسی بھی مقامی اسکرپٹ پر بھاری ہیں۔

سروس روکیں اور جانچیں کہ وہ رکی ہی رہی

آغاز کے لیے استعمال ہونے والے اسی منتخب کنندہ سے روکیں، پھر ٹنل جانے کی بجائے حالت دوبارہ پڑھیں:

scutil --nc stop "Office VPN"
scutil --nc status "Office VPN"

Disconnected پر لوٹنے والی روکاؤ اب بھی ایک چیز جانچنے کے لیے چھوڑتی ہے: کیا پروفائل طلب پر جڑنے کے لیے مقرر ہے، جو آپ کی اسکرپٹ کے بغیر اسے واپس لا سکتا ہے۔ اگر اسی Mac پر کسی اور کلائنٹ کے روٹس ہیں تو وہ روٹس مقامی روکاؤ سے بچ سکتے ہیں۔ مشین کے VPN سے باہر ہونے کا نتیجہ نکالنے سے پہلے روٹ کی جانچ دوبارہ چلائیں۔

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