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

Du har en lagret VPN-tjeneste i Systeminnstillinger, og du vil at terminalen skal starte den. På macOS er den støttede veien scutil --nc, men bare for tjenester som systemets egen nettverksforbindelsesbehandler eier. Menylinjen er ikke API-et: tredjepartsklienter har vanligvis sin egen automatisering, og en profil som skyves ut av en administrasjonstjeneste kan nekte en lokal start. Dette er sjekklisten jeg kjører: finn den nøyaktige tjenesten, les tilstanden, start den, vent på at tilstanden endres, og bevis deretter at trafikken faktisk bruker tunnelen. Stopp ved det første trinnet som ikke stemmer, fordi hver senere kommando forutsetter at den forrige lyktes.

Finn tjenesten før du prøver å starte den

Begynn med oversikten i stedet for profilnavnet du husker:

scutil --nc help
scutil --nc list

Hver linje parer en status med en tjenesteidentifikator, en type og et visningsnavn. Identifikatoren er verdien du skriver skript mot, fordi visningsnavn gjentas og kan redigeres. Apples scutil-håndbok dokumenterer nettverksforbindelsesmodusen, mens den installerte --nc help er den autoritative listen over underkommandoer på den Macen; ikke anta at et flagg fra en eldre veiledning fortsatt finnes i macOS-versjonen din.

En tom liste er et resultat, ikke en feil. En tjeneste opprettet av en leverandørklient eller en administrasjonsprofil kan være aktiv mens den er usynlig her, eller synlig med en type som den innebygde kontrolleren ikke kan drive. I så fall bruker du leverandørens verktøy eller profildokumentasjonen. Å opprette en parallell innebygd profil bare for å ha noe å starte er en dårlig handel.

Les gjeldende tilstand og bekreft velgeren

Spør tjenesten om tilstand før du starter den, slik at du vet hva en vellykket start skal endre:

scutil --nc status "Office VPN"

Hvis to tjenester deler et visningsnavn, er navnet tvetydig. Send identifikatoren i stedet; kommandoen godtar begge, men bare identifikatoren er garantert å velge én tjeneste. Kontroller at tilstandsordet er et du kjenner — vanligvis Connected, Disconnected, Connecting eller Disconnecting — før du parser det i et skript. Kontroller også om profilen administreres, fordi en låst konfigurasjon kan godta kommandoen og likevel ignorere den eller spørre om bekreftelse.

Dette tilstandsvarselet er billig, så bruk det som vakt i automatisering: start bare når statusen er Disconnected, og ikke behandle Connecting som en feil. Hvis tjenesten allerede er Connected, hopp over starten i stedet for å avbryte en fungerende tunnel.

Start forbindelsen og vent på at tilstanden stabiliserer seg

Startforespørselen er asynkron. Kommandoen kommer tilbake når forespørselen er godtatt, ikke når autentiseringen er ferdig eller rutene er installert. Kjør den, og undersøk deretter tilstanden med begrenset venting, og avbryt hvis tjenesten faller tilbake 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 Connecting-status som aldri løses opp, peker vanligvis på påloggingsinformasjon, MFA eller serveren, ikke på scutil. Kommandoen kan ikke levere en interaktiv pålogging, så en profil som forventer et token eller en maskinvarebrikke, blir stående i Connecting og faller til slutt tilbake. Les tilstandsordet før du legger til nye forsøk; en løkke mot en autentiseringsforespørsel kan ikke lykkes.

Ikke behandle skallens utgangsstatus som beredskap. Det nyttige signalet er tilstandsstrengen, etterfulgt av bevis på at tunnelen bærer trafikk. En startkommando som kommer stille tilbake, kan fortsatt etterlate deg med en forbindelse som aldri autentiseres.

Bevis at tunnelen bærer trafikk, ikke bare at den sier Connected

Connected beskriver forbindelsen, ikke rutingsbeslutningen. Innebygde PPP- og IKEv2-tjenester oppretter et ppp- eller utun-grensesnitt og installerer ruter, mens en delt tunnel bevisst lar standardruten være. Inspiser grensesnittene og begge adressefamiliene:

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

Finn grensesnittet tjenesten opprettet i stedet for å gjette et nummer, og spør deretter rutetabellen hvilket grensesnitt en bestemt destinasjon bruker: route -n get 10.0.0.10, med en intern vert i stedet. Hvis den rapporterer det fysiske grensesnittet, er tunnelen oppe, men bærer ikke den strømmen. Kontroller delte tunnelruter, resolverrekkefølge og enhver lokal brannmurregel som tillater tunnellgrensesnittet men ikke prosessen.

Navneoppslag er den vanlige falske negativen. Interne navn kan løses gjennom feil resolver mens tunnelen er helt sunn, noe som ser ut som en VPN-feil og ikke er det. scutil --dns viser rekkefølgen macOS vil bruke; etter en resolverendring, tøm bufferen med dscacheutil -flushcache og sudo killall -HUP mDNSResponder.

Hold påloggingsinformasjon og privilegier utenfor kommandolinjen

Legg aldri inn et passord, en forhåndsdelt nøkkel eller et token i argumentene. Argumenter er synlige i prosesslister og havner i skallhistorikken, og en kopiert støtteutskrift kan lekke dem. Profilens egen håndtering av påloggingsinformasjon — enten det er et Keychain-element, en systemforespørsel eller klientens autentiseringsflyt — er stedet for hemmeligheter.

Å kjøre kommandoen med sudo gjør ikke en interaktiv pålogging ubetjent. Det endrer den effektive brukeren, ikke tilgjengeligheten til en GUI-forespørsel, en maskinvarebrikke eller påloggingsnøkkelringen. En LaunchAgent kan starte en tjeneste etter at brukeren har logget inn og nøkkelringen er låst opp; en LaunchDaemon når vanligvis ikke disse delene av brukersesjonen. Hvis en organisasjon administrerer tjenesten, vinner dens livssyklusregler over ethvert lokalt skript.

Stopp tjenesten og bekreft at den forble stoppet

Stopp med den samme velgeren du brukte til å starte, og les deretter tilstanden på nytt i stedet for å anta at tunnelen er borte:

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

En stopp som går tilbake til Disconnected, etterlater likevel én ting å kontrollere: om profilen er satt til å koble til ved behov, noe som kan bringe den tilbake uten skriptet ditt. Hvis en annen klient eier ruter på samme Mac, kan disse rutene overleve en innebygd stopp. Kjør rutekontrollen på nytt før du konkluderer med at maskinen er utenfor VPN-en.

For en innpakning du kjører manuelt, hold rekkefølgen fast: liste, status, start, undersøkelse, rutetest, stopp, bekreftelse. Ikke parse det vennlige navnet ut av fri format når identifikatoren er tilgjengelig, og ikke behandle startkommandoens utgang som beredskap. Tilkoblingsbehandleren rapporterer tilstand; beviset ditt er tilstanden pluss en rute som peker på tunnelen.