ARM-konstruaĵo ne signifas FortiClient-subtenon por via Raspberry Pi

Ruli VPN-klienton sur Raspberry Pi ne samas al tio, ke FortiClient estas subtenata sur ĝi. Tri asertoj kunfandiĝas en ĉi tiu diskuto: la vendisto kvalifikas platformon, iu konstruas binaraĵon por la procesoro, kaj la pordego permesas la protokolon kaj registriĝon de tiu kliento. Trovi unu el la tri diras nenion pri la aliaj du. Trairu ilin en ĉi tiu ordo kaj haltu kiam unu malsukcesas, ĉar ĝuste tion vi devas solvi.

Unua paŝo: legu la vicon de eldonaj notoj por via preciza pako

Subtenaj deklaroj estas ligitaj al versio, do komencu per la eldonaj notoj por la pako, kiun aprobas via organizo. Por konkreta ekzemplo, la tabelo de FortiClient Standalone 7.4.7 listigas Ubuntu 22.04 kaj 24.04, Red Hat 9 kaj CentOS Stream 9 kun GNOME. Ĝia procesora postulo por Linux estas formulata kiel Intel aŭ ekvivalento.

Raspberry Pi OS ne estas unu el tiuj listigitaj Linux-medioj. Tio ne estas verdikto pri ĉiu FortiClient-eldono nek antaŭdiro pri postaj eldonoj; ĝi estas aserto pri tiu vico en tiu dokumento. Legu la matricon por la versio, kiun vi efektive intencas uzi.

Ne transportu procesorajn notojn el la vicoj Windows aŭ macOS en la vicon Linux. Vendistoj dokumentas platformojn laŭ eldono kaj laŭ versio, kaj noto valida por unu vico ne estas pruvo pri alia.

Dua paŝo: konfirmu, kion rulas la Pi

Tri komandoj fiksas la lokajn faktojn antaŭ ajna elŝuto:

uname -m
cat /etc/os-release
dpkg --print-architecture

La unua diras al vi la kernan arkitekturon, la dua la distribuon kaj eldonon, kaj la tria la uzantspacan arkitekturon por kiu pakoj estas konstruitaj. 64-bita kerno kun 32-bita uzantspaco estas ebla, kaj tio ŝanĝas kiun pakon vi bezonas.

Poste kontrolu, kio estas efektive disponebla por tiu platformo. La publikigita paktabelo de Debian trixie inkluzivas konstruaĵojn arm64 kaj armhf de openfortivpn. Tio pruvas arkitekturan disponeblecon en tiu distribuo. Ĝi ne pruvas, ke Fortinet kvalifikas FortiClient sur derivita distribuo, nek ke la pordego de via organizo akceptas la klienton.

Uzu subtenatajn pakojn kaj aktualan eldondokumentaron anstataŭ kaŝmemorigitan pakon el malnova eldono aŭ raporton pri malsukcesa konstruado el forumfadeno. Se ekzistas grafika fasado, kvalifiku ĝin aparte: funkcianta komandlinia konstruaĵo ne pruvas, ke la redaktilo, sekreta konservado kaj superrigardo de labortabla ujo estas prizorgataj.

Tria paŝo: kontrolu la pordegon antaŭ ol kulpigi la klienton

Upstream priskribas openfortivpn kiel PPP-kaj-TLS-klienton, kiu lanĉas pppd. Tio estas specifa efektivigo, kaj ĝi postulas, ke la pordego proponu kongruan reĝimon. Servila markonomo ne estas protokola interkonsento.

Kolektu la pordegan eldonon kaj la ebligitan alirmetodon, la aprobitan hostnomom kaj ĝian fidaĵon, kaj la identecan laborfluon, kiun la servo postulas, inkluzive ajnan duan faktoron kaj kontrolon de aparata sinteno. Administrata starigo povas postuli registrajn paŝojn, kiujn triaparta kliento havas neniun rimedon plenumi.

Provu la konekton per la konto, kiun oni donis al vi, ne per administranta, ĉar registriĝo kaj politiko kutime ligiĝas al la uzanto:

sudo openfortivpn vpn.example.com:443 -u <username>

Legu la malsukceson, ne nur la elirkodon. Atestila eraro, PPP-tempolimo kaj politika malakcepto estas tri malsamaj problemoj, kaj nur unu el ili temas pri ARM.

Kvara paŝo: akceptu ĝin sur la aparato, ene de la interkonsento

Akceptu la agordon per reala privata rimedo, DNS-resolvo tra la tunelo, kaj rekonekto post reta interrompo. Poste konfirmu, ke celo, kiu devus resti neatingebla, ankoraŭ malsukcesas, ĉar atingeblo sola ne pruvas, ke la politiko estas ĝusta.

Notu kvar faktojn kune: la operaciuman eldonon, la uzantspacan arkitekturon, la version de la klienta pako, kaj la pordegan reĝimon. Sen ĉiuj kvar, la sekva persono ne povas diri, ĉu la agordo estas subtenata aŭ nur funkcias.

Se la dunganto postulas administratan FortiClient-medion, kiun la Pi ne povas plenumi, petu aprobitan finpunkton aŭ aprobitan alirhoston. Ne malŝaltu samrangulan validigon, ne imitu sintenajn kontrolojn, kaj ne anstataŭigu la pordegon de la organizo por akomodi unu maŝinon. La konkludo skribenda estas, kiu subtenata kombinaĵo estas rajtigita, ne ke fermitkoda programaro neniam povas celi ARM.