Je script start de VPN; het richt die niet in

Je schrijft een script dat scutil --nc start uitvoert met de naam van de verbinding, het werkt op je Mac, en het faalt op elke vers geïnstalleerde machine op kantoor. Het script is niet kapot. Er wordt iets van gevraagd wat het nooit kon: een bestaande verbinding starten is niet dezelfde handeling als een nieuwe aanmaken.

Inrichten en sessiebeheer zijn twee taken met twee eigenaren, en een werkstroom die het tegendeel aanneemt, slaagt voor elke test op de machine waarop hij is geschreven.

Waar het startcommando werkelijk mee praat

Een sessiebeheercommando richt zich tot een configuratie die al bestaat en al is goedgekeurd. Het vraagt het systeem die genoemde verbinding op te brengen, met de serverinstellingen, identiteitsverwijzingen en het beleid die eerder zijn opgeslagen. Zijn die nooit geïnstalleerd, dan is er niets om te starten.

Daarom verschijnt de fout op nieuwe hardware en niet op de laptop van de beheerder. De laptop is maanden geleden ingericht door iemand die dat inmiddels is vergeten. Zie het startcommando als een deurbel waar iemand vorig kwartaal draden naartoe heeft getrokken. Ertegen drukken is niet hetzelfde als de bedrading aanleggen.

Drie eigenaren van een VPN-configuratie

Een profiel dat door de organisatie wordt beheerd, komt uit apparaatbeheer. Het profiel bevat de serveradressen, de authenticatieopzet en het beleid dat de organisatie eist, en de VPN-beheerder is de persoon die ze levert. Een script zou die instellingen niet moeten reconstrueren uit een weergavenaam die het in een lijst vond.

Een native persoonlijke VPN-configuratie wordt gemaakt via de Network Extension API van Apple, die de ingebouwde IPsec- en IKEv2-protocollen dekt. Dat is een applicatie-interface met een opslagstap en goedkeuring door de gebruiker, geen shell-commando dat stil elk tunneltype aanmaakt dat een leverancier levert.

Een client van een derde partij is een derde geval met een eigen importformaat, een eigen beheertool en vaak een eigen bevoorrechte helper. De sessie is eigendom van het proces van die leverancier. Een systeemservice met een vergelijkbare naam vinden is geen bewijs dat een systeemcommando de tunnel bestuurt, en dat aannemen levert scripts op die lijken te werken tot de leverancier de client bijwerkt.

Native inrichting heeft een opslag en een goedkeuring

Het model van Apple is laden, wijzigen, opslaan. Een applicatie laadt de bestaande voorkeuren vóór de eerste opslag na het starten, wijzigt de configuratie en slaat die daarna op. De opslag meldt een fout wanneer hij niet kan bewaren, en dat resultaat negeren maakt van een inrichtingsfout drie stappen later een verbindingsfout.

De eerste opslag vereist ook dat de gebruiker de applicatie goedkeurt. Dat is een bewuste beveiligingsgrens, en het betekent dat de eerste run op een nieuwe Mac interactief is, ook al kan elke latere verbinding en verbreking worden geautomatiseerd. Plan de eerste run als een menselijke taak met een mens erbij. Automatiseer de tweede run en verder, en schrijf dat in de runbook zodat niemand het onmogelijke belooft. Een uitrolplan dat een volledig onbeheerde eerste run belooft, belooft iets wat het platform niet biedt.

Apple raadt ook aan de servercompatibiliteit met een configuratieprofiel te valideren voordat je op de API vertrouwt. Die controle eerst doen scheidt «de server accepteert deze client niet» van «de client heeft de instellingen nooit opgeslagen», en dat zijn verschillende tickets voor verschillende teams.

Wat een herhaalbaar startcommando mag aannemen

Na de inrichting kan een script veilig de bestaande verbinding benaderen via de interface van de eigenaar. Geef het de stabiele identiteit van de verbinding plus de actie die je wilt, en niets anders. Het zou geen geraden voorkeurspad moeten lezen, en niet moeten aannemen dat de naam in het menu uniek is in het hele systeem.

Voor native verbindingen is een benoemd sessieverzoek zoals scutil --nc start een besturingshandeling. Het installeert geen serverinstellingen, importeert geen inloggegevens en voert geen autorisatie van de eerste opslag uit. Behandel het als de laatste stap van een keten, nooit als de hele keten.

Houd geheimen buiten commandoregelargumenten en buiten gewone diagnostische uitvoer. Welk identiteitsmechanisme de uitrol ook koos, daarop moet het startcommando vertrouwen, en een wachtwoord dat in de shell-geschiedenis is geplakt, is een bevinding in elke review.

Twee acceptatiecontroles

De eerste controle is de inrichting: neem een vers geïnstalleerde Mac en bewijs dat de configuratie aanwezig is, eigendom is van de juiste beheerder en volledig is goedgekeurd. Doe dat voordat je de verbinding test, want een verbindingstest op een niet-ingerichte machine bewijst niets over het script.

De tweede controle is de sessie: verbind, bereik de geautoriseerde resource en verbreek netjes. Elke fout heeft nu een eigenaar, en dat is het praktische voordeel van het splitsen van de twee taken. Een ontbrekend profiel is een leveringsprobleem, een opslagfout is een goedkeuringsprobleem, een geweigerde login is een authenticatieprobleem, en een time-out na een geslaagde start is de sessielaag. Geen daarvan is «het script is kapot».