Planificar Wi-Fi, certificados, VPN y proxy de Apple con Sophos Mobile

Ámbito: Sophos Mobile en Sophos Fusion (antes Sophos Central), iPhone y iPad con iOS/iPadOS. Esta orientación distingue las políticas de dispositivo iOS (Device Policy) de las políticas de usuario iOS (User Policy). No es una configuración paso a paso probada para un tenant concreto, ni una guía de macOS, ni una autorización para un despliegue masivo en producción. Compruebe primero en el dispositivo de destino la versión del sistema operativo, el modo de inscripción, la supervisión (Supervision), el tipo de política y las funciones disponibles en su tenant.

⚠️ No interrumpa la conexión: Un certificado Wi-Fi/EAP incorrecto, una CA SCEP inaccesible, un PAC/WPAD defectuoso o un túnel VPN pueden cortar también el canal de retorno de las tareas MDM. Antes de modificar nada, verifique una conexión independiente del perfil que se va a cambiar y una vía local para resolver incidencias. Un rollback guardado en la consola no llega automáticamente a un dispositivo aislado sin conexión.

Distinga primero el modo de gestión

Device Enrollment no implica automáticamente supervisión: Automated Device Enrollment supervisa el dispositivo, pero otros métodos no necesariamente. Apple User Enrollment nunca lo supervisa y afecta a los datos gestionados, no a todo el dispositivo privado. En BYOD, la cuenta Managed Apple Account y el consentimiento forman parte de los requisitos previos. En ese caso no hay proxy HTTP global ni VPN convencional para todo el dispositivo, ni ajustes de proxy en la configuración Wi-Fi gestionada; Sophos no puede consultar MAC/UDID/IMEI para la identificación NAC.

Sophos limita el User Enrollment basado en perfiles a iOS/iPadOS 17 o versiones anteriores; esto no equivale a la eliminación general del User Enrollment account-driven. Al cancelar la inscripción se eliminan del dispositivo el volumen APFS gestionado y la cuenta Managed Apple Account gestionada; eso no constituye un rollback general de Wi-Fi o VPN. Apple describe la VPN por aplicación como una función posible de User Enrollment, no como prueba de que exista una vía funcional para asignar aplicaciones en Sophos.

Planifique conjuntamente Wi-Fi y la cadena de certificados

Aísle el piloto BYOD antes de cada cambio: En las políticas de usuario de iOS/iPadOS, Sophos sincroniza los cambios automáticamente cada vez que el dispositivo vuelve a conectarse a Sophos Mobile; no es necesario ejecutar Update devices manualmente. Por ello, utilice una política de usuario independiente, asignada únicamente al dispositivo BYOD de prueba autorizado, y compruebe sus asignaciones actuales y el número de dispositivos destinatarios antes de editarla y antes de pulsar Save. No modifique para el piloto una política ya compartida con dispositivos BYOD en producción. Asignarla después a dispositivos de prueba seleccionados no limita la sincronización del cambio en otros dispositivos que ya tengan asignada esa misma política. Esta regla de alcance también se aplica a los cambios de certificados y a las correcciones durante la reversión; la sincronización por sí sola no confirma ni el funcionamiento de la red ni la vía de retorno MDM.

¿Quién verifica a quién? En una red Wi-Fi empresarial con EAP (autenticación entre el dispositivo y la red), el dispositivo verifica el nombre y la cadena de certificados del servidor RADIUS. Con autenticación basada en certificados, RADIUS verifica a su vez la identidad de cliente emitida. Por tanto, la CA del servidor y la identidad de cliente cumplen funciones distintas. La opción Identity certificate de la configuración Wi-Fi requiere una configuración Client certificate en la misma política; el certificado de servidor de Trusted certificates requiere una configuración Root certificate en esa política.

Solo marcadores ficticios; no los reutilice: radius.test.invalid como nombre del servidor, Test-CA como CA de servidor de confianza y CN=Testperson,OU=Pilot,O=Beispiel como subject X.500 (campos de la identidad de cliente). Sustituya todos los valores por los nombres, la CA y los campos de identidad confirmados por su equipo de PKI/RADIUS. Compruebe en el dispositivo de prueba que la identidad de servidor configurada coincide con la cadena real y que RADIUS acepta el certificado de cliente emitido. El certificado raíz es un certificado X.509 en formato PEM/DER; un certificado de cliente importado es PKCS#12 (.pfx). Cargar un .pfx no implica que pueda reutilizarse automáticamente en varias políticas: si necesita el certificado de cliente en otra política, debe volver a cargarlo en ella. Compruebe la procedencia de la CA, la titularidad de la clave, la validez y el uso previsto. Cargar una CA raíz no demuestra que todas las aplicaciones confíen en ella.

