RemoteEnable não é um login de VPN: delimitar a administração do SoftEther

O tutorial manda executar o RemoteEnable e depois conectar, e isso lê-se como se os dois passos fossem o mesmo tipo de coisa. Não são. O RemoteEnable concede a outra máquina permissão para administrar o serviço de cliente SoftEther VPN em execução neste computador. Conectar-se é uma conta de VPN que se autentica num servidor, e nisso não há qualquer permissão de administração envolvida.

O mito: o RemoteEnable liga a VPN

A confusão vem da proximidade. Um guia ativa a administração remota, reinicia o serviço de cliente, liga-se em seguida, e a ligação funciona depois, por isso os dois passos parecem ligados causalmente. O que realmente mudou é quem pode falar com o serviço, não se o serviço consegue alcançar um servidor. Desative a administração remota num cliente configurado corretamente e a ligação de VPN ainda assim estabelece-se.

A ajuda do comando no projeto original é explícita quanto ao âmbito: administração remota através do VPN Client Manager ou do vpncmd de fora do localhost. Nada nessa descrição menciona um túnel, uma conta ou uma rota. A permissão concedida é alcance administrativo, e o seu objeto é o serviço de cliente, não a ligação.

Três identidades que partilham a palavra palavra-passe

Os guias antigos usam uma única palavra para três credenciais sem relação, e é assim que as implementações acabam com um segredo colado no campo errado.

A palavra-passe de administração do serviço de cliente protege a administração do cliente SoftEther local. A palavra-passe da conta de VPN autentica-se num servidor segundo a política desse servidor. O certificado do servidor não é de todo uma palavra-passe, mas responde a que ponto final o cliente deve aceitar. Alterar uma delas não altera as outras, e copiar um valor entre elas produz uma configuração diferente em vez de uma mais simples.

A opção só-remoto na palavra-passe de administração merece uma segunda análise, porque decide se o requisito de palavra-passe também se aplica à administração a partir da máquina local. Restringir esse âmbito é uma escolha deliberada para um portátil de um só utilizador, não uma alternativa para uma palavra-passe que ninguém registou.

O que ativar a administração remota muda realmente

Daí resultam duas consequências operacionais, e ambas são fáceis de perder num guia de copiar e colar. Uma palavra-passe de administração passa a ser obrigatória assim que a administração remota é ativada, e a nova disponibilidade só entra em vigor depois de o serviço de cliente ser reiniciado.

Esse reinício é uma interrupção real para tudo o que usa o cliente, por isso planeie-o com quem é dono da máquina. Ativar a funcionalidade também não abre por si só um caminho na firewall: o serviço continua a ter de ser alcançável a partir da estação de administração, e uma firewall do anfitrião ou uma ACL a montante podem mantê-lo inalcançável. Um serviço inalcançável não é prova de que a permissão foi bem delimitada, apenas de que algo mais o está a bloquear.

Escreva o caminho de administração previsto nas notas de implementação, incluindo a porta e o intervalo de endereços que o podem usar. Essa nota é também o lugar para registar quem pediu a capacidade e quando deve ser retirada.

Decida quem pode administrar este cliente

Num portátil que seja seu, mantenha a administração na consola local, a menos que consiga nomear a máquina que precisa de acesso remoto e dizer porquê. Para um dispositivo administrado centralmente, nomeie o administrador, o caminho de administração e o responsável pela recuperação antes de ativar seja o que for. A questão não é se a funcionalidade é conveniente, mas quem responde pela configuração que ela expõe.

Execute os comandos contra o serviço local para que a alteração fique no seu próprio histórico de shell e não numa captura de ecrã: vpncmd localhost /client /cmd RemoteDisable desativa a capacidade, e o mesmo comando com RemoteEnable ativa-a. Reinicie o serviço a seguir, ou a definição não ficará em vigor.

Se um tutorial a ativa como passo preliminar sem explicação, trate isso como uma pergunta por resolver e não como uma instrução a seguir. Pergunte que estação de administração a deve usar, e se não houver resposta, deixe a capacidade desativada.

Verifique o acesso de administração e a conetividade em separado

Dois testes respondem a duas perguntas diferentes, e executar apenas um deles é a forma de uma implementação acabar com administração remota que ninguém pretendia.

vpncmd localhost /client /cmd RemoteDisable
systemctl restart vpnclient
vpncmd localhost /client /cmd AccountList
vpncmd localhost /client /cmd NicList

As duas primeiras linhas devolvem o cliente à administração local e aplicam a alteração. As duas últimas confirmam que as contas de VPN e os adaptadores virtuais continuam configurados, como deveriam estar, porque o âmbito de administração e o estado da ligação são definições independentes. Se a lista de contas voltar vazia após o reinício, algo mais se avariou e a definição de administração remota não é a explicação.

Depois teste a própria ligação a partir do cliente e confirme que o adaptador mantém o endereço e as rotas esperadas. Uma sessão de vpncmd bem-sucedida prova uma relação de controlo e não diz nada sobre se o tráfego sai pelo túnel.