Un perfil VPN no se importa en macOS: lea primero la carga útil

Cuando un perfil se instala sin problemas en un Mac y se rechaza en otro, la red aún no se ha alcanzado, así que los certificados, las puertas de enlace y las contraseñas no tienen ninguna culpa. El instalador se detuvo en una carga útil que no quiso aceptar, y normalmente registra cuál. Eso deja el archivo del perfil y todo lo que lo generó como los únicos lugares sensatos donde trabajar, y convierte borrar los ajustes del cliente en una forma de destruir pruebas en lugar de una reparación.

Lea el perfil en vez de reiniciar el Mac

Exporte el .mobileconfig y mire qué contiene realmente antes de tocar el cliente:

plutil -p profile.mobileconfig | head -60

Un perfil VPN son en realidad dos cargas útiles con trabajos distintos: com.apple.vpn.managed contiene la conexión y com.apple.dnsSettings.managed contiene la configuración del resolutor. La instalación se detiene en la primera carga útil que el instalador rechaza, y el rechazo llega al registro del sistema con esa carga útil nombrada, así que es el registro el que le dice qué sección abrir. Guarde una copia del último perfil que sí se importó, porque ese archivo es la base con la que se mide su diferencia.

Lo que el generador añadió en silencio

Apple Configurator 2.15, compilación 7A23, emitió el siguiente bloque dentro de su carga útil de DNS:

<key>DNS</key>
<dict>
  <key>SupplementalMatchDomainsNoSearch</key>
  <integer>0</integer>
</dict>

En macOS 12.1, los perfiles escritos por esa compilación se rechazaron al importarlos. Una conexión creada con Configurator 2.11.1 entró sin queja, porque esa versión nunca escribía la clave. Elimine todo el diccionario de DNS o solo la clave problemática, vuelva a guardarlo y luego reintente en la misma máquina antes de cambiar cualquier otra cosa. Esa única edición suele ser toda la reparación.

La herramienta tiene una trampa que conviene conocer antes de confiar en ella. Una vez borrada la clave, guardar la misma conexión no la devolvió, y solo reapareció cuando se creó una conexión desde cero. Trate cada perfil recién generado como sospechoso e inspecciónelo, sobre todo cuando se hizo toda una tanda de conexiones de una vez.

La vía MDM falla en otro lugar

Un servicio de gestión que empuja el mismo perfil puede fallar en otro punto: el cliente se queja de que no se creó ningún servicio VPN. En el caso notificado, una carga útil configurada para autenticación por certificado exigía aun así un campo de contraseña; rellenarlo con un marcador permitió aplicar el perfil, y nada usó nunca ese valor para autenticar.

Si toma esa vía, guarde una cadena ficticia y nunca una credencial real, y mantenga el secreto auténtico fuera del cuerpo del perfil. Un perfil con una contraseña que funciona se convierte en un archivo que hay que proteger como una clave, y eso es un problema mucho mayor que la importación fallida con la que empezó. Decida quién es dueño de ese marcador antes de distribuir el perfil, para que nadie lo confunda después con un valor que merece rotarse. Documentar por qué existe cuesta una línea y ahorra una discusión dentro de seis meses.

Confirme que el perfil ha llegado de verdad

Una importación correcta no es un servicio en marcha, así que compruebe en este orden:

profiles show -type configuration
scutil --nc list
scutil --nc start "Your VPN Service"
scutil --nc status "Your VPN Service"
scutil --dns | head -20

El primer comando lista las cargas útiles instaladas; el segundo dice si existe algún servicio VPN. El último, ejecutado tras conectar, muestra el resolutor que el sistema usará realmente. Léalos en ese orden y deténgase donde se rompe la cadena, porque un servicio ausente hace que cualquier pregunta sobre el resolutor no tenga sentido. Un perfil puede figurar como instalado y no poseer nada utilizable, y ese es justo el estado que esta secuencia está diseñada para exponer.

Si el túnel se levanta mientras una entrada de servicio sigue sin nombre utilizable, el campo de nombre visible se perdió en la exportación, y la cura es un perfil regenerado y no un cambio de nombre en el cliente. Si el resolutor sigue apuntando al local, la carga útil de DNS se eliminó con más profundidad de la que pretendía.

Despliegue por etapas, un Mac cada vez

Instale en un Mac gestionado con la misma compilación del sistema, y luego compruebe tres cosas por separado: el servicio aparece, el resolutor cambia y una petición interna real tiene éxito. Solo después de las tres debe ampliarse el alcance.

Son tres resultados distintos que fallan de tres maneras distintas, y eso es lo que hace que una máquina de prueba valga los diez minutos. Un perfil que se importa no es un perfil que funciona, y la máquina de la primera etapa atrapa ambos tipos de fallo antes de que el resto del parque vea ninguno.