Um login VPN num PC partilhado: quem mais recebe a rota?

Partilhar uma estação de trabalho levanta uma pergunta a que um portátil de um único utilizador nunca tem de responder: depois de uma pessoa autenticar o túnel, quem mais o pode usar? O login identifica um sujeito, e a rota que instala descreve um âmbito, e essas duas coisas não são o mesmo objeto. Entre elas estão o sistema operativo, a configuração do cliente e o que o serviço privado exige por si. Comparar os pontos de aplicação é a única forma de responder sem adivinhar.

Um login, vários âmbitos

A autenticação responde a quem foi admitido. A rota responde a que pacotes podem sair pelo túnel. A autorização responde a que serviço aceitará a ligação resultante, e nenhuma das três implica a seguinte.

Um túnel para todo o host é a predefinição comum e torna a lacuna evidente. A rota está na tabela do núcleo, por isso qualquer processo que use essa tabela pode alcançar a rede privada, incluindo um iniciado por um utilizador que nunca viu a janela VPN. Não é um defeito do túnel; é o que significa uma rota de todo o sistema. O serviço privado pode ainda recusar a ligação, e é por isso que alcançabilidade e permissão precisam de respostas separadas.

Escrever as quatro perguntas antes do teste evita que a revisão se reduza a uma delas.

Onde está realmente a fronteira

Quatro disposições cobrem a maioria das máquinas: um túnel para todo o host, uma ligação por utilizador, uma lista de aplicações permitidas e um espaço de nomes de rede ou máquina virtual separados.

Cada uma coloca o ponto de aplicação noutro lugar, e as diferenças contam mais do que os rótulos. Uma ligação por utilizador é aplicada pelas permissões do perfil, não pelo ecrã de início de sessão do ambiente de trabalho. Uma lista de aplicações permitidas é aplicada dentro do cliente, que decide o que transportará. Um espaço de nomes ou uma VM aplica na fronteira da interface, pelo que um processo lá dentro não vê de todo a rota do host. O número de ecrãs de início de sessão na máquina não diz nada sobre nenhuma delas.

Ler a tabela linha a linha mostra que a pergunta real não é se existe isolamento, mas onde é implementado.

Compare quatro pontos de aplicação

No Linux a tabela de rotas é a primeira coisa a inspecionar, porque um túnel para todo o host aparece lá e um espaço de nomes não. Executar a consulta como segundo utilizador é o passo que as pessoas saltam; a resposta difere da que obtiveram como elas próprias, e isso explica o relatório.

As duas verificações seguintes olham para a política, não para o encaminhamento. Uma regra de firewall que corresponde a um UID aplica-se ao tráfego gerado localmente, pelo que pode separar dois utilizadores num host mesmo quando ambos partilham a rota. Um perfil de ligação com uma lista explícita de permissões é aplicado pelo gestor de rede na ativação. Nenhuma das verificações exige alterar o túnel, e é por isso que vale a pena fazê-las antes de redesenhar seja o que for.

ip route get 10.40.2.10
sudo -u bob ip route get 10.40.2.10
nmcli connection show vpn-work | grep -i permission
sudo nft list ruleset | grep -n skuid

Se a segunda consulta mostrar a rota do túnel, a fronteira não está onde o projeto supunha.

As regras de sessões simultâneas são um controlo à parte

Os gateways limitam frequentemente quantas sessões uma conta pode manter, e esse limite nada tem a ver com os utilizadores locais. Restringe a conta, por isso uma segunda pessoa que entre com a mesma credencial pode terminar o túnel da primeira.

Leia a falha antes de supor um problema local de isolamento. Um limite de sessões produz uma desconexão no gateway, enquanto um problema de âmbito produz um túnel a funcionar mas que simplesmente não transporta o tráfego do outro utilizador. Estes dois sintomas levam a correções completamente diferentes. Guarde a mensagem exata do cliente, porque normalmente nomeia a regra. Peça ao proprietário do perfil o fluxo de trabalho aprovado em vez de contornar o limite.

Uma máquina virtual não isenta ninguém dessa regra e acrescenta o seu próprio desenho de rede e de credenciais.

Teste o contexto que lhe importa

Teste o utilizador e a aplicação previstos e depois teste um contexto que deveria ser negado. Uma revisão que apenas prova que a palavra-passe original funciona testou a autenticação e nada mais.

sudo -u bob curl -sS -m 5 https://intranet.internal/health
wg show
ss -tnp | grep -E ':443|:51820'

Anote o ponto de aplicação ao lado de cada resultado: a tabela de rotas, uma regra de UID, uma permissão de perfil ou a política de sessões do gateway. Esse registo torna a alteração seguinte verificável. Também impede que a mesma pergunta seja reaberta sempre que alguém repara num segundo ecrã de início de sessão. Alcançabilidade não é autorização, e nenhuma das duas é isolamento.