Pornirea unui VPN Mac salvat din terminal cu scutil --nc

Aveți un serviciu VPN salvat în Setările sistemului și doriți ca terminalul să îl pornească. Pe macOS calea acceptată este scutil --nc, dar numai pentru serviciile deținute de managerul propriu de conexiuni de rețea al sistemului. Bara de meniu nu este API-ul: clienții terți au de obicei propria automatizare, iar un profil distribuit de un serviciu de administrare poate refuza o pornire locală. Aceasta este lista de verificare pe care o parcurg: găsiți serviciul exact, citiți-i starea, porniți-l, așteptați schimbarea stării și apoi demonstrați că traficul folosește într-adevăr tunelul. Opriți-vă la primul pas care nu se potrivește, pentru că fiecare comandă ulterioară presupune că precedenta a reușit.

Găsiți serviciul înainte de a încerca să îl porniți

Începeți cu inventarul, nu cu numele profilului pe care îl țineți minte:

scutil --nc help
scutil --nc list

Fiecare linie asociază o stare cu un identificator de serviciu, un tip și un nume afișat. Identificatorul este valoarea pentru care se scriu scripturi, pentru că numele afișate se repetă și pot fi editate. Manualul scutil al Apple documentează modul de conexiune la rețea, în timp ce --nc help instalat este lista autoritativă a subcomenzilor pe acel Mac; nu presupuneți că un comutator dintr-un ghid mai vechi mai există în versiunea dumneavoastră de macOS.

O listă goală este un rezultat, nu o eroare. Un serviciu creat de un client al furnizorului sau de un profil de administrare poate fi activ în timp ce este invizibil aici, sau vizibil cu un tip pe care controlerul nativ nu îl poate conduce. În acest caz, folosiți instrumentul furnizorului sau documentația profilului. Crearea unui profil nativ paralel doar pentru a avea ce porni este o afacere proastă.

Citiți starea curentă și confirmați selectorul

Întrebați serviciul despre stare înainte de a-l porni, ca să știți ce ar trebui să schimbe o pornire reușită:

scutil --nc status "Office VPN"

Dacă două servicii împart un nume afișat, numele este ambiguu. Transmiteți identificatorul în schimb; comanda acceptă ambele, dar numai identificatorul garantează selectarea unui singur serviciu. Înainte de a-l analiza într-un script, verificați că cuvântul de stare este unul cunoscut — de obicei Connected, Disconnected, Connecting sau Disconnecting. Verificați și dacă profilul este administrat, pentru că o configurație blocată poate accepta comanda și totuși o ignoră sau cere confirmare.

Acest apel de stare este ieftin, așa că folosiți-l ca gardă în automatizare: porniți numai când starea este Disconnected și nu tratați Connecting ca pe o eroare. Dacă serviciul este deja Connected, săriți peste pornire în loc să întrerupeți un tunel funcțional.

Porniți conexiunea și așteptați stabilizarea stării

Cererea de pornire este asincronă. Comanda revine când cererea a fost acceptată, nu când se termină autentificarea sau se instalează rutele. Executați-o, apoi interogați starea cu o așteptare limitată și ieșiți dacă serviciul revine la 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

O stare Connecting care nu se rezolvă niciodată indică de obicei acreditări, MFA sau serverul, nu scutil. Comanda nu poate oferi o autentificare interactivă, așa că un profil care așteaptă un token sau o cheie hardware va rămâne în Connecting și în cele din urmă va reveni. Citiți cuvântul de stare înainte de a adăuga reîncercări; o buclă împotriva unui prompt de autentificare nu poate reuși.

Nu tratați starea de ieșire a shell-ului ca fiind disponibilitate. Semnalul util este șirul de stare, urmat de dovada că tunelul transportă trafic. O comandă de pornire care revine în tăcere vă poate lăsa totuși cu o conexiune care nu se autentifică niciodată.

Demonstrați că tunelul transportă trafic, nu doar că spune Connected

Connected descrie conexiunea, nu decizia de rutare. Serviciile native PPP și IKEv2 creează o interfață ppp sau utun și instalează rute, în timp ce un tunel divizat lasă în mod deliberat ruta implicită neatinsă. Inspectați interfețele și ambele familii de adrese:

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

Găsiți interfața creată de serviciu în loc să ghiciți un număr, apoi întrebați tabelul de rutare ce interfață folosește o destinație anume: route -n get 10.0.0.10, înlocuind-o cu un gazdă internă. Dacă raportează interfața fizică, tunelul este activ dar nu transportă acel flux. Verificați rutele tunelului divizat, ordinea resolutorilor și orice regulă locală de firewall care permite interfața tunelului dar nu procesul.

Rezolvarea numelor este falsul negativ obișnuit. Numele interne pot fi rezolvate prin resolutorul greșit în timp ce tunelul este perfect sănătos, ceea ce arată ca o defecțiune VPN și nu este. scutil --dns arată ordinea pe care o va folosi macOS; după o schimbare de resolutor, goliți cache-ul cu dscacheutil -flushcache și sudo killall -HUP mDNSResponder.

Țineți acreditările și privilegiile în afara liniei de comandă

Nu puneți niciodată o parolă, o cheie prepartajată sau un token în argumente. Argumentele sunt vizibile în listele de procese și ajung în istoricul shell-ului, iar o transcriere de suport copiată le poate divulga. Gestionarea acreditărilor de către profilul însuși — fie un element Keychain, o solicitare de sistem sau fluxul de autentificare al clientului — este locul pentru secrete.

Rularea comenzii cu sudo nu face o autentificare interactivă nesupravegheată. Schimbă utilizatorul efectiv, nu disponibilitatea unei solicitări GUI, a unui token hardware sau a keychain-ului de autentificare. Un LaunchAgent poate porni un serviciu după ce utilizatorul s-a autentificat și keychain-ul este deblocat; un LaunchDaemon de obicei nu ajunge la acele părți ale sesiunii utilizatorului. Dacă o organizație administrează serviciul, regulile sale de ciclu de viață au prioritate față de orice script local.

Opriți serviciul și verificați că a rămas oprit

Opriți cu același selector pe care l-ați folosit pentru pornire, apoi citiți din nou starea în loc să presupuneți că tunelul a dispărut:

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

O oprire care revine la Disconnected lasă totuși un lucru de verificat: dacă profilul este setat să se conecteze la cerere, ceea ce îl poate readuce fără scriptul dumneavoastră. Dacă un alt client deține rute pe același Mac, acele rute pot supraviețui unei opriri native. Verificați din nou ruta înainte de a concluziona că mașina este în afara VPN-ului.

Pentru un wrapper rulat manual, păstrați ordinea fixă: listă, stare, pornire, interogare, test de rută, oprire, verificare. Nu analizați numele prietenos dintr-o ieșire liberă când identificatorul este disponibil și nu tratați ieșirea comenzii de pornire ca disponibilitate. Managerul de conexiuni raportează starea; dovada dumneavoastră este starea plus o rută care indică tunelul.