Duas contas de login do Mac não separam o tráfego VPN

Duas contas de login no mesmo Mac parecem dois mundos separados até a rede chegar. Um túnel iniciado numa sessão ainda pode mudar o que a outra sessão experimenta, dependendo de que cliente o possui e que política o acompanha. Descreva a separação de que precisa antes de escolher um mecanismo para a impor. A ordem importa, porque um mecanismo escolhido primeiro tende a redefinir o requisito à sua volta.

Três perguntas fazem a maior parte do trabalho: que aplicações de quem precisam de que recursos privados, se as duas sessões têm de estar ativas ao mesmo tempo e o que é permitido a essas aplicações fazer quando o túnel delas não está disponível.

Comece pelo tráfego, não pela lista de contas

Mudar de conta é uma fronteira de identidade, não uma fronteira de encaminhamento. O macOS carrega uma configuração VPN para a conta que a possui, mas a interface, as suas rotas e qualquer política de todo o sistema que instale pertencem à máquina. Se o requisito é que só as aplicações de uma pessoa entrem na rede corporativa, o projeto tem de o dizer em termos de aplicações e destinos, não em termos de quem tem sessão iniciada. Caso contrário, a segunda conta herda o que o cliente da primeira deixou.

Escreva o comportamento exigido numa frase: o correio e o acesso a ficheiros de um utilizador seguem o túnel gerido, a navegação do outro utilizador fica na ligação doméstica e nenhum dos caminhos herda a rota predefinida do outro. Essa frase é testável; uma história de mudança de sessão normalmente não é.

Canal do perfil e âmbito do tráfego são coisas diferentes

A Apple suporta disposições VPN geridas fornecidas por utilizador ou por dispositivo, e um guia de implementação descreve esses modelos juntamente com integração dependente do fornecedor. O canal de entrega diz quem recebe a configuração e quem a possui. Não define por si só que tráfego é capturado, porque a implementação do cliente e a política configurada continuam a decidi-lo.

Onde um modo documentado consciente do utilizador ou da aplicação pode expressar o requisito, esse é o caminho mais curto. Depois verifique as aplicações e identidades reais em vez de confiar em nomes: duas cópias da mesma aplicação não são dois caminhos de rede diferentes, e um perfil que lista uma aplicação não garante que os seus processos auxiliares estejam cobertos.

Um sistema convidado é uma fronteira real com limites reais

Uma máquina virtual dá-lhe um sistema operativo separado com a sua própria pilha de rede, pelo que um convidado pode executar o seu próprio túnel e as suas próprias aplicações sem tocar nas rotas do anfitrião. É uma separação mais forte do que uma segunda conta de login, e também dá mais trabalho de manutenção. Decida se esse custo compra uma fronteira de que realmente precisa antes de o propor.

O modo de rede virtual continua a precisar de revisão. Se o convidado está em bridge, atrás de NAT ou isolado determina o que pode alcançar e o que o pode alcançar, e as aplicações do anfitrião não se tornam aplicações do convidado só porque o convidado está ligado. Verifique também a política de bloqueio, ou um túnel de convidado caído voltará ao caminho do anfitrião de uma forma que ninguém pretendia.

Um proxy é mais estreito do que uma conta de utilizador

Uma aplicação do anfitrião pode alcançar um serviço de proxy real em execução num convidado ou contentor aprovado, e isso cobre o tráfego que a aplicação envia realmente pelo protocolo suportado. Não cobre todos os processos pertencentes a essa conta do Mac, nem o tráfego que a aplicação envia fora do protocolo do proxy.

Outra precaução em máquinas partilhadas: um ouvinte TCP ligado ao loopback do anfitrião não é uma verificação de nome de utilizador. Restringir um proxy à máquina local mantém-no fora da rede, mas não autoriza um utilizador local em detrimento de outro que já tenha sessão iniciada. Mantenha a autenticação do serviço explícita se essa distinção importar.

Prove a fronteira com dois testes

Execute os dois caminhos e observe-os separadamente. Com a conta pretendida, abra a aplicação que precisa do recurso privado e confirme que alcança o serviço gerido; com a outra conta, confirme que a navegação comum mantém o caminho doméstico. Depois quebre o túnel de propósito e verifique o comportamento de recurso de cada lado, porque é aí que a maioria dos projetos falha em silêncio. Faça as verificações também na mesma hora, para que uma rede alterada não contamine a comparação.

Se um contentor ou convidado executar o túnel, acrescente uma terceira verificação: confirme que uma aplicação Mac nativa fora dele continua a comportar-se como projetado. Escolha a disposição mais simples cujo âmbito possa demonstrar, e não rotule as máquinas virtuais como universalmente necessárias nem a mudança de conta como universalmente suficiente antes de executar esses testes.