Para Root certificate en una política de dispositivo iOS, abra la configuración en Edit policy mediante Add configuration > Root certificate. Seleccione el archivo X.509 en formato PEM/DER con Upload a file y ábralo con Open. Tras la carga, Certificate name muestra el Distinguished Name (DN) del emisor, no la identidad de cliente. Guarde la configuración con Apply y, después, guarde la política con Save en Edit policy. Según Sophos, asignar la política instala el certificado raíz cargado en el dispositivo. Ni la indicación ni el guardado por sí solos demuestran confianza, validez ni una instalación correcta. Cada certificado raíz adicional requiere su propia configuración Root certificate en la misma política.

Para Root certificate en una política de usuario iOS, Sophos describe la importación en Edit policy mediante Add configuration > Root certificate. Seleccione el archivo X.509 en formato PEM/DER con Upload a file y ábralo con Open. Tras la carga, Certificate name muestra el Distinguished Name del emisor. Guarde la configuración con Apply y, después, guarde la política con Save en Edit policy. Añada una configuración Root certificate independiente para cada certificado raíz adicional. Según Sophos, asignar la política de usuario instala el certificado en el dispositivo; dentro de la misma política puede utilizarse, por ejemplo, como certificado de servidor EAP en Wi-Fi. Ni la indicación de carga ni la política guardada demuestran una instalación correcta, confianza en el certificado o una autenticación Wi-Fi funcional.

En la configuración Client certificate de la política de dispositivo iOS, seleccione primero Upload a file en File y después el archivo de certificado PKCS#12 (.pfx). En Certificate name, Sophos Mobile muestra el nombre leído del archivo de certificado. Ese nombre por sí solo no demuestra que el certificado sea de confianza, que sea válido ni que se haya instalado correctamente.

Antes de configurar SCEP: Si utiliza la conexión SCEP configurada en Sophos setup con las variables indicadas más abajo, revise primero el procedimiento de requisitos y certificados SCEP: accesibilidad de la CA desde Sophos Fusion, aperturas de firewall limitadas a la región correspondiente y, para esta vía documentada con una CA de Windows, una cuenta autorizada para generar challenges e inscribir certificados. Antes de configurar SCEP, incorpore el certificado de la CA del servidor SCEP como Root certificate en la misma política. Esta confianza en el servidor es distinta de la confianza en el servidor RADIUS y de la identidad de cliente emitida; esto no implica que Windows sea un requisito de toda implementación SCEP directa.

SCEP (Simple Certificate Enrollment Protocol) permite que un dispositivo solicite un certificado a la CA. Para ello se necesita una URL de CA accesible o la variable de proxy SCEP de Sophos correctamente configurada. Pida al equipo de PKI que ajuste a su CA los campos subject X.500 y SAN/UPN (nombres de identidad adicionales), el challenge, los parámetros de reintento para solicitudes pendientes, la longitud de clave y los bits de uso. Para la configuración SCEP de una política de dispositivo iOS, son importantes estas decisiones:

