El teu script inicia la VPN; no la prepara

Escrius un script que executa scutil --nc start amb el nom de la connexió, funciona al teu Mac i falla a cada màquina recentment imatgejada de l'oficina. El script no està trencat. Se li demana una cosa que mai no ha pogut fer: iniciar una connexió existent no és la mateixa operació que crear-ne una.

L'aprovisionament i el control de sessió són dues feines amb dos propietaris, i un flux de treball que assumeixi el contrari passarà totes les proves a la màquina on es va escriure.

Amb què parla realment l'ordre d'inici

Una ordre de control de sessió s'adreça a una configuració que ja existeix i que ja està aprovada. Demana al sistema que aixequi aquesta connexió anomenada, fent servir la configuració del servidor, les referències d'identitat i la política desades abans. Si aquestes mai no es van instal·lar, no hi ha res per iniciar.

Per això la fallada apareix en maquinari nou i no a l'ordinador portàtil de l'administrador. L'ordinador es va aprovisionar fa mesos per una persona que des de llavors ha oblidat que ho va fer. Pensa en l'ordre d'inici com un timbre que algú va cablejar el trimestre passat. Prémer-lo no és el mateix que instal·lar el cablejat.

Tres propietaris d'una configuració de VPN

Un perfil gestionat per l'organització prové de la gestió de dispositius. El perfil porta les adreces del servidor, la disposició d'autenticació i la política que l'organització requereix, i l'administrador de VPN és la persona que les subministra. Un script no hauria de reconstruir aquests paràmetres a partir d'un nom de visualització que ha trobat en una llista.

Una configuració de VPN personal nativa es crea mitjançant l'API Network Extension d'Apple, que cobreix els protocols IPsec i IKEv2 integrats. És una interfície d'aplicació amb un pas de desament i una aprovació de l'usuari, no una ordre d'intèrpret que crea en silenci qualsevol tipus de túnel que un proveïdor distribueixi.

Un client de tercers és un tercer cas amb el seu propi format d'importació, la seva pròpia eina de gestió i sovint el seu propi assistent amb privilegis. La seva sessió pertany al procés d'aquell proveïdor. Trobar un servei del sistema amb un nom semblant no és prova que una ordre del sistema controli el túnel, i assumir-ho produeix scripts que semblen funcionar fins que el proveïdor actualitza el client.

L'aprovisionament natiu té un desament i una aprovació

El model d'Apple és carregar, modificar, desar. Una aplicació carrega les preferències existents abans del seu primer desament després d'iniciar-se, canvia la configuració i després la desa. El desament informa d'un error quan no pot persistir, i ignorar aquest resultat converteix una fallada d'aprovisionament en una fallada de connexió tres passos més enllà.

El primer desament també requereix que l'usuari aprovi l'aplicació. És una frontera de seguretat deliberada, i significa que la primera execució en un Mac nou és interactiva encara que totes les connexions i desconnexions posteriors es puguin automatitzar. Planifica la primera execució com una tasca humana amb una persona present. Automatitza la segona execució i les següents, i digues-ho al runbook perquè ningú no prometi l'impossible. Un pla de desplegament que promet una primera execució totalment desatesa promet una cosa que la plataforma no ofereix.

Apple també recomana validar la compatibilitat del servidor amb un perfil de configuració abans de confiar en l'API. Fer aquesta comprovació primer separa «el servidor no acceptarà aquest client» de «el client mai no ha desat la configuració», que són tiquets diferents per a equips diferents.

Què pot assumir una ordre d'inici repetible

Després de l'aprovisionament, un script pot adreçar-se amb seguretat a la connexió existent mitjançant la interfície del seu propietari. Dóna-li la identitat estable de la connexió més l'acció que vols, i res més. No hauria de llegir un camí de preferències endevinat, ni assumir que el nom mostrat al menú és únic a tot el sistema.

Per a connexions natives, una petició de sessió amb nom com scutil --nc start és una operació de control. No instal·la la configuració del servidor, no importa credencials ni fa l'autorització del primer desament. Tracta-la com l'últim pas d'una cadena, mai com la cadena sencera.

Mantingues els secrets fora dels arguments de la línia d'ordres i de la sortida de diagnòstic habitual. El mecanisme d'identitat que triï el desplegament és el que ha de fer servir l'ordre d'inici, i una contrasenya enganxada a l'historial de l'intèrpret és una troballa en qualsevol revisió.

Dues comprovacions d'acceptació

La primera comprovació és l'aprovisionament: agafa un Mac acabat d'imatgejar i demostra que la configuració hi és, que la posseeix el gestor correcte i que està plenament aprovada. Fes-ho abans de provar la connectivitat, perquè una prova de connexió en una màquina no aprovisionada no demostra res sobre el script.

La segona comprovació és la sessió: connecta, arriba al recurs autoritzat i desconnecta netament. Ara cada fallada té un propietari, i aquest és el benefici pràctic de separar les dues feines. Un perfil absent és un problema de lliurament, un error de desament és un problema d'aprovació, un inici de sessió rebutjat és un problema d'autenticació, i un temps d'espera després d'un inici correcte és la capa de sessió. Cap d'ells no és «el script està trencat».