Cliente Fortinet para Linux: comprobe a pasarela antes de reparar

A guía arquivada di que instale bibliotecas de 32 bits, parche un tema GTK e execute o instalador desde un terminal. Parte dese consello era correcto para unha versión concreta do cliente, e nada diso pode devolver un modo de túnel que a pasarela xa non ofrece. Antes de cambiar un paquete, atope a primeira etapa que fallou. Isto vai da pasarela cara a dentro, porque alí as respostas son baratas e unha reparación local equivocada é o que máis tempo custa.

Comprobación 1: nomee a etapa que fallou

Tres etapas fallan de xeito distinto. O programa non arranca, arranca e rexeita a identidade do servidor, ou conéctase e a pasarela non ten un servizo do tipo que vostede necesita. Cada fallo deixa a súa propia evidencia: un erro do cargador, unha mensaxe de certificado, unha resposta da pasarela que nomea un modo non dispoñible.

Anóteo antes de tocar nada. Todo o que segue depende de que etapa nomeou, e as tres reparacións non teñen nada en común.

Comprobación 2: a versión da pasarela e o modo de túnel

O modo de túnel desapareceu nas pasarelas actuais, e a táboa de integración de FortiClient 7.4.4 con Linux é onde está escrito: FortiOS 7.6.3 e posteriores xa non ofrecen o modo de túnel SSL VPN e remiten os administradores a IPsec. Manteña o produto, a versión e o modo unidos a esa frase cando a repita. Non di nada sobre todos os produtos de Fortinet, nin sobre as funcións de acceso web que aínda existen. A compatibilidade xeral de versións e a dispoñibilidade dun modo de túnel son comprobacións separadas.

Pregunte ao propietario da pasarela dúas cousas: que versión executa a pasarela e que métodos de acceso están activados hoxe. Pida a resposta por escrito, coa cadea de versión e a páxina de configuración ou a liña de configuración de onde vén, porque unha garantía verbal é o que devolve a xente á guía arquivada. Despois comprobe esa resposta coas notas da pasarela ou a matriz do provedor para esa versión exacta. Un navegador que mostra o portal web demostra que o portal responde, e nada máis.

Comprobación 3: a edición do cliente que aproba o propietario

Obteña a edición e a versión aprobadas do cliente Linux e despois comprobe o sistema operativo, a arquitectura, o escritorio e o fluxo de autenticación que admite. A matriz 7.4.4 é un exemplo ligado a unha versión, non unha recomendación para o cliente máis recente nin unha promesa para cada derivado. Pregunte que cliente manterá realmente o propietario, porque esa resposta forma parte da migración e non é un engadido. Un cliente que morre antes de que o seu primeiro paquete chegue á pasarela demostra algo sobre o portátil, non sobre o servizo.

As bibliotecas de 32 bits e un tema parcheado cambian o que o binario pode cargar; non cambian o que admite o provedor. Se o sistema operativo ou o fluxo de autenticación quedan fóra da matriz, a pregunta de cualificación xa está respondida.

Comprobación 4: solicite o perfil de substitución

Se a organización pasou do modo de túnel SSL VPN a IPsec, solicite o perfil novo e o procedemento de alta na mesma conversa. Non cambie o nome dunha configuración SSL e supoña que os campos se trasladan: un perfil IPsec nomea unha versión de IKE, unha pasarela remota e a súa identidade, un método de autenticación e os selectores de tráfico que acepta cada lado. A política de conta e dispositivo tamén se pode aplicar doutro xeito. Un cambio de nome produce un cliente que parece configurado e non negocia nada.

Lea o perfil antes de confiar nel. Debe indicar a versión de IKE e as propostas, se a autenticación usa un certificado ou unha clave precompartida, que subredes locais e remotas se seleccionan e que espera a pasarela como identidade propia. Confirme que o cliente Linux aprobado admite esa disposición, porque un documento de migración non é unha declaración de paridade de funcións para cada versión do cliente. Un cliente independente como openfortivpn non é un intérprete de OpenVPN, así que trate calquera outra cousa con SSL no nome como non aprobada ata que o propietario diga o contrario para este modo, este fluxo de inicio de sesión e esta política de dispositivos.

Comprobación 5: dependencias locais, e despois valide e rexistre

Coa pasarela e o cliente resoltos, un fallo de arranque é un problema de empaquetado, e as instrucións do propio paquete mantido son a referencia que hai que seguir. Un fallo de identidade TLS pertence ao operador: as ancoraxes de confianza e o nome esperado son a súa configuración, non algo que se evite localmente. Esas son as dúas etapas nas que a guía arquivada foi algunha vez útil.

Ningunha das dúas se resolve aceptando un certificado descoñecido nin desactivando unha comprobación de postura. Manteña as comprobacións de MFA e de dispositivo no seu sitio, porque recuperar a conectividade debilitándoas cambia unha caída por un incidente. Se o modo desapareceu, ningunha marca local o devolve.

Tras o cambio aprobado, chegue ao recurso privado previsto, confirme a resolución de DNS e volva conectarse unha vez. Rexistre o cliente, a plataforma, a versión da pasarela e o modo de túnel xuntos, porque a seguinte persoa necesita os catro. Un programa que se abre correctamente superou a etapa local de arranque, e nada máis.