• Punto de conexión y nombre de la CA: URL es la dirección web del servidor CA. %_SCEPPROXYURL_% remite a la URL del servidor en la pestaña SCEP de la página Sophos setup. CA name es un nombre que la CA reconoce; puede servir, por ejemplo, para distinguir instancias de CA. Confirme con el equipo de PKI el nombre que espera su CA. Este campo no es la indicación Certificate name de un certificado importado ni el nombre de ejemplo de la CA de confianza del servidor RADIUS.
• Identidad de usuario o de dispositivo: Subject puede contener marcadores para datos del usuario o propiedades del dispositivo. Sophos indica CN=%_USERNAME_% para un usuario y CN=%_DEVPROP(SerialNumber)_% para un iPhone o iPad. Son ejemplos de sintaxis documentados, no valores comprobados para su tenant. Acuerde la identidad deseada con el equipo de PKI y compruebe que los datos estén disponibles y que el subject resultante de sustituir los marcadores sea un nombre X.500 válido. BYOD: Un marcador de número de serie documentado no demuestra que User Enrollment pueda resolver una identidad basada en el número de serie; Sophos no puede consultar allí los identificadores del dispositivo. Compruebe el subject y la emisión con una persona de prueba.
• Tipo y valor del SAN: En Type of Subject Alternative Name, seleccione el tipo aprobado por el equipo de PKI e introduzca el valor correspondiente en Value of Subject Alternative Name. RFC 822 name designa una dirección de correo electrónico válida. Para esta configuración SCEP de iOS, Sophos describe DNS name como el nombre DNS del servidor CA y Uniform resource identifier como su URL completa; no como el nombre del servidor RADIUS ni como la dirección del challenge. AD user logon name es un campo distinto que designa el UPN definido en Active Directory. Challenge es la dirección web desde la que el dispositivo obtiene una contraseña de challenge del servidor SCEP. %_CACHALLENGE_% remite a la URL de challenge configurada en la pestaña SCEP de la página Sophos setup, no a la contraseña en sí. No incluya secretos reales en ejemplos públicos ni en tickets.
• Solicitudes pendientes: Retries establece el número de reintentos cuando el servidor responde con pending; no es un contador general de reintentos para todos los errores de red. Retry delay es el intervalo entre esos intentos, en segundos. Acuerde el número y el intervalo con el equipo de PKI; no los confunda con la renovación del certificado.
• Clave y uso previsto: Key size designa el tamaño de la clave pública del certificado emitido y debe coincidir con el tamaño configurado en el servidor SCEP. Certificate usage establece el uso permitido: Use as digital signature para firmas digitales y Use for encryption para cifrado de datos. La selección debe corresponder a las especificaciones de PKI y al servicio de destino; no demuestra una autenticación Wi-Fi/VPN correcta ni el cifrado de todo el tráfico del dispositivo.

Al crear la política existe el campo SCEP renewal interval. Revise con el equipo de PKI el intervalo, la caducidad, la revocación y la sustitución; definir un intervalo no garantiza ni la renovación correcta ni la recuperación de un dispositivo que haya quedado sin conexión.

Sustitución de identidad en las políticas de dispositivo y de usuario: En el ejemplo anterior CN=%_USERNAME_%, %_USERNAME_% se sustituye por Exchange Login del usuario asignado al dispositivo, no necesariamente por su nombre para mostrar ni automáticamente por el UPN de AD. Antes de asignar la política, compruebe la asignación del usuario y el valor de esta propiedad; el subject resultante debe seguir siendo un nombre X.500 válido y aprobado por el equipo de PKI. AD user logon name sigue siendo el campo UPN independiente.

Para SCEP en una política de usuario iOS, defina los extremos por separado. URL es la dirección web del servidor CA. La variable %_SCEPPROXYURL_% remite a la URL del servidor en la pestaña SCEP de la página Sophos setup. Challenge es la URL para obtener una contraseña de challenge del servidor SCEP, no la contraseña en sí. %_CACHALLENGE_% remite a la URL de challenge configurada en esa pestaña SCEP. Al igual que en los parámetros de solicitud descritos arriba, Retries solo cuenta los reintentos tras una respuesta pending; Retry delay indica el intervalo entre ellos en segundos. Key size debe coincidir con el tamaño de clave pública configurado en el servidor SCEP. Confirme estos parámetros con el equipo de PKI; no son intervalos de renovación ni demuestran una emisión correcta.

Wi-Fi empresarial y dirección Wi-Fi privada

Para un piloto Wi-Fi de dispositivo aislado, el siguiente procedimiento conecta los ajustes de red con la asignación de la política. Asegure antes las vías independientes de red y de retorno descritas en la sección del piloto; no edite una política asignada en producción.

1. En Policies, abra la plataforma Apple correspondiente al dispositivo de destino, cree una política de dispositivo con Create e introduzca el nombre, la descripción y el nombre de la organización. En Edit policy, añada la configuración Wi-Fi con Add configuration y abra su nombre para editarla. Para Wi-Fi empresarial, prepare primero los certificados de cliente y raíz necesarios en la misma política, como se describe arriba; Apply en las configuraciones de certificado raíz no sustituye a Save para toda la política.
2. En SSID, introduzca el nombre de la red Wi-Fi confirmado por el equipo de redes y ajuste Security type al método real, incluida su variante Personal o Enterprise. Personal requiere la contraseña Wi-Fi; para Enterprise, utilice los ajustes de EAP, autenticación y confianza descritos más abajo. Connect automatically conecta automáticamente cuando la red está disponible; Hidden network designa una red que no anuncia su SSID. Elija ambas opciones según la red prevista, no como prueba de seguridad.
3. Revise todas las configuraciones y guarde la política con Save en Edit policy. Para asignarla después, siga el procedimiento «Crear y asignar la política»: seleccione la política piloto guardada, marque solo los dispositivos de prueba individuales autorizados y contraste la lista y el número antes de Finish. Tenga en cuenta las advertencias de esa guía sobre programación e iPadOS. Después, observe por separado el estado de las tareas y la asignación, la autenticación Wi-Fi real y el check-in MDM según los criterios de comprobación indicados más abajo; guardar y asignar no son resultados de conexión confirmados.

