Starta en sparad Mac-VPN från terminalen med scutil --nc

Du har en sparad VPN-tjänst i Systeminställningar och vill att terminalen ska starta den. På macOS är den stödda vägen scutil --nc, men bara för tjänster som systemets egen nätverksanslutningshanterare äger. Menyraden är inte API:t: tredjepartsklienter har vanligtvis sin egen automatisering, och en profil som skjuts ut av en hanteringstjänst kan neka en lokal start. Det här är checklistan jag kör: hitta den exakta tjänsten, läs dess tillstånd, starta den, vänta på att tillståndet ändras och bevisa sedan att trafiken faktiskt använder tunneln. Stanna vid det första steget som inte stämmer, eftersom varje senare kommando förutsätter att det föregående lyckades.

Hitta tjänsten innan du försöker starta den

Börja med inventeringen i stället för profilnamnet du minns:

scutil --nc help
scutil --nc list

Varje rad parar en status med en tjänstidentifierare, en typ och ett visningsnamn. Identifieraren är värdet du skriptar mot, eftersom visningsnamn upprepas och kan redigeras. Apples scutil-handbok dokumenterar nätverksanslutningsläget, medan den installerade --nc help är den auktoritativa listan över underkommandon på den Macen; anta inte att en flagga från en äldre guide fortfarande finns i din macOS-version.

En tom lista är ett resultat, inte ett fel. En tjänst som skapats av en leverantörsklient eller en hanteringsprofil kan vara aktiv medan den är osynlig här, eller synlig med en typ som den inbyggda kontrollern inte kan styra. I så fall använder du leverantörens verktyg eller profildokumentationen. Att skapa en parallell inbyggd profil bara för att ha något att starta är en dålig affär.

Läs aktuellt tillstånd och bekräfta väljaren

Fråga tjänsten om tillstånd innan du startar den, så att du vet vad en lyckad start ska ändra:

scutil --nc status "Office VPN"

Om två tjänster delar ett visningsnamn är namnet tvetydigt. Skicka identifieraren i stället; kommandot accepterar båda, men bara identifieraren garanterar att en tjänst väljs. Kontrollera att tillståndsordet är ett du känner igen — vanligtvis Connected, Disconnected, Connecting eller Disconnecting — innan du parsar det i ett skript. Kontrollera också om profilen hanteras, eftersom en låst konfiguration kan acceptera kommandot och ändå ignorera det eller fråga efter bekräftelse.

Detta tillståndsanrop är billigt, så använd det som vakt i automatisering: starta bara när statusen är Disconnected, och behandla inte Connecting som ett fel. Om tjänsten redan är Connected, hoppa över starten i stället för att avbryta en fungerande tunnel.

Starta anslutningen och vänta på att tillståndet stabiliseras

Startbegäran är asynkron. Kommandot återvänder när begäran har accepterats, inte när autentiseringen är klar eller rutterna har installerats. Kör det, undersök sedan tillståndet med begränsad väntetid och avbryt om tjänsten faller tillbaka till 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 aldrig löses upp pekar vanligtvis på inloggningsuppgifter, MFA eller servern, inte på scutil. Kommandot kan inte tillhandahålla en interaktiv inloggning, så en profil som väntar på en token eller en hårdvarunyckel blir kvar i Connecting och faller till slut tillbaka. Läs tillståndsordet innan du lägger till nya försök; en loop mot en autentiseringsprompt kan inte lyckas.

Behandla inte skalets utgångsstatus som beredskap. Den användbara signalen är tillståndssträngen, följd av bevis på att tunneln bär trafik. Ett startkommando som återvänder tyst kan fortfarande lämna dig med en anslutning som aldrig autentiseras.

Bevisa att tunneln bär trafik, inte bara att den säger Connected

Connected beskriver anslutningen, inte routingbeslutet. Inbyggda PPP- och IKEv2-tjänster skapar ett ppp- eller utun-gränssnitt och installerar rutter, medan en delad tunnel avsiktligt lämnar standardrutten orörd. Inspektera gränssnitten och båda adressfamiljerna:

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

Hitta gränssnittet som tjänsten skapade i stället för att gissa ett nummer, fråga sedan routingtabellen vilket gränssnitt en viss destination använder: route -n get 10.0.0.10, med en intern värd i stället. Om den rapporterar det fysiska gränssnittet är tunneln uppe men bär inte det flödet. Kontrollera delade tunnelrutter, resolverordning och varje lokal brandväggsregel som tillåter tunnelgränssnittet men inte processen.

Namnuppslagning är den vanliga falska negativen. Interna namn kan lösas genom fel resolver medan tunneln är helt frisk, vilket ser ut som ett VPN-fel och inte är det. scutil --dns visar ordningen som macOS kommer att använda; efter en resolverändring, töm cachen med dscacheutil -flushcache och sudo killall -HUP mDNSResponder.

Håll inloggningsuppgifter och privilegier utanför kommandoraden

Lägg aldrig ett lösenord, en fördelad nyckel eller en token i argumenten. Argument syns i processlistor och hamnar i skalhistoriken, och en kopierad supportutskrift kan läcka dem. Profilens egen hantering av inloggningsuppgifter — vare sig det är ett Keychain-objekt, en systemprompt eller klientens autentiseringsflöde — är platsen för hemligheter.

Att köra kommandot med sudo gör inte en interaktiv inloggning obevakad. Det ändrar den effektiva användaren, inte tillgängligheten av en GUI-prompt, en hårdvarutoken eller inloggningsnyckelringen. En LaunchAgent kan starta en tjänst efter att användaren loggat in och nyckelringen låsts upp; en LaunchDaemon når vanligtvis inte dessa delar av användarsessionen. Om en organisation hanterar tjänsten vinner dess livscykelregler över alla lokala skript.

Stoppa tjänsten och verifiera att den förblev stoppad

Stoppa med samma väljare som du använde för att starta, och läs sedan tillståndet igen i stället för att anta att tunneln är borta:

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

En stoppa som återgår till Disconnected lämnar ändå en sak att kontrollera: om profilen är inställd på att ansluta vid behov, vilket kan föra tillbaka den utan ditt skript. Om en annan klient äger rutter på samma Mac kan dessa rutter överleva en inbyggd stopp. Kör rutkontrollen igen innan du drar slutsatsen att maskinen är utanför VPN:en.

För ett omslag som du kör manuellt, håll ordningen fast: lista, status, start, undersökning, ruttest, stopp, verifiering. Parsa inte det vänliga namnet ur fri form när identifieraren är tillgänglig, och behandla inte startkommandots utgång som beredskap. Anslutningshanteraren rapporterar tillstånd; ditt bevis är tillståndet plus en rutt som pekar på tunneln.