Un perfil VPN non se importa en macOS: lea primeiro a carga útil
Un perfil rexeitado nun Mac e aceptado noutro adoita ser un problema de carga útil. Compare o XML, revise que engadiu o xerador e despois verifique o servizo.
Cando un perfil se instala sen problemas nun Mac e se rexeita noutro, a rede aínda non se alcanzou, así que os certificados, as pasarelas e os contrasinais non teñen ningunha culpa. O instalador detívose nunha carga útil que non quixo aceptar, e normalmente rexistra cal. Iso deixa o ficheiro do perfil e todo o que o xerou como os únicos lugares sensatos onde traballar, e converte borrar os axustes no cliente nunha forma de destruír probas en lugar dunha reparación.
Lea o perfil en vez de reiniciar o Mac
Exporte o .mobileconfig e mire que contén realmente antes de tocar o cliente:
plutil -p profile.mobileconfig | head -60
Un perfil VPN son en realidade dúas cargas útiles con traballos distintos: com.apple.vpn.managed contén a conexión e com.apple.dnsSettings.managed contén a configuración do resolutor. A instalación detense na primeira carga útil que o instalador rexeita, e o rexeitamento chega ao rexistro do sistema con esa carga útil nomeada, así que é o rexistro quen lle di que sección abrir. Garde unha copia do último perfil que si se importou, porque ese ficheiro é a base coa que se mide a súa diferenza.
O que o xerador engadiu en silencio
Apple Configurator 2.15, compilación 7A23, emitiu o seguinte bloque dentro da súa carga útil de DNS:
<key>DNS</key>
<dict>
<key>SupplementalMatchDomainsNoSearch</key>
<integer>0</integer>
</dict>
En macOS 12.1, os perfís escritos por esa compilación rexeitáronse ao importalos. Unha conexión creada con Configurator 2.11.1 entrou sen queixa, porque esa versión nunca escribía a clave. Elimine todo o dicionario de DNS ou só a clave problemática, volva gardalo e despois reintente na mesma máquina antes de cambiar calquera outra cousa. Esa única edición adoita ser toda a reparación.
A ferramenta ten unha trampa que convén coñecer antes de confiar nela. Unha vez borrada a clave, gardar a mesma conexión non a devolveu, e só reapareceu cando se creou unha conexión desde cero. Trate cada perfil recentemente xerado como sospeitoso e inspeccióneo, sobre todo cando se fixo toda unha quenda de conexións dunha vez.
A vía MDM falla noutro lugar
Un servizo de xestión que empurra o mesmo perfil pode fallar noutro punto: o cliente quéixase de que non se creou ningún servizo VPN. No caso notificado, unha carga útil configurada para autenticación por certificado esixía aínda así un campo de contrasinal; enchedalo cun marcador permitiu aplicar o perfil, e nada usou nunca ese valor para autenticar.
Se toma esa vía, garde unha cadea ficticia e nunca unha credencial real, e manteña o secreto auténtico fóra do corpo do perfil. Un perfil cun contrasinal que funciona convértese nun ficheiro que hai que protexer como unha clave, e iso é un problema moito maior que a importación fallida coa que empezou. Decida quen é o dono dese marcador antes de distribuír o perfil, para que ninguén o confunda despois cun valor que merece rotarse. Documentar por que existe custa unha liña e aforra unha discusión dentro de seis meses.
Confirme que o perfil chegou de verdade
Unha importación correcta non é un servizo en marcha, así que comprobe nesta orde:
profiles show -type configuration
scutil --nc list
scutil --nc start "Your VPN Service"
scutil --nc status "Your VPN Service"
scutil --dns | head -20
O primeiro comando lista as cargas útiles instaladas; o segundo di se existe algún servizo VPN. O último, executado tras conectar, mostra o resolutor que o sistema usará realmente. Lea os dous na devandita orde e detéñase onde se rompe a cadea, porque un servizo ausente fai que calquera pregunta sobre o resolutor non teña sentido. Un perfil pode figurar como instalado e non posuír nada utilizable, e ese é xustamente o estado que esta secuencia está deseñada para expor.
Se o túnel se levanta mentres unha entrada de servizo segue sen nome utilizable, o campo do nome visible perdeuse na exportación, e a cura é un perfil rexenerado e non un cambio de nome no cliente. Se o resolutor segue apuntando ao local, a carga útil de DNS eliminouse con máis profundidade do que pretendía.
Despregue por etapas, un Mac cada vez
Instale nun Mac xestionado coa mesma compilación do sistema, e despois comprobe tres cousas por separado: o servizo aparece, o resolutor cambia e unha petición interna real ten éxito. Só despois das tres debe ampliarse o alcance.
Son tres resultados distintos que fallan de tres maneiras distintas, e iso é o que fai que unha máquina de proba valga os dez minutos. Un perfil que se importa non é un perfil que funciona, e a máquina da primeira etapa atrapa ambos os dous tipos de fallo antes de que o resto do parque vexa ningún.