Fortinet Linux klientas: prieš taisydami patikrinkite šliuzą
Archyvuotas Linux vadovas taiso bibliotekas; jis negali grąžinti tunelio režimo, kurio šliuzas atsisakė. Patikrinkite leidimo ribą, klientą, tada vietinį etapą.
Archyvuotas vadovas liepia įdiegti 32 bitų bibliotekas, pataisyti GTK temą ir paleisti diegimo programą iš terminalo. Dalis to patarimo buvo teisinga konkrečiam kliento leidimui, ir niekas iš to negrąžins tunelio režimo, kurio šliuzas nebeteikia. Prieš keisdami paketą, raskite pirmą etapą, kuris nepavyko. Tai eina nuo šliuzo į vidų, nes ten atsakymai pigūs, o neteisingas vietinis pataisymas kainuoja daugiausia laiko.
Patikra 1: įvardykite etapą, kuris nepavyko
Trys etapai nepavyksta skirtingai. Programa nepasileidžia, pasileidžia ir atmeta serverio tapatybę, arba prisijungia, o šliuzas neturi reikiamo tipo paslaugos. Kiekviena nesėkmė palieka savo įrodymą: įkėlėjo klaidą, sertifikato pranešimą, šliuzo atsakymą, kuriame nurodomas nepasiekiamas režimas.
Užsirašykite tai prieš ką nors liesdami. Viskas po šio taško priklauso nuo to, kurį etapą įvardijote, o trys pataisymai neturi nieko bendra.
Patikra 2: šliuzo leidimas ir tunelio režimas
Tunelio režimo dabartiniuose šliuzuose nebėra, ir FortiClient 7.4.4 Linux integracijos lentelė yra vieta, kur tai parašyta: FortiOS 7.6.3 ir naujesnės versijos nebeteikia SSL VPN tunelio režimo ir nukreipia administratorius į IPsec. Kai kartojate tą sakinį, laikykite produktą, leidimą ir režimą su juo susietus. Jis nieko nesako apie kiekvieną Fortinet produktą ir nieko apie web prieigos funkcijas, kurios dar egzistuoja. Bendra versijų suderinamumas ir vieno tunelio režimo prieinamumas yra atskiros patikros.
Paklauskite šliuzo savininko dviejų dalykų: kokį leidimą šliuzas naudoja ir kokie prieigos metodai šiandien įjungti. Paprašykite atsakymo raštu, su leidimo eilute ir nustatymų puslapiu ar konfigūracijos eilute, iš kurios jis gautas, nes būtent žodinis patikinimas nukreipia žmones atgal į archyvuotą vadovą. Tada patikrinkite tą atsakymą pagal šliuzo pastabas arba tiekėjo matricą tiksliai tam leidimui. Naršyklė, rodanti web portalą, įrodo, kad portalas atsako, ir nieko daugiau.
Patikra 3: kliento leidimas, kurį savininkas patvirtina
Gaukite patvirtintą Linux kliento leidimą ir versiją, tada patikrinkite palaikomą operacinę sistemą, architektūrą, darbalaukį ir autentifikavimo eigą. 7.4.4 matrica yra su versija susietas pavyzdys, ne rekomendacija naujausiam klientui ir ne pažadas kiekvienam dariniui. Paklauskite, kurį klientą savininkas iš tikrųjų palaikys, nes tas atsakymas yra migracijos dalis, o ne vėlesnė mintis. Klientas, kuris miršta prieš jo pirmam paketui pasiekiant šliuzą, įrodo kažką apie nešiojamąjį kompiuterį, o ne apie paslaugą.
32 bitų bibliotekos ir pataisyta tema keičia, ką gali įkelti dvejetainis failas; jos nekeičia, ką palaiko tiekėjas. Jei operacinė sistema ar autentifikavimo eiga yra už matricos ribų, kvalifikacijos klausimas jau atsakytas.
Patikra 4: paprašykite pakaitinio profilio
Jei organizacija perėjo nuo SSL VPN tunelio režimo prie IPsec, paprašykite naujo profilio ir registracijos procedūros tame pačiame pokalbyje. Nepervadinkite SSL konfigūracijos ir nemanote, kad laukai persikels: IPsec profilis nurodo IKE versiją, nuotolinį šliuzą ir jo tapatybę, autentifikavimo metodą ir srauto selektorius, kuriuos priima kiekviena pusė. Paskyros ir įrenginio politika taip pat gali būti taikoma kitaip. Pervadinimas sukuria klientą, kuris atrodo sukonfigūruotas ir nieko nesidera.
Perskaitykite profilį prieš juo pasitikėdami. Jame turi būti nurodyta IKE versija ir pasiūlymai, ar autentifikavimas naudoja sertifikatą, ar iš anksto bendrinamą raktą, kurie vietiniai ir nuotoliniai potinkliai pasirinkti ir ko šliuzas tikisi kaip savo tapatybės. Patvirtinkite, kad patvirtintas Linux klientas palaiko tokią tvarką, nes migracijos dokumentas nėra funkcijų lygybės pareiškimas kiekvienam kliento leidimui. Nepriklausomas klientas, pavyzdžiui, openfortivpn, nėra OpenVPN interpretatorius, todėl viską kitą su SSL pavadinime laikykite nepatvirtintu, kol savininkas nepasakys kitaip šiam režimui, šiai prisijungimo eigai ir šiai įrenginio politikai.
Patikra 5: vietinės priklausomybės, tada patikrinkite ir užrašykite
Kai šliuzas ir klientas išsiaiškinti, paleidimo nesėkmė yra pakavimo problema, o prižiūrimo paketo pačios instrukcijos yra nuoroda, kuria reikia vadovautis. TLS tapatybės nesėkmė priklauso operatoriui: pasitikėjimo inkarai ir laukiamas pavadinimas yra jo konfigūracija, o ne kažkas, ką apeiti vietiškai. Tai du etapai, kuriuose archyvuotas vadovas kada nors buvo naudingas.
Nė vieno neišsprendžia nežinomo sertifikato priėmimas ar būsenos patikros išjungimas. Laikykite MFA ir įrenginio patikras vietoje, nes ryšio atkūrimas jas susilpninus maino sutrikimą į incidentą. Jei režimas dingo, jokia vietinė vėliavėlė jo negrąžins.
Po patvirtinto pakeitimo pasiekite numatytą privatų išteklių, patvirtinkite DNS sprendimą ir kartą prisijunkite iš naujo. Užrašykite klientą, platformą, šliuzo leidimą ir tunelio režimą kartu, nes kitam žmogui reikia visų keturių. Programa, kuri sėkmingai atsiveria, praėjo vietinį paleidimo etapą, ir nieko daugiau.