Conta VPN compartilhada: um limite de dispositivos não é isolamento de clientes

Oito conexões simultâneas é um número de uma página de licença, e não diz nada sobre o que esses oito dispositivos podem fazer uns aos outros. Um login compartilhado pode coexistir com chaves por sessão, e também pode coexistir com um gateway que encaminha alegremente o tráfego de um cliente para outro. O erro é tratar a conta como uma fronteira de segurança. Faça antes quatro perguntas separadas: o que foi comprado, o que protege o túnel, o que pode atravessar entre pares e o que pode derrubar o enlace local.

O que uma permissão de conexões realmente promete

Um limite de dispositivos conta quantas sessões o provedor aceitará por uma assinatura. É um controlo comercial e operacional, não uma declaração sobre identidade ou isolamento. Alguns provedores emitem um certificado distinto por dispositivo sob uma única conta; outros reutilizam uma única credencial em cada conexão. A diferença aparece na revogação, porque credenciais separadas permitem cortar um dispositivo e uma compartilhada não lhe deixa essa opção.

Leia como o provedor emite credenciais antes de supor qualquer coisa sobre a separação de chaves. O nome da conta não revela nada disso.

Verifique se o gateway encaminha entre clientes

O alcance entre pares é uma decisão do lado do servidor. No OpenVPN o interruptor pertinente está ausente a menos que apareça na configuração, mas o descarregamento moderno do plano de dados muda onde a regra é aplicada.

grep -n "client-to-client" /etc/openvpn/server.conf
iptables -A FORWARD -i tun0 -o tun0 -j DROP

Uma configuração sem essa diretiva deixa o tráfego entre pares para o firewall do anfitrião, que ainda pode permiti-lo. Quando o descarregamento está ativo, o núcleo trata a interface do túnel em vez do processo de espaço de usuário, então verifique os contadores de regras em vez de confiar no ficheiro. Bloquear o tráfego encaminhado entre endereços do túnel isola os clientes sem tocar no seu acesso ao gateway. Confirme com um teste de um cliente para um serviço noutro, tanto antes como depois da regra.

Proteja a sessão antes dos pares

A proteção do túnel e o acesso entre pares são propriedades diferentes, e uma cifra forte não implica isolamento. No modo TLS cada cliente deriva as suas próprias chaves de sessão, então um cliente não pode ler o tráfego de outro mesmo quando o gateway o retransmite. O antigo esquema de chave estática compartilha uma única chave entre todos, por isso reutilizar ali um login tem consequências muito piores. Inspecione o modo configurado e não a página de marketing, e depois julgue se compartilhar a conta se adequa aos dados em causa.

A autenticação do serviço em cada anfitrião continua importante, porque o túnel apenas prova que um cliente chegou à rede, não que deva chegar a um determinado daemon.

As falhas do Wi-Fi local não são comprometimentos do VPN

Uma conexão caída prova que o enlace local falhou, não que alguém tenha quebrado o túnel. Interferências, uma concessão DHCP perdida e uma transferência de roaming terminam uma sessão sem tocar em credenciais ou texto cifrado. Trate a desconexão como uma constatação de disponibilidade e mantenha-a separada das constatações de confidencialidade e acesso entre pares. Onde a rede local não é fiável, proteja o tráfego de ponta a ponta em vez de se apoiar apenas no túnel.

Anote as quatro respostas: permissão, modelo de chaves, política entre pares e dependência do enlace local. Esse registo transforma uma preocupação vaga sobre uma conta compartilhada em controlos concretos.