Um perfil do Access Server bloqueado ao utilizador é gerado para uma conta e recusa todas as outras, pelo que o passo de transferência decide a quem pertence o ficheiro antes de qualquer definição do cliente contar. A ordem abaixo é a que dou a quem pede «o ficheiro VPN»: inicie sessão como a pessoa que o vai usar, encontre o controlo para a sua versão do servidor, leia a que está bloqueado o ficheiro, confirme que a política permite esse tipo e depois entregue-o de uma forma em que ainda o possa revogar. Pare no primeiro passo que falhar; cada passo seguinte assume que o anterior se manteve.

Verificação 1: inicie sessão como a conta, não como o administrador

O portal do cliente é a interface de utilizador normal, habitualmente em https://vpn.example:943/, enquanto a administração está em https://vpn.example:943/admin. Estes são exemplos predefinidos; nomes de anfitrião, portas e proxies inversos alteram-nos, por isso use o endereço que o seu operador lhe deu. Iniciar sessão primeiro no caminho de administração é o erro mais comum, porque a sessão de administração pode criar e gerir contas mas não é a conta que vai transportar o túnel.

Se a pessoa ainda não consegue iniciar sessão, pare aqui e corrija isso primeiro: uma reposição de palavra-passe, uma atribuição de grupo em falta ou uma conta que só existe como entrada de autenticação importada vão bloquear a transferência seja qual for o navegador que tentar. Transferir a partir da própria sessão do administrador produz o perfil do administrador, e é exatamente o ficheiro que não deve acabar no portátil de outra pessoa.

Verificação 2: encontre o controlo de transferência para a sua versão

Depois de iniciar sessão, o portal mostra um controlo de perfil de ligação perto do topo da página. Para o Access Server 2.14 e posteriores, o tutorial descreve-o como uma secção Perfil de Ligação em «Transfira o seu perfil abaixo». Quando o portal também oferece um instalador OpenVPN Connect pré-configurado, são duas entregas diferentes: uma instala o cliente com o perfil já anexado, a outra dá-lhe um ficheiro para importar num cliente que já tem.

A versão conta aqui. Um portal mais antigo pode rotular o mesmo botão de forma diferente, e um portal muito personalizado pode movê-lo para baixo de um aviso. Se a secção faltar por completo, não comece a adivinhar URL: passe à verificação de política em vez de experimentar caminhos, porque um controlo em falta é quase sempre uma decisão do lado do servidor.

Verificação 3: leia a que está bloqueado o ficheiro

Um perfil bloqueado ao utilizador transporta um certificado de cliente e uma chave incorporados emitidos para um utilizador, e o servidor mapeia essa identidade para essa conta. Renomear o ficheiro, editar o nome apresentado ou escrever credenciais diferentes no pedido não altera o mapeamento, e é por isso que um perfil copiado falha para a segunda pessoa com um erro de autenticação ou de certificado em vez de um problema de encaminhamento. Veja dentro do ficheiro se precisar de confirmar o que tem:

grep -c "BEGIN CERTIFICATE" office-user.ovpn
grep -n "^remote " office-user.ovpn

A contagem de certificados diz-lhe que há uma identidade incorporada; as linhas remote apenas indicam o servidor. Dois ficheiros que apontam para o mesmo servidor podem, por isso, pertencer a pessoas diferentes, e um ficheiro que aponta para dois servidores continua ligado ao seu proprietário original. Os perfis bloqueados ao servidor e os perfis de início de sessão automático têm outra vez modelos de utilização permitidos diferentes: um perfil bloqueado ao servidor espera credenciais no momento da ligação, e um perfil de início de sessão automático ignora o pedido de palavra-passe por conceção. Nenhum deles se torna outro tipo ao editar o ficheiro.

Verificação 4: confirme que a política permite esse tipo

Que tipos de perfil existem é uma definição do administrador, não uma preferência do cliente. Se o portal só oferece uma transferência bloqueada ao utilizador, o servidor pode não permitir outro tipo, ou permitir um que o grupo da conta não recebe. Pedir ao administrador para ativar outro tipo para que apareça um botão em falta é uma alteração de política com consequências reais, e remover a autenticação multifator para chegar a uma página de transferência troca um controlo de autenticação por comodidade.

Consoante a versão, a interface web de administração também expõe a gestão de perfis para um utilizador, onde um administrador pode emitir ou revogar um perfil sem iniciar sessão como essa pessoa. Onde essa capacidade falta, o utilizador transfere o seu próprio ficheiro. Em qualquer caso, a fonte correta é a conta prevista, nunca um perfil de administrador copiado e tratado como modelo.

Verificação 5: entregue, e depois mantenha-o revogável

Trate a transferência como material de credenciais e não como um ficheiro de configuração. Um perfil bloqueado ao utilizador contém uma chave privada, por isso deve viajar por um canal que usaria para uma palavra-passe, não por uma pasta de disco partilhada nem por um grupo de conversa. Registe que utilizador e que dispositivo receberam que ficheiro, porque a revogação é por conta: quando um portátil é substituído ou se perde, o administrador revoga o acesso dessa pessoa e emite um novo perfil, e o ficheiro antigo deixa de funcionar na tentativa de ligação seguinte.

Termine com quatro verificações por esta ordem: o início de sessão no portal era o utilizador previsto, o ficheiro contém uma identidade e não apenas um endereço de servidor, uma ligação de teste a partir do cliente previsto tem sucesso, e uma segunda ligação com outra conta falha. Se a quarta tiver sucesso, distribuiu o ficheiro errado, e a revogação é o passo seguinte em vez de uma edição da configuração. O tutorial de transferência do Access Server mostra a disposição atual do portal e a diferença entre um perfil e um instalador pré-configurado.

Artigos relacionados