Begin ’n gestoorde Mac-VPN vanuit die terminaal met scutil --nc

Jy het ’n gestoorde VPN-diens in Stelselinstellings, en jy wil hê die terminaal moet dit begin. Op macOS is die ondersteunde pad scutil --nc, maar net vir dienste wat deur die stelsel se eie netwerkverbindingsbestuurder besit word. Die kieslysbalk is nie die API nie: derdeparty-kliënte het gewoonlik hul eie outomatisering, en ’n profiel wat deur ’n bestuurdienste gestuur is, kan ’n plaaslike begin weier. Dit is die kontrolelys wat ek volg: vind die presiese diens, lees sy toestand, begin dit, wag tot die toestand verander, en bewys dan dat verkeer werklik deur die tonnel gaan. Stop by die eerste stap wat nie klop nie, want elke latere opdrag aanvaar dat die een voor dit geslaag het.

Vind die diens voordat jy dit probeer begin

Begin met die inventaris eerder as die profielnaam wat jy onthou:

scutil --nc help
scutil --nc list

Elke reël paar ’n status met ’n diensidentifiseerder, ’n tipe en ’n vertoonnaam. Die identifiseerder is die waarde om vir scripte te gebruik, want vertoonname herhaal en kan gewysig word. Apple se scutil-handleiding dokumenteer die netwerkverbindingsmodus, terwyl die geïnstalleerde --nc help die gesaghebbende lys subopdragte op daardie Mac is; moenie aanvaar dat ’n vlag uit ’n ouer gids nog in jou macOS-weergawe bestaan nie.

’n Leë lys is ’n resultaat, nie ’n fout nie. ’n Diens wat deur ’n verskafferkliënt of ’n bestuurprofiel geskep is, kan aktief wees terwyl dit hier onsigbaar is, of sigbaar met ’n tipe wat die inheemse beheerder nie kan bestuur nie. In daardie geval, gebruik die verskaffer se hulpmiddel of die profieldokumentasie. Die skep van ’n parallelle inheemse profiel net om iets te hê om te begin, is ’n slegte ruil.

Lees die huidige toestand en bevestig die keuse

Vra die diens se toestand voordat jy dit begin, sodat jy weet wat ’n suksesvolle begin behoort te verander:

scutil --nc status "Office VPN"

As twee dienste dieselfde vertoonnaam deel, is die naam dubbelsinnig. Gee eerder die identifiseerder; die opdrag aanvaar albei, maar net die identifiseerder is gewaarborg om een diens te kies. Kontroleer dat die statuswoord een is wat jy herken — tipies Connected, Disconnected, Connecting of Disconnecting — voordat jy dit in ’n script ontleed. Kontroleer ook of die profiel bestuur word, want ’n geslote konfigurasie kan die opdrag aanvaar en dit steeds ignoreer of om bevestiging vra.

Hierdie toestandoproep is goedkoop, so gebruik dit as die wag in outomatisering: begin net wanneer die status Disconnected is, en moenie Connecting as ’n fout beskou nie. As die diens reeds Connected is, slaan die begin oor eerder as om ’n werkende tonnel te onderbreek.

Begin die verbinding en wag tot die toestand bedaar

Die beginversoek is asinkroon. Die opdrag keer terug wanneer die versoek aanvaar is, nie wanneer verifikasie klaar is of roetes geïnstalleer is nie. Voer dit uit en peil dan die toestand met ’n begrensde wag en stop as die diens terugval na 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

’n Status van Connecting wat nooit oplos nie, dui gewoonlik op geloofsbriewe, MFA of die bediener, nie op scutil nie. Die opdrag kan nie ’n interaktiewe aanmelding verskaf nie, so ’n profiel wat ’n token of ’n hardeware-sleutel verwag, sal in Connecting sit en uiteindelik terugval. Lees die statuswoord voordat jy herproberings byvoeg; ’n lus teen ’n verifikasie-oproep kan nie slaag nie.

Moenie die skulp se afsluitstatus as gereedheid beskou nie. Die nuttige sein is die toestandstring, gevolg deur bewys dat die tonnel verkeer dra. ’n Beginopdrag wat stil terugkeer, kan jou steeds met ’n verbinding laat wat nooit verifieer nie.

Bewys dat die tonnel verkeer dra, nie net dat dit Connected sê nie

Connected beskryf die verbinding, nie die roetebesluit nie. Inheemse PPP- en IKEv2-dienste skep ’n ppp- of utun-koppelvlak en installeer roetes, terwyl ’n verdeelde tonnel die verstekroete doelbewus alleen laat. Ondersoek die koppelvlakke en beide adresfamilies:

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

Vind die koppelvlak wat die diens geskep het eerder as om ’n nommer te raai, en vra dan die roetebestuurder watter koppelvlak ’n spesifieke bestemming gebruik: route -n get 10.0.0.10, met ’n interne gasheer in die plek daarvan. As dit die fisiese koppelvlak rapporteer, is die tonnel op maar dra dit nie daardie vloei nie. Kontroleer verdeelde-tonnel-roetes, resolver-volgorde en enige plaaslike firewall-reël wat die tonnelkoppelvlak toelaat maar nie die proses nie.

Naamresolusie is die gewone valse negatief. Interne name kan deur die verkeerde resolver opgelos word terwyl die tonnel heeltemal gesond is, wat soos ’n VPN-fout lyk en nie een is nie. scutil --dns wys die volgorde wat macOS sal gebruik; spoel na ’n resolver-verandering die kas uit met dscacheutil -flushcache en sudo killall -HUP mDNSResponder.

Hou geloofsbriewe en voorregte uit die opdraglyn

Moenie ooit ’n wagwoord, vooraf-gedeelde sleutel of token in die argumente sit nie. Argumente is sigbaar in proseslyste en beland in skulphistorie, en ’n gekopieerde ondersteuningsverslag kan dit lek. Die profiel se eie geloofsbriefhantering, of dit ’n Keychain-item, ’n stelsel-oproep of die kliënt se verifikasievloei is, is die plek vir geheime.

Om die opdrag met sudo te laat loop, maak nie ’n interaktiewe aanmelding onbewaak nie. Dit verander die effektiewe gebruiker, nie die beskikbaarheid van ’n GUI-oproep, ’n hardeware-token of die aanmeld-sleutelring nie. ’n LaunchAgent kan ’n diens begin nadat die gebruiker aangemeld het en die sleutelring ontsluit is; ’n LaunchDaemon kan gewoonlik nie daardie gebruikersessie-dele bereik nie. As ’n organisasie die diens bestuur, wen sy lewensiklusreëls bo enige plaaslike script.

Stop die diens en verifieer dat dit gestop gebly het

Stop met dieselfde keuse wat jy gebruik het om te begin, en lees dan die toestand terug eerder as om aan te neem die tonnel is weg:

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

’n Stop wat na Disconnected terugkeer, laat nog een ding om te kontroleer: of die profiel op aanvraag verbind, wat dit sonder jou script kan terugbring. As ’n ander kliënt roetes op dieselfde Mac besit, kan daardie roetes ’n inheemse stop oorleef. Herhaal die roetekontrole voordat jy aflei dat die masjien van die VPN af is.

Vir ’n omhulsel wat jy met die hand laat loop, hou die volgorde vas: lys, status, begin, peil, roetetoets, stop, verifieer. Moenie die vriendelike naam uit vrye-vorm-uitset ontleed wanneer die identifiseerder beskikbaar is nie, en moenie die beginopdrag se afsluit as gereedheid beskou nie. Die verbindingsbestuurder rapporteer toestand; jou bewys is die toestand plus ’n roete wat na die tonnel wys.