Skriptet ditt starter VPN-en; det klargjør den ikke

Du skriver et skript som kjører scutil --nc start med navnet på tilkoblingen, det virker på din Mac, og det feiler på hver nyinstallert maskin på kontoret. Skriptet er ikke ødelagt. Det blir bedt om noe det aldri kunne: å starte en eksisterende tilkobling er ikke samme handling som å opprette en ny.

Klargjøring og sesjonsstyring er to arbeid med to eiere, og en arbeidsflyt som legger noe annet til grunn, vil klare hver test på maskinen der den ble skrevet.

Hva startkommandoen egentlig snakker med

En sesjonsstyringskommando henvender seg til en konfigurasjon som allerede finnes og allerede er godkjent. Den ber systemet om å reise den navngitte tilkoblingen, med serverinnstillingene, identitetsreferansene og regelen som ble lagret tidligere. Ble de aldri installert, er det ingenting å starte.

Derfor dukker feilen opp på ny maskinvare og ikke på den bærbare datamaskinen til administratoren. Den ble klargjort for måneder siden av en person som har glemt det siden. Tenk på startkommandoen som en dørklokke noen la ledninger til i forrige kvartal. Å trykke på den er ikke det samme som å legge ledningene.

Tre eiere av en VPN-konfigurasjon

En profil som organisasjonen styrer, kommer fra enhetsstyring. Profilen bærer serveradressene, ordningen for autentisering og regelen organisasjonen krever, og VPN-administratoren er personen som leverer dem. Et skript bør ikke bygge disse innstillingene på nytt fra et visningsnavn det fant i en liste.

En native personlig VPN-konfigurasjon lages via Apples Network Extension API, som dekker de innebygde IPsec- og IKEv2-protokollene. Det er et programgrensesnitt med et lagringstrinn og godkjenning fra brukeren, ikke en shell-kommando som stille lager hvilken som helst tunneltype en leverandør måtte levere.

En klient fra tredjepart er et tredje tilfelle med sitt eget importformat, sitt eget styringsverktøy og ofte sin egen privilegerte hjelper. Sesjonen er eid av prosessen til den leverandøren. Å finne en systemtjeneste med lignende navn er ikke bevis for at en systemkommando styrer tunnelen, og å legge det til grunn gir skript som ser ut til å virke til leverandøren oppdaterer klienten.

Native klargjøring har lagring og godkjenning

Apples modell er last inn, endre, lagre. Et program laster de eksisterende innstillingene før den første lagringen etter oppstart, endrer konfigurasjonen og lagrer den deretter. Lagringen rapporterer en feil når den ikke kan vedvare, og å overse det resultatet gjør en klargjøringsfeil om til en tilkoblingsfeil tre steg senere.

Den første lagringen krever også at brukeren godkjenner programmet. Det er en bevisst sikkerhetsgrense, og det betyr at den første kjøringen på en ny Mac er interaktiv selv når hver senere tilkobling og frakobling kan automatiseres. Planlegg den første kjøringen som en menneskelig oppgave med et menneske til stede. Automatiser den andre kjøringen og videre, og skriv det i runbooken så ingen lover det umulige. En utrullingsplan som lover en fullstendig overvåkningsløs første kjøring, lover noe plattformen ikke tilbyr.

Apple anbefaler også å validere serverkompatibilitet med en konfigurasjonsprofil før man stoler på API-et. Å gjøre den kontrollen først skiller «serveren godtar ikke denne klienten» fra «klienten lagret aldri innstillingene», som er ulike saker for ulike team.

Hva en gjentakbar startkommando kan legge til grunn

Etter klargjøringen kan et skript trygt rette seg mot den eksisterende tilkoblingen via grensesnittet til eieren. Gi det den stabile identiteten til tilkoblingen pluss handlingen du vil ha, og ikke noe annet. Det bør ikke lese en gjettet innstillingssti, og ikke legge til grunn at navnet i menyen er unikt i hele systemet.

For native tilkoblinger er en navngitt sesjonsforespørsel som scutil --nc start en styringshandling. Den installerer ikke serverinnstillinger, importerer ikke innloggingsdetaljer og utfører ikke autorisasjon av første lagring. Behandle den som det siste steget i en kjede, aldri som hele kjeden.

Hold hemmeligheter utenfor kommandolinjeargumenter og utenfor vanlig diagnostisk utdata. Hvilken identitetsmekanisme utrullingen enn valgte, er det den startkommandoen skal stole på, og et passord som er limt inn i shell-historikken er et funn i enhver gjennomgang.

To godkjenningstester

Den første kontrollen er klargjøring: ta en nyinstallert Mac og bevis at konfigurasjonen finnes, er eid av rett administrator og er fullt godkjent. Gjør det før du tester tilkoblingen, for en tilkoblingstest på en maskin som ikke er klargjort, beviser ingenting om skriptet.

Den andre kontrollen er sesjonen: koble til, nå den autoriserte ressursen og koble fra rent. Hver feil har nå en eier, og det er den praktiske fordelen med å dele de to arbeidene. En manglende profil er et leveringsproblem, en lagringsfeil er et godkjenningsproblem, en avvist innlogging er et autentiseringsproblem, og en timeout etter en vellykket start er sesjonslaget. Ingen av dem er «skriptet er ødelagt».