Een opgeslagen Mac-VPN starten vanuit de terminal met scutil --nc

Je hebt een opgeslagen VPN-service in Systeeminstellingen, en je wilt dat de terminal hem start. Op macOS is het ondersteunde pad scutil --nc, maar alleen voor services die eigendom zijn van de eigen netwerkverbindingsbeheerder van het systeem. De menubalk is niet de API: clients van derden hebben meestal hun eigen automatisering, en een profiel dat door een beheerservice wordt gepusht, kan een lokale start weigeren. Dit is de checklist die ik doorloop: vind de exacte service, lees de status, start hem, wacht tot de status verandert en bewijs dan dat verkeer echt de tunnel gebruikt. Stop bij de eerste stap die niet klopt, want elk later commando veronderstelt dat het vorige is geslaagd.

Vind de service voordat je hem probeert te starten

Begin met de inventaris in plaats van de profielnaam die je onthoudt:

scutil --nc help
scutil --nc list

Elke regel koppelt een status aan een service-identificatie, een type en een weergavenaam. De identificatie is de waarde om tegen te scripten, omdat weergavenamen herhalen en kunnen worden bewerkt. Apple’s scutil-handleiding documenteert de netwerkverbindingsmodus, terwijl de geïnstalleerde --nc help de gezaghebbende lijst met subcommando’s op die Mac is; ga er niet van uit dat een vlag uit een oudere gids nog bestaat in jouw macOS-versie.

Een lege lijst is een resultaat, geen fout. Een service die door een leveranciersclient of een beheerprofiel is gemaakt, kan actief zijn terwijl hij hier onzichtbaar is, of zichtbaar met een type dat de native controller niet kan aansturen. Gebruik in dat geval de tool van de leverancier of de profieldocumentatie. Een parallel native profiel aanmaken alleen om iets te hebben om te starten is een slechte ruil.

Lees de huidige status en bevestig de selector

Vraag de service naar de status voordat je hem start, zodat je weet wat een geslaagde start moet veranderen:

scutil --nc status "Office VPN"

Als twee services dezelfde weergavenaam delen, is de naam dubbelzinnig. Geef in plaats daarvan de identificatie door; het commando accepteert beide, maar alleen de identificatie garandeert dat één service wordt gekozen. Controleer dat het statuswoord er een is dat je kent — meestal Connected, Disconnected, Connecting of Disconnecting — voordat je het in een script parseert. Controleer ook of het profiel wordt beheerd, want een vergrendelde configuratie kan het commando accepteren en het toch negeren of om bevestiging vragen.

Deze statusaanroep is goedkoop, dus gebruik hem als bewaker in automatisering: start alleen als de status Disconnected is, en behandel Connecting niet als een fout. Als de service al Connected is, sla de start over in plaats van een werkende tunnel te onderbreken.

Start de verbinding en wacht tot de status tot rust komt

Het startverzoek is asynchroon. Het commando keert terug wanneer het verzoek is geaccepteerd, niet wanneer de authenticatie is voltooid of routes zijn geïnstalleerd. Voer het uit, peil dan de status met een begrensde wachttijd en stop als de service terugvalt naar 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

Een Connecting-status die nooit wordt opgelost, wijst meestal op inloggegevens, MFA of de server, niet op scutil. Het commando kan geen interactieve login leveren, dus een profiel dat een token of een hardwaresleutel verwacht, blijft in Connecting hangen en valt uiteindelijk terug. Lees het statuswoord voordat je nieuwe pogingen toevoegt; een lus tegen een authenticatieprompt kan niet slagen.

Behandel de exitstatus van de shell niet als gereedheid. Het nuttige signaal is de statusstring, gevolgd door bewijs dat de tunnel verkeer draagt. Een startcommando dat stil terugkeert, kan je nog steeds achterlaten met een verbinding die nooit authenticeert.

Bewijs dat de tunnel verkeer draagt, niet alleen dat hij Connected zegt

Connected beschrijft de verbinding, niet de routeringsbeslissing. Native PPP- en IKEv2-services maken een ppp- of utun-interface en installeren routes, terwijl een gesplitste tunnel de standaardroute bewust ongemoeid laat. Inspecteer de interfaces en beide adresfamilies:

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

Vind de interface die de service heeft gemaakt in plaats van een nummer te gokken, en vraag dan de routingtabel welke interface een specifieke bestemming gebruikt: route -n get 10.0.0.10, met een interne host ervoor in de plaats. Als die de fysieke interface meldt, is de tunnel actief maar draagt hij die stroom niet. Controleer gesplitste tunnelroutes, de volgorde van resolvers en elke lokale firewallregel die de tunnelinterface toestaat maar niet het proces.

Naamresolutie is de gebruikelijke valse negatief. Interne namen kunnen via de verkeerde resolver worden opgelost terwijl de tunnel volledig gezond is, wat op een VPN-storing lijkt en het niet is. scutil --dns toont de volgorde die macOS zal gebruiken; na een resolverwijziging leeg je de cache met dscacheutil -flushcache en sudo killall -HUP mDNSResponder.

Houd inloggegevens en privileges buiten de opdrachtregel

Zet nooit een wachtwoord, een vooraf gedeelde sleutel of een token in de argumenten. Argumenten zijn zichtbaar in proceslijsten en belanden in de shellgeschiedenis, en een gekopieerd supporttranscript kan ze lekken. De eigen omgang van het profiel met inloggegevens — of dat een Keychain-item, een systeemprompt of de authenticatiestroom van de client is — is de plek voor geheimen.

Het commando met sudo uitvoeren maakt een interactieve login niet onbeheerd. Het verandert de effectieve gebruiker, niet de beschikbaarheid van een GUI-prompt, een hardwaretoken of de login-keychain. Een LaunchAgent kan een service starten nadat de gebruiker is ingelogd en de keychain is ontgrendeld; een LaunchDaemon bereikt die delen van de gebruikerssessie meestal niet. Als een organisatie de service beheert, winnen haar levenscyclusregels van elk lokaal script.

Stop de service en verifieer dat hij gestopt bleef

Stop met dezelfde selector die je voor de start gebruikte, en lees daarna de status opnieuw in plaats van aan te nemen dat de tunnel weg is:

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

Een stop die terugkeert naar Disconnected laat nog één ding te controleren: of het profiel is ingesteld om op verzoek te verbinden, wat het zonder jouw script kan terugbrengen. Als een andere client routes op dezelfde Mac bezit, kunnen die routes een native stop overleven. Controleer de route opnieuw voordat je concludeert dat de machine buiten de VPN staat.

Voor een wrapper die je met de hand uitvoert, houd de volgorde vast: lijst, status, start, peiling, routetest, stop, verificatie. Parse de vriendelijke naam niet uit vrije uitvoer wanneer de identificatie beschikbaar is, en behandel de exit van het startcommando niet als gereedheid. De verbindingsbeheerder rapporteert status; jouw bewijs is de status plus een route die naar de tunnel wijst.