Cliente VPN portátil sem direitos de administrador: o que ainda se parte

Portátil descreve o instalador, não o kernel. Um cliente pode chegar como um único executável num stick USB e ainda precisar de um dispositivo de túnel, de uma entrada na tabela de rotas e de uma escrita no resolver antes de o primeiro pacote se mover. Qual dos três a máquina de destino o deixará tocar decide se essa compilação funciona sequer ali. Os testes abaixo respondem à pergunta na ordem em que o cliente os encontrará.

Portátil cobre três promessas diferentes, e só uma é gratuita

Sem instalador significa que o fornecedor não registou um serviço, não enviou um desinstalador nem acrescentou uma entrada de menu. Sem administrador significa que uma conta comum pode iniciar o cliente e concluir uma ligação. Sem alteração no anfitrião significa que a máquina parece idêntica depois de sair. As páginas de descarregamento que dizem portátil prometem normalmente apenas a primeira destas, e as outras duas são onde as implementações falham. Uma compilação também pode ser portátil no sentido estrito: corre a partir de suportes só de leitura sem qualquer escrita de ficheiros de ponto, o que ainda não diz nada sobre a pilha de rede.

As promessas caras são a segunda e a terceira. Um único executável que precisa de um adaptador, de uma rota ou de uma escrita no resolver pede ao sistema operativo uma autoridade que a etiqueta portátil nunca cobriu.

Encontre o ajudante privilegiado que o cliente vai chamar

Quase nenhum cliente VPN move pacotes sozinho. No Windows o caminho dos dados passa por filtros WFP e pelo Base Filtering Engine, no macOS por um fornecedor NetworkExtension que o utilizador aprova nas Definições do Sistema, e no Linux por um dispositivo tun mais a pilha de encaminhamento. O binário que copiou é uma superfície de controlo para esses componentes, não um substituto deles. Pergunte que componente o cliente espera e depois confirme que está instalado, a correr e que pode ser usado pela sua conta.

O Linux é o local mais fácil para o provar, porque a verificação é uma única chamada ao sistema. Abrir /dev/net/tun e pedir um dispositivo ao kernel exige CAP_NET_ADMIN, e a documentação do kernel sobre TUN/TAP indica tanto a regra de propriedade como a capacidade. Execute o teste com a conta que vai iniciar o cliente, não como root.

ls -l /dev/net/tun
ip tuntap add dev vpntest mode tun
ip link delete vpntest

Um erro de permissões na linha do meio é a resposta que procurava: esta conta não pode criar uma interface de túnel, por isso qualquer cliente no espaço de utilizador que precise de uma falha ao ligar, não ao descarregar. A última linha remove o dispositivo de teste e não imprime nada quando funciona. Se ambas as linhas tiverem sucesso, o anfitrião não alterou nada de forma permanente.

Teste as alterações de rota e de resolver antes da primeira ligação

O túnel dividido transforma uma ligação numa decisão de encaminhamento, enquanto um túnel completo a transforma numa substituição da rota predefinida. Ambos são escritas na pilha de rede do anfitrião, e ambos falham para uma conta sem privilégios mesmo quando o cliente arranca limpo. O resolver é a terceira escrita, e nos anfitriões com systemd é normalmente a que se parte por último. Essa ordem importa quando decide onde gastar uma instalação elevada.

Um teste de rota precisa de um destino que lhe importe mesmo, por isso substitua o marcador abaixo por uma sub-rede do seu próprio perfil. O nome do dispositivo tem de existir para a rota se poder ligar a alguma coisa.

ip route add 10.20.0.0/16 dev vpntest
ip route del 10.20.0.0/16
resolvectl query intranet.example.internal

Se a primeira linha devolver RTNETLINK answers: Operation not permitted, a conta não pode instalar a rota privada que o perfil exige. A segunda linha prova o mesmo direito ao contrário, o que importa porque um cliente que pode acrescentar rotas mas não removê-las deixa uma tabela partida atrás. A consulta ao resolver mostra depois se os nomes privados são resolvidos pelo túnel ou se escorrem para o resolver em que o anfitrião já confia.

Execute as três enquanto o dispositivo de teste ainda existe e depois apague-o. Uma rota que aponta para um dispositivo que desapareceu é a razão mais comum para um portátil perder a conectividade depois de uma ligação falhada.

Decida o que tem de sobreviver à sessão

Apagar a pasta não é um plano de limpeza. Adaptadores, rotas, definições do resolver, certificados de confiança e credenciais guardadas podem cada um sobreviver ao processo, e um serviço de arranque pode restaurar alguns sem perguntar. Anote o que é permitido ao cliente deixar para trás antes de o executar, não depois da primeira desconexão falhada.

A regra prática é tirar uma fotografia das três superfícies que vai alterar e compará-las depois. Registe as interfaces, a tabela de encaminhamento principal e o estado do resolver antes da primeira ligação, e depois repita as mesmas três leituras quando o cliente tiver saído.

ip -brief addr show
ip route show table main
resolvectl status

Tudo o que está presente na segunda captura e ausente na primeira precisa de um dono. Ou o cliente remove-o ao sair, ou você remove-o com os mesmos comandos que o criaram, e essa remoção pertence às notas de implementação e não à memória de alguém sobre o que aconteceu. No Windows as leituras equivalentes são Get-NetAdapter, Get-NetRoute e Get-DnsClientServerAddress, que não exigem elevação mas mostram os mesmos restos.