Cliente SoftEther na inicialização: AccountStartupSet e a ordem do daemon

Reiniciar a máquina deixa-a na rede com o túnel novamente em baixo. O cliente do SoftEther guarda dois estados que a maioria das pessoas trata como um só: se o serviço está em execução e se uma conta guardada pode subir com ele. Ambos têm de ser verdadeiros, e o segundo é um sinalizador por conta, não uma definição de arranque. Execute as quatro verificações abaixo por ordem e pare na primeira falha.

Confirme que a conta está marcada para início automático

O sinalizador vive no registo da conta dentro da própria configuração do cliente, por isso reinstalar o cliente ou restaurar um diretório vazio apaga-o. Abra a consola de gestão e veja a lista de contas antes de alterar qualquer outra coisa.

cd /opt/softether/vpnclient
./vpncmd

Escolha 2 para a gestão do cliente VPN e aceite o servidor local premindo Enter.

AccountStartupSet
office-hub
exit

O AccountStartupSet registe a conta como uma que deve subir quando o serviço do cliente arranca. Não inicia o serviço nem cria uma nova conta, e não imprime nada de útil quando o nome está errado. Volte a ler a lista de contas depois do comando, porque um erro de escrita é silencioso e parece exatamente um sinalizador que não teve efeito.

Confirme que o serviço arranca, e cedo o suficiente

No Linux o cliente corre como daemon a partir do seu próprio diretório e tem de estar ativo antes de qualquer passo de arranque tentar usar a conta. Um gancho curto que muda de diretório e o inicia basta em sistemas que ainda executam rc.local.

cd /opt/softether/vpnclient
./vpnclient start

Onde o rc.local já não existe, escreva uma unidade systemd com um WorkingDirectory explícito e uma política de reinício. O binário resolve a configuração relativamente ao local de onde é iniciado, por isso uma unidade sem essa definição pode arrancar com sucesso e não ler nada. A ordem é a segunda metade do problema: uma tentativa de ligação que corre antes de o daemon escutar falha de forma intermitente, o que é muito mais difícil de diagnosticar do que uma falha constante. Uma política de reinício cobre o terceiro caso, em que o daemon morre em silêncio horas depois.

Verifique a lista de processos em vez de confiar num ficheiro pid deixado pelo arranque anterior.

Confirme que o adaptador recebeu um endereço

Assim que a conta liga, o cliente apresenta um adaptador virtual e o adaptador ainda precisa de um endereço. Um hub com SecureNAT responde normalmente ao DHCP; um hub ligado por ponte a uma LAN física espera que, em vez disso, responda o servidor dessa LAN.

ip -brief address
dhclient vpn_vpn1

Retire o nome da interface da listagem, porque o número num exemplo não é uma constante. Se o endereço tiver de ser estático, coloque-o na configuração de rede da distribuição para essa interface, para que seja reaplicado após um evento de ligação e não apenas no arranque. Um script de uma só execução deixa o adaptador sem endereço na primeira vez que o túnel se volta a ligar durante o dia. Essa falha parece um túnel morto embora a conta esteja bem.

Um adaptador sem endereço é a falha mais silenciosa da lista, uma vez que a conta continua a reportar-se ligada.

Confirme que a rota aponta para onde pensa

O tráfego pode continuar a falhar com uma ligação saudável e um endereço válido. Pergunte ao kernel que interface usaria para um destino dentro da sub-rede do hub e depois compare essa resposta com o túnel.

ip route get 10.10.20.15

Uma sub-rede local que se sobreponha ao intervalo do hub ganha, porque a sua rota é mais específica e já está instalada.

Isso é uma decisão de numeração e não um erro do cliente, e reiniciar o serviço não a altera. A configuração do resolver é a outra metade: um endereço sem um servidor DNS funcional produz um túnel que passa todas as verificações de ligação e ainda assim não consegue abrir um nome.

Escreva as quatro verificações nas notas de reconstrução

Registe em conjunto o nome da conta, o comando de início do serviço e o nome da interface, porque um anfitrião reconstruído restaura os dados da conta mas não o gancho do sistema operativo que lança o daemon. Esses vivem em locais diferentes e normalmente são salvaguardados por pessoas diferentes.

O sinalizador é uma linha para reaplicar e fácil de esquecer.

Mantenha a ordem: sinalizador, serviço, endereço, rota. Uma lista de verificação que começa pelo meio produz muitas respostas erradas e confiantes.