Cliente Fortinet para Linux: verifique o gateway antes de reparar

O guia arquivado diz para instalar bibliotecas de 32 bits, aplicar um patch a um tema GTK e executar o instalador a partir de um terminal. Parte desse conselho estava correta para uma versão específica do cliente, e nada disso repõe um modo de túnel que o gateway já não oferece. Antes de alterar um pacote, encontre a primeira fase que falhou. Isto avança do gateway para dentro, porque é aí que as respostas são baratas e é uma correção local errada que consome mais tempo.

Verificação 1: nomeie a fase que falhou

Três fases falham de formas diferentes. O programa não arranca, arranca e rejeita a identidade do servidor, ou liga-se e o gateway não tem um serviço do tipo de que precisa. Cada falha deixa a sua própria evidência: um erro do carregador, uma mensagem de certificado, uma resposta do gateway que nomeia um modo indisponível.

Anote isso antes de tocar em qualquer coisa. Tudo o que vem depois deste ponto depende da fase que nomeou, e as três correções não têm nada em comum.

Verificação 2: a versão do gateway e o modo de túnel

O modo de túnel desapareceu nos gateways atuais, e a tabela de integração do FortiClient 7.4.4 com Linux é onde isso está escrito: o FortiOS 7.6.3 e posteriores já não oferecem o modo de túnel SSL VPN e encaminham os administradores para IPsec. Mantenha o produto, a versão e o modo ligados a essa frase quando a repetir. Não diz nada sobre todos os produtos Fortinet, nem sobre funcionalidades de acesso web que ainda existem. A compatibilidade geral de versões e a disponibilidade de um modo de túnel são verificações separadas.

Pergunte ao proprietário do gateway duas coisas: que versão o gateway executa e que métodos de acesso estão ativos hoje. Peça a resposta por escrito, com a cadeia de versão e a página de definições ou a linha de configuração de onde veio, porque é uma garantia verbal que devolve as pessoas ao guia arquivado. Depois confirme essa resposta com as notas do gateway ou a matriz do fornecedor para essa versão exata. Um navegador que mostra o portal web prova que o portal responde, e nada mais.

Verificação 3: a edição do cliente que o proprietário aprova

Obtenha a edição e a versão aprovadas do cliente Linux e verifique depois o sistema operativo, a arquitetura, o ambiente de trabalho e o fluxo de autenticação suportados. A matriz 7.4.4 é um exemplo ligado a uma versão, não uma recomendação para o cliente mais recente nem uma promessa para cada derivado. Pergunte que cliente o proprietário vai realmente suportar, porque essa resposta faz parte da migração e não é um acrescento. Um cliente que morre antes de o primeiro pacote chegar ao gateway prova algo sobre o portátil, não sobre o serviço.

Bibliotecas de 32 bits e um tema corrigido alteram o que o binário consegue carregar; não alteram o que o fornecedor suporta. Se o sistema operativo ou o fluxo de autenticação ficar fora da matriz, a pergunta de qualificação já está respondida.

Verificação 4: peça o perfil de substituição

Se a organização passou do modo de túnel SSL VPN para IPsec, peça o novo perfil e o procedimento de registo na mesma conversa. Não mude o nome de uma configuração SSL e assuma que os campos transitam: um perfil IPsec indica uma versão de IKE, um gateway remoto e a sua identidade, um método de autenticação e os seletores de tráfego que cada lado aceita. A política de conta e de dispositivo também pode ser aplicada de forma diferente. Uma mudança de nome produz um cliente que parece configurado e não negoceia nada.

Leia o perfil antes de confiar nele. Deve indicar a versão de IKE e as propostas, se a autenticação usa um certificado ou uma chave pré-partilhada, que sub-redes locais e remotas são selecionadas e o que o gateway espera como sua identidade. Confirme que o cliente Linux aprovado suporta essa disposição, porque um documento de migração não é uma declaração de paridade de funcionalidades para cada versão do cliente. Um cliente independente como o openfortivpn não é um interpretador de OpenVPN, por isso trate tudo o resto com SSL no nome como não aprovado até o proprietário dizer o contrário para este modo, este fluxo de início de sessão e esta política de dispositivos.

Verificação 5: dependências locais, e depois valide e registe

Com o gateway e o cliente resolvidos, uma falha de arranque é um problema de empacotamento, e as instruções do próprio pacote mantido são a referência a seguir. Uma falha de identidade TLS pertence ao operador: as âncoras de confiança e o nome esperado são a sua configuração, não algo a contornar localmente. São as duas fases em que o guia arquivado alguma vez foi útil.

Nenhuma das duas se resolve aceitando um certificado desconhecido ou desativando uma verificação de postura. Mantenha as verificações de MFA e de dispositivo no lugar, porque recuperar a conetividade enfraquecendo-as troca uma interrupção por um incidente. Se o modo desapareceu, nenhuma opção local o traz de volta.

Após a alteração aprovada, chegue ao recurso privado pretendido, confirme a resolução de DNS e volte a ligar uma vez. Registe o cliente, a plataforma, a versão do gateway e o modo de túnel em conjunto, porque a pessoa seguinte precisa dos quatro. Um programa que abre com sucesso passou a fase local de arranque, e nada mais.