Fortinet Linux client: suriin ang gateway bago mag-ayos
Ang naka-archive na gabay sa Linux ay nag-aayos ng mga library; hindi nito maibabalik ang tunnel mode na tinanggal ng gateway. Suriin ang hangganan ng release, ang client, pagkatapos ang lokal na yugto.
Sinasabi ng naka-archive na gabay na mag-install ng 32-bit na library, i-patch ang GTK theme at patakbuhin ang installer mula sa terminal. Ang bahagi ng payong iyon ay tama para sa isang partikular na release ng client, at wala sa mga ito ang makapagbabalik ng tunnel mode na hindi na inaalok ng gateway. Bago mo baguhin ang isang pakete, hanapin ang unang yugtong nabigo. Ito ay mula sa gateway papasok, dahil doon mura ang mga sagot at ang maling lokal na pag-aayos ang pinakamatagal.
Pagsusuri 1: pangalanan ang yugtong nabigo
Tatlong yugto ang nabibigo sa magkaibang paraan. Hindi bumubukas ang programa, bumubukas ito at tinatanggihan ang pagkakakilanlan ng server, o kumokonekta ito at walang serbisyo ang gateway na uri ng kailangan mo. Bawat kabiguan ay nag-iiwan ng sariling ebidensya: error ng loader, mensahe tungkol sa certificate, o tugon ng gateway na nagbanggit ng hindi available na mode.
Isulat ito bago mo hawakan ang anuman. Lahat ng sumusunod ay nakadepende sa kung aling yugto ang pinangalanan mo, at ang tatlong pag-aayos ay walang pagkakatulad.
Pagsusuri 2: ang release ng gateway at ang tunnel mode
Wala na ang tunnel mode sa mga kasalukuyang gateway, at ang talahanayan ng integrasyon ng FortiClient 7.4.4 para sa Linux ang lugar kung saan nakasulat iyon: hindi na nag-aalok ang FortiOS 7.6.3 at mas bago ng tunnel mode na SSL VPN at itinuturo ang mga administrator sa IPsec. Panatilihing nakakabit ang produkto, release at mode sa pangungusap na iyon kapag inuulit mo ito. Wala itong sinasabi tungkol sa bawat produktong Fortinet, at wala ring sinasabi tungkol sa mga feature ng web access na umiiral pa. Ang pangkalahatang compatibility ng bersyon at ang pagkakaroon ng isang tunnel mode ay magkaibang pagsusuri.
Tanungin ang may-ari ng gateway ng dalawang bagay: anong release ang pinapatakbo ng gateway, at aling mga paraan ng access ang naka-enable ngayon. Hilingin ang sagot sa sulat, kasama ang string ng release at ang pahina ng settings o linya ng configuration na pinagmulan nito, dahil ang pasalitang katiyakan ang nagpapabalik sa mga tao sa naka-archive na gabay. Pagkatapos, suriin ang sagot na iyon laban sa mga tala ng gateway o sa matrix ng vendor para sa eksaktong release na iyon. Ang browser na nagpapakita ng web portal ay nagpapatunay na tumutugon ang portal, at wala nang iba.
Pagsusuri 3: ang edisyon ng client na inaprubahan ng may-ari
Kunin ang aprubadong edisyon at bersyon ng Linux client, pagkatapos suriin ang sinusuportahang operating system, arkitektura, desktop at daloy ng authentication. Ang matrix 7.4.4 ay halimbawang nakatali sa bersyon, hindi rekomendasyon para sa pinakabagong client at hindi pangako para sa bawat deribatibo. Itanong kung aling client ang talagang susuportahan ng may-ari, dahil ang sagot na iyon ay bahagi ng migration at hindi isang naisipan lamang. Ang client na namamatay bago pa makarating ang unang pakete nito sa gateway ay nagpapatunay ng isang bagay tungkol sa laptop, hindi tungkol sa serbisyo.
Binabago ng 32-bit na library at na-patch na theme ang kayang i-load ng binary; hindi binabago nito ang sinusuportahan ng vendor. Kung ang operating system o ang daloy ng authentication ay nasa labas ng matrix, nasagot na ang tanong ng kwalipikasyon.
Pagsusuri 4: humingi ng kapalit na profile
Kung lumipat ang organisasyon mula sa tunnel mode ng SSL VPN patungong IPsec, humingi ng bagong profile at pamamaraan ng enrollment sa parehong usapan. Huwag palitan ang pangalan ng isang configuration ng SSL at ipalagay na lilipat ang mga field: ang profile ng IPsec ay nagbanggit ng bersyon ng IKE, isang remote gateway at ang pagkakakilanlan nito, isang paraan ng authentication, at ang mga tagapili ng trapiko na tinatanggap ng bawat panig. Maaari ring iba ang pagpapatupad ng patakaran sa account at device. Ang pagpapalit ng pangalan ay gumagawa ng client na mukhang naka-configure at walang naipagkasundo.
Basahin ang profile bago mo ito pagkatiwalaan. Dapat nitong banggitin ang bersyon ng IKE at ang mga panukala, kung gumagamit ang authentication ng certificate o pre-shared key, aling lokal at remote na subnet ang pinili, at ano ang inaasahan ng gateway bilang pagkakakilanlan nito. Kumpirmahin na sinusuportahan ng aprubadong Linux client ang ayos na iyon, dahil ang dokumento ng migration ay hindi pahayag ng pagkakapantay ng feature para sa bawat release ng client. Ang malayang client tulad ng openfortivpn ay hindi tagapagsalin ng OpenVPN, kaya ituring na hindi aprubado ang anumang bagay na may SSL sa pangalan hanggang sabihin ng may-ari ang iba para sa mode na ito, sa daloy ng login na ito at sa patakaran ng device na ito.
Pagsusuri 5: lokal na dependency, pagkatapos i-validate at itala
Kapag malinaw na ang gateway at client, ang kabiguan sa pagbubukas ay problema sa packaging, at ang sariling tagubilin ng inaalagaang pakete ang sangguniang dapat sundin. Ang kabiguan ng pagkakakilanlan ng TLS ay pag-aari ng operator: ang mga anchor ng tiwala at ang inaasahang pangalan ay configuration niya, hindi isang bagay na ilalampas sa lokal. Iyon ang dalawang yugto kung saan naging kapaki-pakinabang ang naka-archive na gabay.
Wala sa dalawa ang nalulutas sa pagtanggap ng hindi kilalang certificate o sa pagpatay ng pagsusuri ng posture. Panatilihin ang mga pagsusuri ng MFA at device, dahil ang pagbabalik ng koneksyon sa pamamagitan ng pagpapahina sa mga ito ay nagpapalit ng pagtigil para sa isang insidente. Kung wala na ang mode, walang lokal na flag ang makapagbabalik nito.
Pagkatapos ng aprubadong pagbabago, maabot ang nilalayong pribadong resource, kumpirmahin ang resolusyon ng DNS at kumonekta muli nang isang beses. Itala nang sabay ang client, platform, release ng gateway at tunnel mode, dahil kailangan ng susunod na tao ang apat. Ang programang matagumpay na bumukas ay nakapasa sa lokal na yugto ng pagbubukas, at wala nang iba.