Client Fortinet per Linux: controllate il gateway prima di riparare

La guida archiviata dice di installare librerie a 32 bit, applicare una patch a un tema GTK ed eseguire l’installer da un terminale. Parte di quel consiglio era corretta per una specifica versione del client, e nulla di tutto ciò può riportare indietro una modalità tunnel che il gateway non offre più. Prima di cambiare un pacchetto, trovate la prima fase che ha fallito. Questo procede dal gateway verso l’interno, perché è lì che le risposte costano poco ed è una correzione locale sbagliata a far perdere più tempo.

Controllo 1: nominate la fase che ha fallito

Tre fasi falliscono in modi diversi. Il programma non parte, parte e rifiuta l’identità del server, oppure si connette e il gateway non ha un servizio del tipo che vi serve. Ogni fallimento lascia la propria prova: un errore del loader, un messaggio di certificato, una risposta del gateway che nomina una modalità non disponibile.

Scrivetelo prima di toccare qualsiasi cosa. Tutto ciò che segue dipende da quale fase avete nominato, e le tre correzioni non hanno nulla in comune.

Controllo 2: la versione del gateway e la modalità tunnel

La modalità tunnel è sparita sui gateway attuali, e la tabella di integrazione di FortiClient 7.4.4 per Linux è il punto in cui questo è scritto: FortiOS 7.6.3 e successivi non offrono più la modalità tunnel SSL VPN e indirizzano gli amministratori verso IPsec. Tenete il prodotto, la versione e la modalità legati a quella frase quando la ripetete. Non dice nulla su ogni prodotto Fortinet, né sulle funzioni di accesso web che esistono ancora. La compatibilità generale delle versioni e la disponibilità di una modalità tunnel sono controlli separati.

Chiedete al proprietario del gateway due cose: quale versione esegue il gateway e quali metodi di accesso sono abilitati oggi. Chiedete la risposta per iscritto, con la stringa di versione e la pagina delle impostazioni o la riga di configurazione da cui proviene, perché è un’assicurazione verbale a rimandare le persone alla guida archiviata. Poi verificate quella risposta con le note del gateway o la matrice del fornitore per quella versione esatta. Un browser che mostra il portale web dimostra che il portale risponde, e nulla di più.

Controllo 3: l’edizione del client che il proprietario approva

Ottenete l’edizione e la versione approvate del client Linux, poi verificate il sistema operativo, l’architettura, il desktop e il flusso di autenticazione supportati. La matrice 7.4.4 è un esempio legato a una versione, non una raccomandazione per il client più recente né una promessa per ogni derivato. Chiedete quale client il proprietario supporterà davvero, perché quella risposta fa parte della migrazione e non è un ripensamento. Un client che muore prima che il suo primo pacchetto raggiunga il gateway dimostra qualcosa sul portatile, non sul servizio.

Le librerie a 32 bit e un tema aggiornato cambiano ciò che il binario può caricare; non cambiano ciò che il fornitore supporta. Se il sistema operativo o il flusso di autenticazione restano fuori dalla matrice, la domanda di qualificazione ha già risposta.

Controllo 4: richiedete il profilo sostitutivo

Se l’organizzazione è passata dalla modalità tunnel SSL VPN a IPsec, richiedete il nuovo profilo e la procedura di registrazione nella stessa conversazione. Non rinominate una configurazione SSL e non date per scontato che i campi si trasferiscano: un profilo IPsec nomina una versione IKE, un gateway remoto e la sua identità, un metodo di autenticazione e i selettori di traffico che ciascun lato accetta. Anche i criteri di account e dispositivo possono essere applicati diversamente. Una rinomina produce un client che sembra configurato e non negozia nulla.

Leggete il profilo prima di fidarvi. Deve indicare la versione IKE e le proposte, se l’autenticazione usa un certificato o una chiave precondivisa, quali sottoreti locali e remote sono selezionate e ciò che il gateway si aspetta come propria identità. Confermate che il client Linux approvato supporti questa impostazione, perché un documento di migrazione non è una dichiarazione di parità di funzioni per ogni versione del client. Un client indipendente come openfortivpn non è un interprete di OpenVPN, quindi trattate qualsiasi altra cosa con SSL nel nome come non approvata finché il proprietario non dica il contrario per questa modalità, questo flusso di accesso e questi criteri dei dispositivi.

Controllo 5: dipendenze locali, poi validate e registrate

Con gateway e client chiariti, un fallimento di avvio è un problema di pacchettizzazione, e le istruzioni del pacchetto mantenuto sono il riferimento da seguire. Un fallimento di identità TLS appartiene all’operatore: le ancore di fiducia e il nome atteso sono la sua configurazione, non qualcosa da aggirare localmente. Sono le due fasi in cui la guida archiviata è stata mai utile.

Nessuno dei due si risolve accettando un certificato sconosciuto o disattivando un controllo di postura. Tenete in piedi i controlli MFA e del dispositivo, perché ripristinare la connettività indebolendoli scambia un’interruzione con un incidente. Se la modalità è sparita, nessun flag locale la riporta.

Dopo la modifica approvata, raggiungete la risorsa privata prevista, confermate la risoluzione DNS e riconnettetevi una volta. Registrate client, piattaforma, versione del gateway e modalità tunnel insieme, perché la persona successiva ha bisogno di tutti e quattro. Un programma che si apre correttamente ha superato la fase locale di avvio, e nulla di più.