Para la configuración Wi-Fi de una política de dispositivo iOS, seleccione primero el Security type adecuado para la red. Una variante Personal permite utilizar la contraseña Wi-Fi. Solo una variante Enterprise ofrece Protocols, Authentication y Trusted certificates. En Accepted EAP types, acuerde con el equipo de RADIUS los métodos que el dispositivo acepta para la autenticación en la red. Los certificados de cliente y raíz descritos arriba siguen vinculados a la misma política.

En Authentication de la política de dispositivo iOS, User es el nombre de usuario Wi-Fi y Password es la contraseña Wi-Fi para autenticarse con credenciales. Según Sophos, Require password on each connect envía la contraseña en cada autenticación; la opción no garantiza que se solicite la contraseña de forma interactiva. Acuerde con el equipo de RADIUS la vía de credenciales y esta selección. Para autenticación basada en certificados, seleccione en su lugar el Identity certificate adecuado de una configuración Client certificate de la misma política de dispositivo. Compruebe en el dispositivo de prueba que RADIUS acepta las credenciales o el certificado de cliente, según la vía elegida; en ambos casos, la identidad del servidor y la cadena de confianza deben comprobarse por separado.

En TTLS, Internal identity designa el protocolo de autenticación de usuario dentro del túnel. No es la identidad externa. Para EAP-FAST puede configurarse un Protected Access Credential (PAC); este PAC no es un script de configuración automática de proxy. Aclare con el equipo de RADIUS el protocolo TTLS y, si corresponde, la credencial EAP-FAST, y compruebe la autenticación en el dispositivo de destino. Sin esa aclaración, excluya del piloto la rama EAP correspondiente.

Para EAP, configure ambos límites de TLS o deje ambos sin configurar. Sophos describe Outer identity para TTLS, PEAP y EAP-FAST y exige una identidad externa para TLS 1.3. No utilice nombres de usuario ni secretos para ella, porque se transmite en texto claro. Si se necesita una identidad externa anónima con el realm adecuado para el encaminamiento, el equipo de PKI/RADIUS debe comprobarla. Observe en el dispositivo de prueba la autenticación y la versión TLS negociadas; la selección por sí sola no demuestra una conexión correcta.

Turn off private address hace que el dispositivo utilice para esta red Wi-Fi su dirección MAC de hardware en lugar de una dirección específica de la red generada por iOS. Esto reduce la privacidad. Utilice la opción solo si es imprescindible identificar el dispositivo con la misma dirección MAC en sus distintas redes. Según Sophos, Synchronized Security no funciona con direcciones MAC privadas: Sophos Fusion Wireless solo conoce la dirección privada y Sophos Mobile solo la dirección de hardware. Sin embargo, desactivar la dirección privada no garantiza por sí solo que Synchronized Security funcione; compruebe la correspondencia y el comportamiento deseado en la red prevista. No lo trate como solución alternativa de NAC para BYOD. En User Enrollment, Sophos no dispone de la dirección MAC para NAC.

También para Wi-Fi en una política de usuario iOS, Sophos distingue entre Personal y Enterprise en Security type. Personal utiliza la contraseña Wi-Fi. Protocols, Authentication y Trusted certificates solo están disponibles con Enterprise. Para autenticarse con credenciales, User es el nombre de usuario Wi-Fi y Password es la contraseña Wi-Fi. Según Sophos, Require password on each connect envía la contraseña en cada autenticación. Acuerde esta selección con el equipo de RADIUS; no la interprete como una garantía de que se solicitará la contraseña al usuario. Para autenticación basada en certificados, seleccione en su lugar el Identity certificate adecuado de una configuración Client certificate de la misma política de usuario. El certificado de servidor de Trusted certificates también requiere una configuración Root certificate en esa política. Utilice el certificado de cliente y su aceptación por RADIUS como criterios de comprobación solo para la autenticación basada en certificados.

