Cisco Secure Client bloqueia a VPN a partir de uma sessão RDP

O início de sessão é bem-sucedido e o túnel não sobe. Essa combinação confunde, porque é lida como um problema de autenticação, e depois se passa a tarde a repor credenciais que nunca foram a causa. Um Cisco Secure Client pode recusar-se a estabelecer uma VPN exatamente porque a tentativa veio de uma sessão de Ambiente de Trabalho Remoto, e essa decisão é tomada por política do lado do cliente.

Onde isto aparece no fluxo de ligação

Percorra o cliente de cima para baixo. O perfil é carregado, as credenciais são recolhidas e a autenticação termina. Depois, antes de qualquer túnel ser construído, o cliente avalia as definições de sessão e de estabelecimento face ao ambiente em que se encontra.

Anote três coisas nesse momento: a mensagem exata, a versão do cliente e o nome do perfil mostrado no cliente. Essas três transformam uma queixa vaga num pedido de suporte sobre o qual alguém pode agir. Tire uma captura de ecrã da caixa de diálogo, porque as mensagens longas são truncadas no registo. Anote também a hora, para que o administrador a possa comparar com o concentrador.

A definição que realmente decide

A política Windows VPN Establishment é o controlo relevante e tem dois valores documentados: apenas utilizadores locais, e permitir utilizadores remotos. A segunda permite estabelecer um túnel a partir de uma sessão de Ambiente de Trabalho Remoto numa configuração suportada. A primeira é a postura predefinida em muitos perfis empresariais.

Não a confunda com Windows Logon Enforcement, que o guia do perfil documenta como uma política separada sobre sessões de início de sessão. Uma rege que sessão pode construir o túnel, a outra rege o comportamento simultâneo ou antes do início de sessão. Alterar a errada não produz qualquer efeito visível.

Leia o perfil que é realmente aplicado

Numa implementação gerida, o cliente recebe o perfil do concentrador ou de um local gerido, e uma cópia editada no disco frequentemente não é a que está em vigor. Por isso uma alteração local no XML pode parecer correta e não mudar nada.

Pergunte ao administrador que perfil e que política de grupo o dispositivo recebe, em vez de que ficheiro existe no portátil. Os dois raramente concordam após uma atualização de versão. Uma cópia obsoleta na pasta local ainda abre no editor e ainda parece correta. Simplesmente não é o que o cliente aplicou.

O caminho RDP depois de o túnel subir

Permitir o estabelecimento remoto não garante que a sua sessão de Ambiente de Trabalho Remoto sobreviva. Quando o túnel muda rotas ou regras de acesso locais, a sessão que o trouxe para dentro pode perder o caminho que a sustenta.

Planeie um canal de recuperação antes da alteração: acesso à consola, um caminho de gestão fora de banda ou um procedimento de reconexão documentado. Decidir isso depois significa geralmente uma deslocação até à máquina.

Não use truques para roubar sessões, ferramentas alternativas de controlo remoto nem uma palavra-passe escrita num script para contornar a política. Se a organização não autoriza este fluxo de trabalho, o passo correto é o caminho de administração que ela suporta.

O que enviar ao administrador

Dê-lhe o texto da mensagem, a versão do cliente, o nome do perfil ativo, o tipo de sessão por onde se ligou e se uma tentativa a partir da consola local se comporta de forma diferente. Acrescente o carimbo temporal.

É exatamente essa última comparação que poupa tempo, porque separa uma recusa por política de sessão de uma falha em todo o dispositivo.

Verifique após uma alteração aprovada

Depois de o perfil ser atualizado, estabeleça uma nova sessão RDP e ligue-se de novo, e depois execute deliberadamente a sequência de desconexão. Confirme que o túnel sobe, que o caminho de gestão sobrevive e que a sua conta ainda consegue iniciar sessão no ambiente de trabalho.

A admissão na VPN, a sobrevivência da sessão e a permissão de início de sessão do Windows são três verificações separadas. Passar uma não diz nada sobre as outras duas.