GVC travado em Acquiring IP: não é um problema de senha

O Global VPN Client fica parado em Acquiring IP, e o reflexo é digitar a senha novamente ou reinstalar o cliente. Nenhum dos dois toca na etapa que falhou. A autenticação terminou antes de o cliente sequer pedir um endereço, então não são as credenciais que o mantêm nessa linha. O que o mantém ali é uma troca DHCP que não terminou, e ela pode travar em três lugares diferentes.

A autenticação e a atribuição de endereço são etapas separadas

O GVC primeiro prova quem você é, depois solicita as configurações do seu adaptador virtual conforme a política atribuída à sua conexão. São passos sequenciais com assinaturas de falha diferentes. Credenciais erradas costumam falhar mais cedo, com uma mensagem de autenticação ou negociação em vez da linha de endereço.

Essa ordem explica por que redefinir a senha, criar um novo usuário local ou reinstalar não muda nada aqui. O cliente já está autorizado; agora espera uma concessão que o gateway ou o seu parceiro DHCP deve fornecer. Mesmo uma política que permite o usuário mas não atribui nenhuma faixa de endereços produz exatamente esta tela.

Portanto, a primeira pergunta útil não é se as credenciais estão corretas, mas qual política foi atribuída e o que ela diz sobre o endereçamento do adaptador virtual. Leia a configuração efetiva dessa conexão em vez da captura de tela que funciona na máquina de um colega.

De onde a concessão realmente vem

Dois modelos são comuns. O firewall pode manter ele próprio um escopo DHCP para clientes VPN, ou encaminhar o pedido para um servidor DHCP externo na rede interna. O modelo determina quais registros importam e para quem ligar.

No modelo interno, verifique se o escopo ainda existe, pertence à interface correta e tem concessões livres. Um escopo esgotado produz um cliente que se autentica perfeitamente e nunca recebe um endereço, e o registro do gateway pode mostrar apenas o pedido. No modelo de encaminhamento, o destino do encaminhamento, a rota de volta para a faixa de clientes VPN e qualquer autorização DHCP interna têm de coincidir.

Anote qual modelo a sua implementação usa antes de testar qualquer coisa. Metade dos conselhos contraditórios online assume o outro.

Um túnel pode estar ativo e ainda assim perder a concessão

Uma conexão de controle estabelecida prova que a negociação funcionou, não que os dados do túnel passam nos dois sentidos. A troca DHCP precisa de pedido e resposta para sobreviver ao caminho de dados, e é aí que vivem as configurações de criptografia, a política da zona VPN e os problemas de MTU.

O conselho sobre NAT traversal é o exemplo mais claro de que o contexto importa. Alguns caminhos precisam dele ativo, outros só funcionam desativado, e o NAT intermediário junto com a conexão negociada decidem qual. Alterá-lo às cegas enquanto também muda configurações do cliente significa que você não saberá qual alteração produziu o resultado. Anote o caminho negociado e as provas antes de alterar o encapsulamento.

Reiniciar o roteador de casa pertence à mesma categoria. Às vezes elimina o sintoma, mas não identifica por que a concessão falhou, e o problema volta na conexão seguinte.

Percorra o caminho da concessão em ordem

Comece no adaptador e avance para fora, para que cada passo só possa falhar por uma razão:

> Get-NetAdapter | Where-Object Name -like "*GVC*"
> ipconfig /all | findstr /i /c:"GVC" /c:"IPv4" /c:"DHCP"
> Test-NetConnection 10.60.0.1 -Port 443

Um endereço como 169.254.x.x significa que o adaptador existe e não recebeu qualquer resposta, o que aponta para a origem da concessão ou para o caminho de dados. Um endereço correto na faixa VPN com entradas DNS erradas é outra avaria: a concessão funcionou e a política forneceu configurações incompletas. Um adaptador que nunca aparece significa que o cliente não chegou a criá-lo.

Assim que aparecer uma concessão, teste o recurso real em vez de declarar vitória na linha de endereço. Se o acesso a arquivos ou à intranet continuar falhando, guarde a concessão bem-sucedida como prova e passe à resolução de nomes ou à política, porque você já deixou a avaria original para trás.

A nota da SonicWall sobre o adaptador virtual enumera vários ramos separados, e as capturas de tela antigas não devem ser lidas como o mapa atual do menu. Use-a para confirmar a etapa alcançada, não como uma lista de verificação a aplicar por inteiro.