შენახული Mac VPN-ის გაშვება ტერმინალიდან scutil --nc-ით

გამოიყენეთ scutil --nc შენახული macOS VPN სერვისის გასაშვებად, შესამოწმებლად და შესაჩერებლად, შეინახეთ სერთიფიკატები argv-ის გარეთ და დაამტკიცეთ, რომ ტრაფიკი ნამდვილად გვირაბს იყენებს.

თქვენ გაქვთ შენახული 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, შიდა ჰოსტის ჩანაცვლებით. თუ ის ფიზიკურ ინტერფეისს აცხადებს, გვირაბი ჩართულია, მაგრამ ამ ნაკადს არ ატარებს. შეამოწმეთ გაყოფილი გვირაბის მარშრუტები, გადამწყვეტის რიგი და ნებისმიერი ლოკალური firewall წესი, რომელიც გვირაბის ინტერფეისს უშვებს, პროცესს კი არა.

სახელების გადაწყვეტა ჩვეულებრივი ცრუ უარყოფითია. შიდა სახელები შეიძლება გადაწყდეს არასწორი გადამწყვეტის მეშვეობით, როცა გვირაბი სრულიად ჯანმრთელია, რაც 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-ის გარეთაა, ხელახლა შეამოწმეთ მარშრუტი.

ხელით გაშვებული გარსისთვის შეინარჩუნეთ თანმიმდევრობა: სია, სტატუსი, გაშვება, შემოწმება, მარშრუტის ტესტი, შეჩერება, დადასტურება. ნუ გააანალიზებთ მეგობრულ სახელს თავისუფალი ფორმატის გამოსავლიდან, როცა იდენტიფიკატორი ხელმისაწვდომია, და ნუ ჩათვლით გაშვების ბრძანების გასვლას მზადყოფნად. კავშირების მმართველი აცხადებს მდგომარეობას; თქვენი მტკიცებულებაა მდგომარეობა და მარშრუტი, რომელიც გვირაბზე მიუთითებს.

დაკავშირებული სტატიები