Dos cuentas de inicio de sesión del Mac no separan el tráfico VPN

Dos cuentas de inicio de sesión en el mismo Mac parecen dos mundos separados hasta que llega la red. Un túnel iniciado en una sesión todavía puede cambiar lo que experimenta la otra sesión, según qué cliente lo posea y qué política lo acompañe. Describa la separación que necesita antes de elegir un mecanismo para imponerla. El orden importa, porque un mecanismo elegido primero tiende a redefinir el requisito a su alrededor.

Tres preguntas hacen la mayor parte del trabajo: qué aplicaciones de quién necesitan qué recursos privados, si ambas sesiones deben estar activas a la vez y qué se permite hacer a esas aplicaciones cuando su túnel no está disponible.

Empiece por el tráfico, no por la lista de cuentas

Cambiar de cuenta es una frontera de identidad, no una frontera de enrutamiento. macOS carga una configuración VPN para la cuenta que la posee, pero la interfaz, sus rutas y cualquier política de todo el sistema que instale pertenecen a la máquina. Si el requisito es que solo las aplicaciones de una persona entren en la red corporativa, el diseño debe decirlo en términos de aplicaciones y destinos, no de quién ha iniciado sesión. De lo contrario, la segunda cuenta hereda lo que dejó el cliente de la primera.

Escriba el comportamiento requerido en una frase: el correo y el acceso a archivos de un usuario siguen el túnel gestionado, la navegación del otro usuario se queda en la conexión doméstica y ninguno de los dos caminos hereda la ruta predeterminada del otro. Esa frase es comprobable; una historia de cambio de inicio de sesión normalmente no lo es.

El canal del perfil y el alcance del tráfico son cosas distintas

Apple admite disposiciones VPN gestionadas entregadas por usuario o por dispositivo, y una guía de despliegue describe esos modelos junto con la integración dependiente del proveedor. El canal de entrega dice quién recibe la configuración y quién la posee. No define por sí mismo qué tráfico se captura, porque la implementación del cliente y la política configurada siguen decidiéndolo.

Donde un modo documentado consciente del usuario o de la aplicación puede expresar el requisito, ese es el camino más corto. Después verifique las aplicaciones e identidades reales en lugar de confiar en los nombres: dos copias de la misma aplicación no son dos caminos de red diferentes, y un perfil que enumera una aplicación no garantiza que sus procesos auxiliares queden cubiertos.

Un sistema invitado es una frontera real con límites reales

Una máquina virtual le da un sistema operativo separado con su propia pila de red, así que un invitado puede ejecutar su propio túnel y sus propias aplicaciones sin tocar las rutas del anfitrión. Es una separación más fuerte que una segunda cuenta de inicio de sesión, y también es más trabajo de mantenimiento. Decida si ese coste compra una frontera que realmente necesita antes de proponerlo.

El modo de red virtual todavía necesita revisión. Que el invitado esté puenteado, detrás de NAT o aislado determina qué puede alcanzar y qué puede alcanzarlo, y las aplicaciones del anfitrión no se convierten en aplicaciones del invitado porque el invitado esté conectado. Revise también la política de bloqueo, o un túnel de invitado caído volverá al camino del anfitrión de una forma que nadie pretendía.

Un proxy es más estrecho que una cuenta de usuario

Una aplicación del anfitrión puede llegar a un servicio de proxy real que se ejecuta en un invitado o contenedor aprobado, y eso cubre el tráfico que la aplicación envía realmente por el protocolo admitido. No cubre todos los procesos propiedad de esa cuenta del Mac ni el tráfico que la aplicación envía fuera del protocolo del proxy.

Otra precaución en máquinas compartidas: un oyente TCP vinculado al loopback del anfitrión no es una comprobación de nombre de usuario. Restringir un proxy a la máquina local lo mantiene fuera de la red, pero no autoriza a un usuario local por encima de otro que ya ha iniciado sesión. Mantenga explícita la autenticación del servicio si esa distinción importa.

Demuestre la frontera con dos pruebas

Ejecute ambos caminos y obsérvelos por separado. Con la cuenta prevista, abra la aplicación que necesita el recurso privado y confirme que llega al servicio gestionado; con la otra cuenta, confirme que la navegación ordinaria conserva el camino doméstico. Luego rompa el túnel a propósito y compruebe el comportamiento de reserva de cada lado, porque es ahí donde la mayoría de los diseños fallan en silencio. Haga las comprobaciones en la misma hora también, para que una red cambiada no contamine la comparación.

Si un contenedor o invitado ejecuta el túnel, añada una tercera comprobación: confirme que una aplicación nativa del Mac fuera de él todavía se comporta como se diseñó. Elija la disposición más simple cuyo alcance pueda demostrar, y no etiquete las máquinas virtuales como universalmente necesarias ni el cambio de cuenta como universalmente suficiente antes de ejecutar esas pruebas.