Fortinet Linux-klient: kontrollera gatewayen innan du reparerar

Den arkiverade guiden säger att du ska installera 32-bitars bibliotek, patcha ett GTK-tema och köra installationsprogrammet från en terminal. En del av rådet var korrekt för en viss klientutgåva, och inget av det kan återställa ett tunnelläge som gatewayen inte längre erbjuder. Innan du ändrar ett paket, hitta det första steget som misslyckades. Detta går från gatewayen och inåt, eftersom svaren är billiga där och en felaktig lokal åtgärd kostar mest tid.

Kontroll 1: namnge steget som misslyckades

Tre steg misslyckas på olika sätt. Programmet startar inte, det startar och avvisar serverns identitet, eller det ansluter och gatewayen har ingen tjänst av den typ du behöver. Varje fel lämnar sitt eget bevis: ett laddarfel, ett certifikatmeddelande, ett gatewaysvar som namnger ett otillgängligt läge.

Skriv ner det innan du rör något. Allt efter denna punkt beror på vilket steg du namngav, och de tre åtgärderna har inget gemensamt.

Kontroll 2: gatewayens utgivning och tunnelläget

Tunnelläget är borta på nuvarande gatewayer, och FortiClient 7.4.4-integreringstabellen för Linux är där det står skrivet: FortiOS 7.6.3 och senare erbjuder inte längre tunnelläget SSL VPN och hänvisar administratörer till IPsec. Håll produkten, utgivningen och läget knutna till den meningen när du upprepar den. Den säger ingenting om alla Fortinet-produkter och ingenting om webbåtkomstfunktioner som fortfarande finns. Allmän versionskompatibilitet och tillgången till ett tunnelläge är separata kontroller.

Fråga gatewayens ägare om två saker: vilken utgivning gatewayen kör och vilka åtkomstmetoder som är aktiverade i dag. Be om svaret skriftligt, med utgivningssträngen och den inställningssida eller konfigurationsrad den kommer från, eftersom det är en muntlig försäkran som skickar folk tillbaka till den arkiverade guiden. Kontrollera sedan svaret mot gatewayens anteckningar eller leverantörens matris för exakt den utgivningen. En webbläsare som visar webbportalen bevisar att portalen svarar, och inget mer.

Kontroll 3: klientutgåvan som ägaren godkänner

Skaffa den godkända Linux-klientutgåvan och versionen och kontrollera sedan det operativsystem, den arkitektur, det skrivbord och det autentiseringsflöde som stöds. Matrisen 7.4.4 är ett versionsbundet exempel, inte en rekommendation för den nyaste klienten och inte ett löfte för varje avledning. Fråga vilken klient ägaren faktiskt kommer att stödja, eftersom det svaret är en del av migreringen och inte en eftertanke. En klient som dör innan dess första paket når gatewayen bevisar något om den bärbara datorn, inte om tjänsten.

32-bitars bibliotek och ett patchat tema ändrar vad binärfilen kan läsa in; de ändrar inte vad leverantören stöder. Om operativsystemet eller autentiseringsflödet ligger utanför matrisen är kvalificeringsfrågan redan besvarad.

Kontroll 4: begär ersättningsprofilen

Om organisationen har flyttat från SSL VPN-tunnelläge till IPsec, begär den nya profilen och registreringsproceduren i samma samtal. Byt inte namn på en SSL-konfiguration och anta att fälten följer med: en IPsec-profil anger en IKE-version, en fjärrgateway och dess identitet, en autentiseringsmetod och de trafikväljare som varje sida accepterar. Även konto- och enhetspolicy kan tillämpas annorlunda. Ett namnbyte ger en klient som ser konfigurerad ut och inte förhandlar något.

Läs profilen innan du litar på den. Den ska ange IKE-versionen och förslagen, om autentisering använder ett certifikat eller en fördelad nyckel, vilka lokala och fjärranslutna subnät som väljs och vad gatewayen förväntar sig som sin identitet. Bekräfta att den godkända Linux-klienten stöder den ordningen, eftersom ett migreringsdokument inte är en förklaring om funktionslikhet för varje klientutgåva. En oberoende klient som openfortivpn är inte en OpenVPN-tolk, så behandla allt annat med SSL i namnet som icke godkänt tills ägaren säger annat för det här läget, det här inloggningsflödet och den här enhetspolicyn.

Kontroll 5: lokala beroenden, och validera och registrera sedan

När gatewayen och klienten är klarlagda är ett startfel ett paketeringsproblem, och det underhållna paketets egna instruktioner är referensen att följa. Ett TLS-identitetsfel tillhör operatören: förtroendeankare och det förväntade namnet är deras konfiguration, inte något som kringgås lokalt. Det är de två steg där den arkiverade guiden någonsin var användbar.

Inget av dem löses genom att acceptera ett okänt certifikat eller stänga av en tillståndskontroll. Behåll MFA- och enhetskontrollerna på plats, eftersom att återställa anslutningen genom att försvaga dem byter ett avbrott mot en incident. Om läget är borta finns det ingen lokal flagga som tar tillbaka det.

Nå den avsedda privata resursen efter den godkända ändringen, bekräfta DNS-uppslagningen och återanslut en gång. Registrera klienten, plattformen, gatewayens utgivning och tunnelläget tillsammans, eftersom nästa person behöver alla fyra. Ett program som öppnas framgångsrikt har klarat det lokala startsteget, och inget annat.