Según la descripción de Wi-Fi, las decisiones EAP anteriores también se aplican a esta política de usuario. Ajuste Accepted EAP types a la autenticación de la red; para TTLS, aclare el protocolo de Internal identity y, para EAP-FAST, si corresponde, el Protected Access Credential (PAC). Esta credencial no es un script PAC de proxy. Configure ambos límites de TLS o deje ambos sin configurar. Outer identity se describe para TTLS, PEAP y EAP-FAST y es obligatoria para TLS 1.3. Tenga en cuenta las advertencias anteriores sobre texto claro y realm. No deduzca de ello que todas las opciones estén disponibles en su tenant ni que la autenticación vaya a funcionar; siguen vigentes la exclusión de un proxy Wi-Fi gestionado y la limitación MAC/NAC de User Enrollment.

Proxy y VPN son intervenciones distintas

• Proxy Wi-Fi: En la política de dispositivo iOS puede configurarse manualmente o mediante PAC (archivo con reglas de proxy). En Apple User Enrollment, la configuración Wi-Fi no admite proxy. Sophos menciona como posible alternativa WPAD (detección automática de un proxy) en el punto de acceso y la opción de proxy HTTP automático seleccionada por el usuario en los ajustes Wi-Fi; no se trata de una configuración de proxy BYOD gestionada remotamente. Pruebe por separado PAC/WPAD, DNS y la accesibilidad.
• Proxy HTTP global: Sophos solo permite esta configuración de dispositivo iOS para dispositivos supervisados; manualmente con servidor, puerto y, si procede, credenciales, o automáticamente con una URL PAC. En el modo manual, Server es el nombre o la dirección IP del proxy HTTP y Port es su número de puerto. Authentication es el nombre de usuario para conectarse al servidor proxy y Password es la contraseña correspondiente. No supone una promesa de compatibilidad con BYOD ni de tolerancia a fallos.
• VPN para todo el dispositivo: La política de dispositivo iOS contempla el tipo de conexión, el servidor y la autenticación; con Custom SSL/TLS debe estar instalada la aplicación del proveedor. No traslade esta configuración a Apple User Enrollment: Apple no permite allí una VPN convencional para todo el dispositivo.
• VPN por aplicación: Configuración específica para aplicaciones seleccionadas, no equivalente a una VPN del dispositivo. Compruebe por separado la aplicación del proveedor, el servidor, la autenticación, los certificados/proxy opcionales, On-Demand y las reglas de dominio para Safari/otros navegadores, calendario, contactos y correo. Compruebe también el alcance real de Send all traffic through VPN; no deduzca de ese nombre un aislamiento universal de aplicaciones ni un efecto en todo el dispositivo. La documentación de Sophos no es uniforme en este punto: La descripción de User Policy incluye VPN por aplicación, pero la asignación de aplicaciones solo menciona Device Policies como requisito y opción seleccionable. Por eso no afirme que existe una ruta funcional de asignación para BYOD: demuéstrela primero en el tenant actual con una aplicación y un dispositivo de prueba.

VPN del dispositivo: proveedor, autenticación y recorrido del tráfico

Los siguientes datos corresponden a la configuración VPN de una política de dispositivo iOS, no a la configuración VPN por aplicación ni a Apple User Enrollment. Compruebe la disponibilidad y la compatibilidad del proveedor en su tenant. Connection name es el nombre de la conexión que se muestra en el dispositivo. En Server, introduzca el nombre de host o la dirección IP del servidor VPN; confirme el punto de conexión adecuado con el responsable de VPN.

