O adaptador virtual do SoftEther aparece mas não envia tráfego

Um adaptador virtual do SoftEther aparece na lista de redes do sistema operativo, declara-se desligado e não transporta qualquer tráfego. Essa combinação é normal num dispositivo sem sessão associada, e também é o estado que vê quando tem um perfil errado ligado a ele. O adaptador é um dispositivo que o sistema operativo possui; a sessão é o que lhe dá vida. Percorra estas quatro verificações por ordem e pare na primeira que falhar.

Separe o dispositivo da sessão

Criar o adaptador instala um dispositivo de rede; não se autentica em nenhum servidor. Confirme o que diz a lista de ligações do cliente antes de tirar conclusões do estado da interface. Um perfil que não está ligado explica o estado desligado sem mais investigação.

O adaptador e a interface física têm funções diferentes. Um transporta o tráfego decifrado que as aplicações veem, e o outro transporta a ligação exterior cifrada até ao servidor. Confundir os dois faz com que as regras da firewall e as rotas sejam aplicadas ao dispositivo errado. As regras escritas para a interface física não corresponderão ao tráfego do túnel, e as regras escritas para o túnel não afetarão a ligação exterior.

Associe um adaptador a um perfil

Cada adaptador deve estar associado ao perfil de ligação que pretende, e essa associação deve ser visível no cliente em vez de memorizada. Quando existem vários adaptadores, anote qual perfil possui qual dispositivo antes de tocar em qualquer um deles. Reutilizar um adaptador entre perfis é a forma como um endereço antigo sobrevive a uma religação.

Se o cliente oferecer uma forma suportada de recriar a associação, use-a em vez de editar diretamente a configuração do sistema operativo. O cliente escreve as definições do adaptador ao ligar, por isso as alterações manuais tendem a desaparecer ou a entrar em conflito na sessão seguinte.

Leia as definições efetivas após ligar

Depois de a sessão estar ativa, leia o endereço, a rota e o resolver do sistema. O painel de estado do cliente descreve o que pediu, enquanto o kernel descreve o que aconteceu realmente.

ip -brief address show
ip route get 10.20.30.41
resolvectl status | head -20

A lista de endereços mostra se o adaptador recebeu alguma coisa, e um adaptador sem endereço após um início de sessão bem-sucedido aponta para a configuração do perfil e não para o controlador. A consulta de rota mostra que interface transportaria um destino privado, e é aí que uma rota ausente se torna visível. A saída do resolver mostra se o DNS seguiu a sessão, uma vez que uma ligação funcional com DNS local continua a produzir uma ligação meio quebrada.

Um adaptador criado sem definições úteis pode coexistir com um início de sessão de gestão bem-sucedido noutro ponto do cliente. Os dois painéis respondem a perguntas diferentes, por isso um nunca é prova do outro. Quando não concordam, a visão do sistema é a que as aplicações experimentam.

Pare antes de fazer ponte ou apagar

Fazer ponte entre o adaptador virtual e um físico é uma alteração de projeto, não uma reparação. Funde duas fronteiras de rede e não é forma de corrigir uma rota ausente. Se a implementação precisar dessa disposição, precisa de um projeto autorizado e de um plano de testes.

Apagar um adaptador é igualmente destrutivo quando outro serviço o utiliza. Identifique primeiro o proprietário, incluindo qualquer outro cliente ou produto de virtualização na máquina que tenha criado uma interface com um nome semelhante. Um dispositivo que reaparece após a remoção diz-lhe que algo o está a recriar.

Termine testando a aplicação, não o adaptador. Uma partilha de ficheiros ou uma página de intranet que carrega pelo túnel é a prova de que o dispositivo, a sessão e a rota estão de acordo.