Fortinet Linux-kliento: kontrolu la kluzon antaŭ ol ripari

La arkivita gvidilo diras instali 32-bitajn bibliotekojn, fliki GTK-etoson kaj lanĉi la instalilon el terminalo. Parto de tiu konsilo estis ĝusta por aparta klienteldono, kaj nenio el ĝi povas revenigi tunelreĝimon, kiun la kluzo ne plu proponas. Antaŭ ol vi ŝanĝos pakon, trovu la unuan etapon, kiu malsukcesis. Ĉi tio iras de la kluzo internen, ĉar tie la respondoj estas malmultekostaj kaj malĝusta loka riparo kostas la plej multe da tempo.

Kontrolo 1: nomu la etapon, kiu malsukcesis

Tri etapoj malsukcesas malsame. La programo ne lanĉiĝas, ĝi lanĉiĝas kaj rifuzas la identecon de la servilo, aŭ ĝi konektiĝas kaj la kluzo ne havas servon de la speco, kiun vi bezonas. Ĉiu malsukceso lasas sian propran pruvon: lanĉilan eraron, atestilan mesaĝon, respondon de la kluzo, kiu nomas nehaveblan reĝimon.

Skribu tion antaŭ ol vi tuŝos ion ajn. Ĉio post ĉi tiu punkto dependas de tio, kiun etapon vi nomis, kaj la tri riparoj havas nenion komunan.

Kontrolo 2: la eldono de la kluzo kaj la tunelreĝimo

La tunelreĝimo malaperis en nunaj kluzoj, kaj la FortiClient 7.4.4-integriĝtabelo por Linux estas kie tio estas skribita: FortiOS 7.6.3 kaj postaj ne plu proponas la tunelreĝimon SSL VPN kaj direktas administrantojn al IPsec. Tenu la produkton, la eldonon kaj la reĝimon ligitaj al tiu frazo, kiam vi ripetas ĝin. Ĝi diras nenion pri ĉiu Fortinet-produkto kaj nenion pri retaliraj funkcioj, kiuj ankoraŭ ekzistas. Ĝenerala versia kongruo kaj la havebleco de unu tunelreĝimo estas apartaj kontroloj.

Demandu la posedanton de la kluzo du aferojn: kiun eldonon la kluzo funkciigas, kaj kiuj alirmetodoj estas ŝaltitaj hodiaŭ. Petu la respondon skribe, kun la eldonĉeno kaj la agorda paĝo aŭ konfigura linio, de kiu ĝi venis, ĉar parola certigo estas tio, kio resendas homojn al la arkivita gvidilo. Poste kontrolu tiun respondon kontraŭ la notoj de la kluzo aŭ la matrico de la vendanto por ĝuste tiu eldono. Retumilo, kiu montras la retportalon, pruvas, ke la portalo respondas, kaj nenion pli.

Kontrolo 3: la klienteldono, kiun la posedanto aprobas

Akiru la aprobitan Linux-klienteldonon kaj version, poste kontrolu la subtenatan operaciumon, arkitekturon, labortablon kaj aŭtentigfluon. La matrico 7.4.4 estas versie ligita ekzemplo, ne rekomendo por la plej nova kliento kaj ne promeso por ĉiu derivaĵo. Demandu, kiun klienton la posedanto efektive subtenos, ĉar tiu respondo estas parto de la migrado kaj ne postpenso. Kliento, kiu mortas antaŭ ol ĝia unua paketo atingas la kluzon, pruvas ion pri la tekkomputilo, ne pri la servo.

32-bitaj bibliotekoj kaj flikita etoso ŝanĝas, kion la binara dosiero povas ŝargi; ili ne ŝanĝas, kion la vendanto subtenas. Se la operaciumo aŭ la aŭtentigfluo staras ekster la matrico, la demando pri taŭgeco jam estas respondita.

Kontrolo 4: petu la anstataŭan profilon

Se la organizo transiris de SSL VPN-tunelreĝimo al IPsec, petu la novan profilon kaj la registran proceduron en la sama konversacio. Ne renomu SSL-agordon kaj supozu, ke la kampoj transiras: IPsec-profilo nomas IKE-version, malproksiman kluzon kaj ĝian identecon, aŭtentigmetodon kaj la trafikselektilojn, kiujn ĉiu flanko akceptas. Ankaŭ konta kaj aparata politiko povas esti aplikata alie. Renomado produktas klienton, kiu aspektas agordita kaj traktas nenion.

Legu la profilon antaŭ ol fidi ĝin. Ĝi devus deklari la IKE-version kaj proponojn, ĉu aŭtentigo uzas atestilon aŭ antaŭdivideitan ŝlosilon, kiuj lokalaj kaj malproksimaj subretoj estas elektitaj, kaj kion la kluzo atendas kiel sian identecon. Konfirmu, ke la aprobita Linux-kliento subtenas tiun aranĝon, ĉar migrada dokumento ne estas deklaro pri funkcia egaleco por ĉiu klienteldono. Sendependa kliento kiel openfortivpn ne estas OpenVPN-interpretilo, do traktu ion ajn alian kun SSL en sia nomo kiel neaprobitan ĝis la posedanto diras alie por ĉi tiu reĝimo, ĉi tiu ensalutfuo kaj ĉi tiu aparatpolitiko.

Kontrolo 5: lokaj dependecoj, poste validigu kaj registru

Kiam la kluzo kaj la kliento estas solvitaj, lanĉomalsukceso estas pakada problemo, kaj la propraj instrukcioj de la prizorgata pako estas la referenco sekvenda. TLS-identeca malsukceso apartenas al la operatoro: fido-ankroj kaj la atendata nomo estas ilia agordo, ne io por ĉirkaŭiri loke. Tiuj estas la du etapoj, en kiuj la arkivita gvidilo iam estis utila.

Neniu el ili solviĝas per akcepto de nekonata atestilo aŭ per malŝalto de sintena kontrolo. Konservu la kontrolojn de MFA kaj aparato, ĉar restarigi konektecon malfortigante ilin interŝanĝas paneon kontraŭ incidento. Se la reĝimo foriris, neniu loka flago revenigas ĝin.

Post la aprobita ŝanĝo, atingidu la celatan privatan rimedon, konfirmu DNS-dissolvon kaj rekonektiĝu unufoje. Registru la klienton, platformon, kluzeldonon kaj tunelreĝimon kune, ĉar la sekva persono bezonas ĉiujn kvar. Programo, kiu malfermiĝas sukcese, trapasis la lokan lanĉetapon, kaj nenion alian.