Dúas contas de inicio de sesión do Mac non separan o tráfico VPN

Dúas contas de inicio de sesión no mesmo Mac parecen dous mundos separados ata que chega a rede. Un túnel iniciado nunha sesión aínda pode cambiar o que experimenta a outra sesión, segundo que cliente o posúa e que política o acompañe. Describa a separación que precisa antes de escoller un mecanismo para impola. A orde importa, porque un mecanismo escollido primeiro tende a redefinir o requisito ao seu redor.

Tres preguntas fan a maior parte do traballo: que aplicacións de quen necesitan que recursos privados, se ambas as sesións deben estar activas á vez e que se permite facer a esas aplicacións cando o seu túnel non está dispoñible.

Empece polo tráfico, non pola lista de contas

Cambiar de conta é unha fronteira de identidade, non unha fronteira de encamiñamento. macOS carga unha configuración VPN para a conta que a posúe, pero a interface, as súas rutas e calquera política de todo o sistema que instale pertencen á máquina. Se o requisito é que só as aplicacións dunha persoa entren na rede corporativa, o deseño debe dicilo en termos de aplicacións e destinos, non de quen ten a sesión iniciada. Doutro xeito, a segunda conta herda o que deixou o cliente da primeira.

Escriba o comportamento requirido nunha frase: o correo e o acceso a ficheiros dun usuario seguen o túnel xestionado, a navegación do outro usuario queda na conexión doméstica e ningún dos dous camiños herda a ruta predeterminada do outro. Esa frase é comprobable; unha historia de cambio de inicio de sesión normalmente non o é.

A canle do perfil e o alcance do tráfico son cousas distintas

Apple admite disposicións VPN xestionadas entregadas por usuario ou por dispositivo, e unha guía de despregamento describe eses modelos xunto coa integración dependente do provedor. A canle de entrega di quen recibe a configuración e quen a posúe. Non define por si mesma que tráfico se captura, porque a implementación do cliente e a política configurada seguen decidíndoo.

Onde un modo documentado consciente do usuario ou da aplicación pode expresar o requisito, ese é o camiño máis curto. Despois verifique as aplicacións e identidades reais en lugar de confiar nos nomes: dúas copias da mesma aplicación non son dous camiños de rede diferentes, e un perfil que lista unha aplicación non garante que os seus procesos auxiliares quedan cubertos.

Un sistema convidado é unha fronteira real con límites reais

Unha máquina virtual dálle un sistema operativo separado coa súa propia pila de rede, así que un convidado pode executar o seu propio túnel e as súas propias aplicacións sen tocar as rutas do anfitrión. É unha separación máis forte que unha segunda conta de inicio de sesión, e tamén é máis traballo de mantemento. Decida se ese custo compra unha fronteira que realmente necesita antes de propoñelo.

O modo de rede virtual aínda necesita revisión. Que o convidado estea ponteado, detrás de NAT ou illado determina que pode acadar e que o pode acadar, e as aplicacións do anfitrión non se converten en aplicacións do convidado polo feito de que o convidado estea conectado. Comprobe tamén a política de bloqueo, ou un túnel de convidado caído volverá ao camiño do anfitrión dun xeito que ninguén pretendía.

Un proxy é máis estreito que unha conta de usuario

Unha aplicación do anfitrión pode chegar a un servizo de proxy real que se executa nun convidado ou contedor aprobado, e iso cobre o tráfico que a aplicación envía realmente polo protocolo admitido. Non cobre todos os procesos propiedade desa conta do Mac nin o tráfico que a aplicación envía fóra do protocolo do proxy.

Outra precaución en máquinas compartidas: un oínte TCP ligado ao loopback do anfitrión non é unha comprobación de nome de usuario. Restrinxir un proxy á máquina local manteno fóra da rede, pero non autoriza un usuario local por riba doutro que xa ten a sesión iniciada. Manteña explícita a autenticación do servizo se esa distinción importa.

Demostre a fronteira con dúas probas

Execute ambos os camiños e obsérveos por separado. Coa conta prevista, abra a aplicación que necesita o recurso privado e confirme que chega ao servizo xestionado; coa outra conta, confirme que a navegación ordinaria conserva o camiño doméstico. Despois rompa o túnel a propósito e comprobe o comportamento de reserva de cada lado, porque é aí onde a maioría dos deseños fallan en silencio. Faga as comprobacións na mesma hora tamén, para que unha rede cambiada non contamine a comparación.

Se un contedor ou convidado executa o túnel, engada unha terceira comprobación: confirme que unha aplicación nativa do Mac fóra del aínda se comporta como se deseñou. Escolla a disposición máis simple cuxo alcance poida demostrar, e non etiquete as máquinas virtuais como universalmente necesarias nin o cambio de conta como universalmente suficiente antes de executar esas probas.