• En Connection type, seleccione el proveedor o tipo de conexión adecuado. Para una aplicación de proveedor VPN del App Store, Sophos describe Custom SSL/TLS. La aplicación debe estar instalada; introduzca su identificador en formato DNS inverso en Identifier (reverse DNS format). Si el proveedor especifica parámetros de conexión propios, registre las claves y los valores confirmados en Third-party settings como propiedades de conexión. No reutilice claves ni valores de configuraciones de otros proveedores.
• User authentication se refiere a la autenticación del usuario. Account es la cuenta de usuario de la conexión VPN; Group puede indicar un grupo de autenticación necesario para ella. Con Password, indique la contraseña VPN; con Certificate, el certificado de autenticación VPN. Aclare con el responsable de VPN si se necesita un grupo y qué identidad debe utilizarse. Estas credenciales no son las del proxy.
• Device authentication es una función distinta. Con Keys (Shared Secret)/Group name, indique el grupo necesario en Group name y la clave compartida en Keys (Shared Secret). Sophos menciona Use hybrid authentication y Request password, pero en esta página solo indica que se seleccionen según las necesidades. Aquí no se aclara su efecto ni qué selección es necesaria; incluya estas dos opciones en el piloto solo tras confirmarlas con el proveedor. Con Certificate, seleccione el certificado de autenticación de dispositivo necesario. Según Sophos, Including user PIN incorpora opcionalmente el PIN del usuario a la autenticación del dispositivo. No aplique ninguna de estas ramas a todos los proveedores sin comprobarla ni registre claves o PIN reales en tickets.
• Send all traffic through VPN es el ajuste para enviar todo el tráfico por esta conexión VPN. Sophos indica que todo el tráfico se envía por la VPN. Compruebe en el dispositivo de prueba el recorrido real del tráfico en el modo de proveedor/túnel elegido y controle por separado el canal de retorno MDM. Esto no demuestra una captura completa de todo el tráfico ni aislamiento de aplicaciones.
• En Proxy, defina el proxy de esta conexión VPN. No proxy significa que no hay proxy de conexión. Con Manually, introduzca la dirección y el puerto del proxy en Server and port; Authentication es el nombre de usuario del proxy y Password es su contraseña. Con Automatic, indique en Proxy server URL la URL del servidor con los ajustes de proxy. Esta selección no es el proxy Wi-Fi ni la configuración de proxy HTTP global; no deduzca de ella un requisito de supervisión ni tolerancia a fallos.
• Provider type distingue la capa de transporte, no el proveedor de Connection type. App proxy transporta el tráfico del túnel VPN en la capa de aplicación y Packet tunnel en la capa de red. Por tanto, App proxy no equivale a VPN por aplicación. Compruebe en el dispositivo de destino qué opción admite el proveedor y qué tráfico captura realmente.

VPN por aplicación: entradas e inicio de conexión

Para Per app VPN en una política de dispositivo iOS, Sophos describe las siguientes entradas y comportamientos; su efecto debe comprobarse en el piloto. Estos datos no resuelven la contradicción sobre la asignación de aplicaciones en User Policy mencionada arriba.

Para Per app VPN, tanto en las políticas de dispositivo iOS como en las políticas de usuario iOS, Connection name es el nombre de la conexión que se muestra en el dispositivo. Es la etiqueta visible de la conexión, no el identificador DNS inverso de la aplicación del proveedor, la dirección del servidor ni la cuenta de usuario.

• Aplicación del proveedor: Si el proveedor VPN ofrece en el App Store una aplicación que proporciona la conexión VPN, seleccione Custom SSL/TLS. Esta aplicación VPN debe estar instalada en el dispositivo; introduzca su identificador en formato DNS inverso en Identifier (reverse DNS format), no el de la aplicación de trabajo cuyo tráfico debe pasar por el túnel.
• Autenticación VPN: Server es el nombre de host o la dirección IP del servidor VPN y Account es la cuenta de usuario para autenticar la conexión. En User authentication, seleccione Password o Certificate e indique, respectivamente, la contraseña VPN en Password o el certificado de autenticación VPN en Certificate. Estos datos son distintos de las credenciales de un proxy de conexión.
• Inicio de conexión: Si Connect automatically on demand está activado, según Sophos el dispositivo activa la VPN cuando la aplicación establece una conexión de red. Si la opción está desactivada, los usuarios deben activar la VPN por sí mismos. Compruebe ambos procesos en el dispositivo de prueba previsto.
• Proxy de conexión: Proxy ofrece No proxy, Manually y Automatic. Para la configuración manual, indique la dirección válida y el puerto del proxy en Server and port, el nombre de usuario del proxy en Authentication y su contraseña en Password. Para la configuración automática, introduzca en Proxy server URL la URL del servidor con los ajustes de proxy. Es el proxy de esta conexión VPN, no la configuración de proxy HTTP global.

Domains in Safari, Domains in Calendar, Domains in Contacts y Domains in Mail utilizan la misma sintaxis: un dominio, dominio parcial o nombre de host por línea. Un dominio parcial coincide cuando todos los componentes separados por puntos coinciden desde la derecha; se ignoran los puntos iniciales y finales. Una cadena sin puntos solo coincide con el host de ese nombre, no con cualquier dominio que tenga esa terminación. Además, sigue aplicándose la regla de dominio de segundo nivel para Calendario, Contactos y Mail; la sección del piloto describe la prueba positiva adecuada.

VPN por aplicación en la política de usuario y asignación de aplicaciones

