Start en gemt Mac-VPN fra terminalen med scutil --nc

Du har en gemt VPN-tjeneste i Systemindstillinger, og du vil have terminalen til at starte den. På macOS er den understøttede vej scutil --nc, men kun for tjenester, som systemets egen netværksforbindelsesmanager ejer. Menulinjen er ikke API’et: tredjepartsklienter har normalt deres egen automatisering, og en profil, der er skubbet ud af en styringstjeneste, kan afvise en lokal start. Dette er den tjekliste, jeg kører: find den præcise tjeneste, læs dens tilstand, start den, vent på at tilstanden ændrer sig, og bevis derefter, at trafikken faktisk bruger tunnelen. Stop ved det første trin, der ikke stemmer, fordi hver senere kommando forudsætter, at den foregående lykkedes.

Find tjenesten, før du prøver at starte den

Begynd med oversigten i stedet for det profilnavn, du husker:

scutil --nc help
scutil --nc list

Hver linje parrer en status med en tjenesteidentifikator, en type og et visningsnavn. Identifikatoren er den værdi, du skriver scripts imod, fordi visningsnavne gentages og kan redigeres. Apples scutil-manual dokumenterer netværksforbindelsestilstanden, mens den installerede --nc help er den autoritative liste over underkommandoer på den Mac; antag ikke, at et flag fra en ældre guide stadig findes i din macOS-version.

En tom liste er et resultat, ikke en fejl. En tjeneste oprettet af en leverandørklient eller en styringsprofil kan være aktiv, mens den er usynlig her, eller synlig med en type, som den indbyggede controller ikke kan drive. I så fald skal du bruge leverandørens værktøj eller profildokumentationen. At oprette en parallel indbygget profil bare for at have noget at starte er en dårlig handel.

Læs den aktuelle tilstand, og bekræft vælgeren

Forespørg på tjenesten, før du starter den, så du ved, hvad en vellykket start bør ændre:

scutil --nc status "Office VPN"

Hvis to tjenester deler et visningsnavn, er navnet tvetydigt. Send i stedet identifikatoren; kommandoen accepterer begge, men kun identifikatoren er garanteret at vælge én tjeneste. Kontroller, at tilstandsordet er et, du kender — typisk Connected, Disconnected, Connecting eller Disconnecting — før du parser det i et script. Kontroller også, om profilen er administreret, fordi en låst konfiguration kan acceptere kommandoen og stadig ignorere den eller spørge om bekræftelse.

Dette tilstandskald er billigt, så brug det som vagt i automatisering: start kun, når statussen er Disconnected, og behandl ikke Connecting som en fejl. Hvis tjenesten allerede er Connected, så spring starten over i stedet for at afbryde en fungerende tunnel.

Start forbindelsen, og vent på, at tilstanden falder til ro

Startanmodningen er asynkron. Kommandoen vender tilbage, når anmodningen er accepteret, ikke når godkendelsen er færdig, eller ruterne er installeret. Kør den, og poll derefter tilstanden med en afgrænset ventetid, og afbryd, hvis tjenesten falder tilbage til 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

En status Connecting, der aldrig bliver løst, peger normalt på legitimationsoplysninger, MFA eller serveren, ikke på scutil. Kommandoen kan ikke levere et interaktivt login, så en profil, der forventer et token eller en hardwarenøgle, bliver siddende i Connecting og falder til sidst tilbage. Læs tilstandsordet, før du tilføjer gentagelser; en løkke mod en godkendelsesprompt kan ikke lykkes.

Behandl ikke shellens exitstatus som parathed. Det nyttige signal er tilstandsstrengen, efterfulgt af bevis for, at tunnelen bærer trafik. En startkommando, der vender stille tilbage, kan stadig efterlade dig med en forbindelse, der aldrig godkendes.

Bevis, at tunnelen bærer trafik, ikke bare at den siger Connected

Connected beskriver forbindelsen, ikke routingbeslutningen. Indbyggede PPP- og IKEv2-tjenester opretter en ppp- eller utun-grænseflade og installerer ruter, mens en opdelt tunnel bevidst lader standardruten være. Undersøg grænsefladerne og begge adressefamilier:

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

Find den grænseflade, tjenesten oprettede, i stedet for at gætte et nummer, og spørg derefter routingtabellen, hvilken grænseflade en bestemt destination bruger: route -n get 10.0.0.10, med en intern vært indsat i stedet. Hvis den rapporterer den fysiske grænseflade, er tunnelen oppe, men bærer ikke den strøm. Kontroller opdelte tunnelruter, resolverrækkefølge og enhver lokal firewallregel, der tillader tunnelgrænsefladen men ikke processen.

Navneopløsning er den sædvanlige falske negativ. Interne navne kan opløses gennem den forkerte resolver, mens tunnelen er helt sund, hvilket ligner en VPN-fejl og ikke er en. scutil --dns viser den rækkefølge, macOS vil bruge; efter en resolverændring skal du tømme cachen med dscacheutil -flushcache og sudo killall -HUP mDNSResponder.

Hold legitimationsoplysninger og privilegier ude af kommandolinjen

Læg aldrig en adgangskode, en forudelt nøgle eller et token i argumenterne. Argumenter er synlige i proceslister og ender i shellhistorik, og en kopieret supportudskrift kan lække dem. Profilens egen håndtering af legitimationsoplysninger — hvad enten det er et Keychain-element, en systemprompt eller klientens godkendelsesflow — er stedet for hemmeligheder.

At køre kommandoen med sudo gør ikke et interaktivt login ubemandet. Det ændrer den effektive bruger, ikke tilgængeligheden af en GUI-prompt, et hardwaredetoken eller login-nøgleringen. En LaunchAgent kan starte en tjeneste, efter brugeren er logget ind, og nøgleringen er låst op; en LaunchDaemon kan normalt ikke nå disse dele af brugersessionen. Hvis en organisation administrerer tjenesten, vinder dens livscyklusregler over ethvert lokalt script.

Stop tjenesten, og bekræft at den blev stoppet

Stop med den samme vælger, du brugte til at starte, og læs derefter tilstanden igen i stedet for at antage, at tunnelen er væk:

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

Et stop, der vender tilbage til Disconnected, efterlader stadig én ting at kontrollere: om profilen er indstillet til at forbinde efter behov, hvilket kan bringe den tilbage uden dit script. Hvis en anden klient ejer ruter på den samme Mac, kan disse ruter overleve et indbygget stop. Kør rutekontrollen igen, før du konkluderer, at maskinen er uden for VPN’en.

For en wrapper, du kører manuelt, skal du holde rækkefølgen fast: liste, status, start, poll, rutetest, stop, bekræft. Parse ikke det venlige navn ud af frit format, når identifikatoren er tilgængelig, og behandl ikke startkommandoens exit som parathed. Forbindelsesmanageren rapporterer tilstand; dit bevis er tilstanden plus en rute, der peger på tunnelen.