د scutil --nc په مرسته له ټرمینل څخه خوندي شوی Mac VPN پیل کړئ

تاسو په سیستم تنظیماتو کې خوندي شوې VPN خدمت لرئ، او غواړئ چې ټرمینل یې پیل کړي۔ په macOS کې ملاتړ شوې لار scutil --nc ده، خو یوازې هغو خدمتونو لپاره چې د سیستم د خپل شبکې اړیکو مدیر ملکیت وي۔ د مینو بار API نه دی: دریمې ډلې کلینټونه معمولاً خپل اتوماتیک کول لري، او هغه پروفایل چې د مدیریت خدمت لخوا رالېږل کیږي کیدای شي محلي پیل رد کړي۔ دا هغه چک لیست دی چې زه یې پرمخ وړم: دقیق خدمت ومومئ، د هغه حالت ولولئ، یې پیل کړئ، د حالت بدلون ته انتظار وکړئ، او بیا ثابته کړئ چې ترافیک واقعاً تونل کاروي۔ په لومړي هغه ګام کې ودریږئ چې سم نه وي، ځکه هر راتلونکی امر فرض کوي چې پخوانی بریالی شوی۔

د پیل کولو هڅه کولو دمخه خدمت ومومئ

د هغه پروفایل نوم پرځای چې په یاد لرئ، له لیست څخه پیل وکړئ:

scutil --nc help
scutil --nc list

هره کرښه یو حالت له خدمت پیژندونکي، ډول او ښودل شوي نوم سره جوړه کوي۔ پیژندونکی هغه ارزښت دی چې سکریپټ پرې لیکل کیږي، ځکه ښودل شوي نومونه تکرار کیږي او کیدای شي سمون شي۔ د Apple 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 غوښتنې، د سختې وسایلې ټوکن یا د ننوتلو Keychain شتون۔ LaunchAgent کیدای شي خدمت پیل کړي وروسته له دې چې کارونکی ننوځي او Keychain پرانیستل شي؛ LaunchDaemon معمولاً د کارونکي غونډې هغو برخو ته نشي رسیدلی۔ که یوه اداره خدمت مدیریت کوي، د هغې ژوند چرخه قواعد له هر محلي سکریپټ څخه مخکې دي۔

خدمت بند کړئ او وګورئ چې بند پاتې شو

د پیل کولو لپاره کارول شوي ورته ټاکونکي سره بند کړئ، بیا د دې پرځای چې فکر کوئ تونل تللی، حالت بیا ولولئ:

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

Disconnected ته راستنیدونکی بند لا هم یو شی د کتلو لپاره پرېږدي: ایا پروفایل د غوښتنې پر بنسټ نښلولو لپاره ټاکل شوی، کوم چې کیدای شي هغه ستاسو له سکریپټ پرته بېرته راوړي۔ که بل کلینټ په ورته Mac کې لارې لري، هغه لارې کیدای شي اصلي بند ته ژوندی پاتې شي۔ د دې پایلې دمخه چې ماشین له VPN بهر دی، د لارې کتنه بیا چلوئ۔

د لاسي چلولو ریپر لپاره ترتیب ثابت وساتئ: لیست، حالت، پیل، پوښتنه، د لارې ازموینه، بند، تایید۔ کله چې پیژندونکی شتون لري د آزاد بڼې وتنې څخه دوستانه نوم مه تحلیل کوئ، او د پیل امر وتل د تیارۍ په توګه مه ګڼئ۔ د اړیکو مدیر حالت راپور کوي؛ ستاسو ثبوت حالت او هغه لاره ده چې تونل ته اشاره کوي۔