La descripción de Sophos de Per app VPN en una política de usuario iOS también documenta las entradas explicadas arriba para la aplicación de proveedor VPN instalada y su identificador DNS inverso, la autenticación con Password o Certificate, el inicio de conexión On-Demand, el proxy de conexión y la sintaxis de dominios. Estas coincidencias documentadas no demuestran que exista una vía funcional de asignación en Apple User Enrollment.

Sophos documenta los siguientes campos condicionados para Per app VPN tanto en las políticas de dispositivo iOS como en las políticas de usuario iOS. Las condiciones se aplican a ambos tipos de política; compruebe la disponibilidad y la compatibilidad del proveedor en su tenant:

• En Third-party settings pueden registrarse propiedades de conexión especificadas por el proveedor VPN. El campo solo está disponible con Custom SSL/TLS. Utilice Add para introducir los valores confirmados de Key y Value. Estas propiedades de conexión no son la Managed configuration de la aplicación de trabajo cuyo tráfico debe pasar por el túnel.
• Group designa el grupo necesario para la autenticación. El campo solo está disponible para Cisco AnyConnect y Cisco Legacy AnyConnect. No extienda esta condición a otros tipos de conexión.
• En Provider type, App proxy transporta el tráfico del túnel VPN en la capa de aplicación y Packet tunnel en la capa de red. Este ajuste no está disponible para Cisco AnyConnect. Compruebe en el dispositivo de prueba previsto qué opción admite el proveedor y qué tráfico captura realmente. La capa de transporte por sí sola no demuestra aislamiento de aplicaciones ni un efecto VPN en todo el dispositivo.

La asignación de una conexión existente a la aplicación de trabajo forma parte del proceso de distribución de aplicaciones, en la sección «Comprobar la configuración administrada y el comportamiento de la aplicación». Allí, asignar VPN por aplicación se limita expresamente a políticas de dispositivo existentes. Los responsables de las políticas proporcionan la conexión adecuada; los responsables de las aplicaciones la seleccionan en VPN connection used by the app. Esta referencia no resuelve la incertidumbre descrita arriba sobre las políticas de usuario ni autoriza una vía de asignación BYOD no comprobada.

Compruebe antes, observe durante el piloto y acote los fallos

1. Inventario y vía de retorno: Anote la titularidad, la inscripción, la supervisión, la versión de iOS/iPadOS, la política afectada y su asignación. Tanto para un dispositivo de empresa supervisado como para uno BYOD de prueba voluntaria, registre una vía de red independiente (por ejemplo, datos móviles u otra red Wi-Fi) y la persona de contacto responsable. Sin esa vía, no distribuya cambios que puedan bloquear el acceso. Para modificar políticas de dispositivo iOS, utilice una política de prueba asignada únicamente al dispositivo piloto de empresa y compruebe sus asignaciones actuales y el número de dispositivos destinatarios antes de actualizarlos; no modifique para el piloto una política ya asignada en producción.
2. Dependencias: Pruebe antes y después del cambio la accesibilidad de DNS, APNs/MDM, CA/SCEP/RA, servidor RADIUS/EAP, PAC/WPAD y extremo VPN. Compruebe la cadena de certificados, los nombres de servidor, la caducidad y la sustitución prevista; no copie claves privadas, challenges ni credenciales en los tickets. Una asignación válida de política por sí sola no demuestra que Wi-Fi o VPN funcionen.
3. Piloto acotado: Empiece con dispositivos de prueba separados y una asignación mínima. Registre lo siguiente como criterios de comprobación, no como resultados confirmados: el dispositivo acepta la identidad verificada del servidor RADIUS y se conecta al Wi-Fi empresarial. Para autenticación basada en certificados, compruebe además la recepción del certificado de cliente y su aceptación por RADIUS; para autenticación con nombre de usuario y contraseña, compruebe la vía de credenciales prevista. Para VPN por aplicación, compruebe el tráfico del túnel de la aplicación de prueba gestionada y asignada; use los accesos de otras aplicaciones como prueba negativa solo si no tienen otra asignación VPN ni coinciden con una regla de dominio configurada. Si se han configurado dominios para Safari/otros navegadores, calendario, contactos o correo, compruebe también los accesos previstos a los dominios correspondientes y no dé por hecho que «los demás accesos no usan el túnel». Compruebe por separado los dominios de Safari y otros navegadores: para las pruebas positivas con Calendario, Contactos y Mail, Sophos exige además que el dominio de segundo nivel del dominio indicado coincida con el del servidor VPN. Un dominio que no cumpla esa condición no sirve como prueba positiva válida del túnel, y la ausencia de tráfico por él no demuestra por sí sola que haya fallado la distribución de la VPN. Compruebe las reglas de dominio en su propio tenant, sin convertir esta condición en una receta de configuración no verificada. Compruebe por separado en el dispositivo de prueba el efecto de Send all traffic through VPN en el modo de proveedor/túnel elegido; no infiera de ello un efecto no verificado en todo el dispositivo ni aislamiento de aplicaciones. Para VPN por aplicación en User Policy, demuestre que la asignación de aplicaciones está realmente disponible o deje la función fuera del alcance por el momento. En PAC/WPAD, observe la vía de contingencia definida ante fallos de web/proxy; tras cada cambio confirme por separado un nuevo check-in MDM y el funcionamiento real de la red. Si no hay check-in o falta la vía de red independiente, detenga el piloto y no asigne más dispositivos.
4. Acote los fallos: Si falla Wi-Fi, compruebe primero el SSID y el tipo de seguridad, el nombre del servidor EAP y la CA de confianza; para autenticación con credenciales, el nombre de usuario, la contraseña y la vía de autenticación RADIUS prevista; para autenticación basada en certificados, la identidad de cliente emitida y la accesibilidad de la CA; si falla la web, PAC/WPAD/DNS y el acceso al proxy; si falla una aplicación, la aplicación del proveedor, el túnel, el certificado y la asignación. Observe por separado el estado de la tarea/check-in y la conexión real. No provoque una segunda interrupción retirando certificados o perfiles sin control.

Reversión sin restablecer el dispositivo

Antes del piloto, prepare una política de sustitución y una cadena de confianza de sustitución funcionales con una red accesible. No retire la CA anterior ni los certificados de identidad hasta confirmar la sustitución en el dispositivo de destino y el check-in MDM.

Según Sophos, los cambios en las políticas de dispositivo iOS requieren Update devices: esta acción crea una tarea de actualización para todos los dispositivos a los que esté asignada la política modificada, no solo para el dispositivo piloto. Por ello, actualice únicamente la política piloto aislada después de comprobar sus destinatarios actuales; una tarea dirigida Assign policy para dispositivos seleccionados no equivale a actualizar una política asignada a varios dispositivos. La tarea dirigida Uninstall policy está prevista para Device Enrollment, pero también puede eliminar la vía de red. En las políticas de usuario iOS de dispositivos con User Enrollment no existe esa tarea Uninstall policy: Sophos ofrece en su lugar la tarea dirigida Unassign iOS user policy. Actualizar o asignar otra política también puede ser apropiado según el fallo. No confunda la tarea dirigida con Unassign para todos los dispositivos.

iPadOS: distinga las acciones directas de los tipos de tarea. La guía de políticas explica las diferencias en la denominación de las vías directas de actualización y desinstalación: la descripción general de tipos menciona iOS/iPadOS, pero las instrucciones directas solo iOS device policies. Por ello, no traslade su secuencia de clics a iPadOS sin comprobarla; aclare la vía directa disponible en el tenant y en el dispositivo piloto. Esto no significa que la reversión en iPadOS carezca de documentación o sea imposible en general: los tipos de tarea de iOS/iPadOS documentan Uninstall policy para Device Enrollment y Unassign iOS user policy para User Enrollment. El procedimiento de paquetes de tareas según el modo de gestión describe esta selección; siga comprobando por separado la transferencia de la tarea y el efecto real de la reversión.

Compruebe la reversión por separado en un dispositivo piloto de empresa con Device Enrollment que siga accesible y en un dispositivo piloto BYOD con User Enrollment que siga accesible: pruebe en el dispositivo de empresa la tarea dirigida Uninstall policy correspondiente solo a ese dispositivo y, en el BYOD, la tarea dirigida Unassign iOS user policy. Confirme en cada dispositivo el estado de la tarea/check-in y el estado de la política efectivamente sincronizada; después vuelva a probar de forma independiente el funcionamiento de Wi-Fi/VPN y el contacto MDM. Limite las nuevas asignaciones o reversiones a los dispositivos piloto efectivamente comprobados hasta haber demostrado ambas vías de retorno. Una tarea guardada o enviada no llega automáticamente a un dispositivo bloqueado sin conexión. Para ello se necesitan la vía de red independiente y la vía local de resolución de incidencias previstas de antemano; Unassign para todos los dispositivos no es una medida inmediata de bajo riesgo. Ni el borrado completo (Wipe) ni la cancelación de User Enrollment constituyen un rollback general de políticas.