Is it âlde openfortivpn .deb geskikt foar jo Raspberry Pi?

In antwurd op in foarum jout jo in folsleine bestânsnamme, en de namme liket de oplossing: ien .deb, ien opdracht, dien. Wat dy tekenrige eins kodearret is in pakketferzje, in CPU-arsjitektuer en de distribúsjesuite dêr't it tsjin boud waard op 'e dei dat immen it berjocht skreau. Gjin fan dy trije beskriuwt automatysk it board op jo buro. De âlde download is in momintopname fan 'e situaasje fan ien masine, net in ynstallaasjeplan foar dy fan jo.

Wat de bestânsnamme stilwei fêstiget

Lês in namme lykas openfortivpn_1.17.0-1_armhf.deb fan rjochts nei lofts. De efterheaksel is de arsjitektuer dêr't it binêre bestân foar kompilearre is, it middelste fjild is de upstream- en ferpakkingsferzje, en it ymplisite fjirde fjild is de bibleteekset fan 'e suite dêr't it yn boud is.

Op in 64-bits Raspberry Pi OS-ynstallaasje is de systeemarsjitektuer arm64, dus wegeret dpkg -i in armhf-pakket fanwegen in arsjitektuerôfwiking. Sels dêr't multiarch it ynstallearjen mooglik makket, ferwachtet it binêre bestân bibleteekferzjes fan 'e ferzje dêr't it tsjin boud is, en in nijer basissysteem leveret se miskien net mear. It resultaat is in ynstallearre pakket wêrfan't it útfierbere bestân net starte kin, en dat is de flater dy't minsken meastentiids ferkeard begripe as de kliïnt sels stikken is.

Dat it board in ARM-apparaat is, makket in ARM-pakket net geskikt. Arsjitektuer is ien as; ferzje en ABI binne de oare twa, en se mislearje ûnôfhinklik.

Freegje de distribúsje foardat jo in downloadkeppeling freegje

Elk ûnderhâlden kanaal kin jo fertelle wat it op dit stuit ynstallearje soe. Fier de fraach út op 'e doelmasine, mei de repositories dy't it eins brûkt, foardat jo hokker bestânsoerdracht dan ek oerbliuwe.

cat /etc/os-release
dpkg --print-architecture
apt-cache policy openfortivpn

In kandidatline mei in ferzje en in repositorynamme betsjut dat de distribúsje al in bou hat foar dit systeem. Gjin kandidaat, of in kandidaat út in suite dy't jo net fan doel wiene te brûken, is ynformaasje oer jo boarnen, net oer it bestean fan 'e software earne.

As it fernijen fan metadata mislearret, hâld dy mislearring dan skieden fan 'e pakketfraach. Namme-oplossing, repository-transport, in ûntbrekkende Release-handtekening en in suite oan 'e ein fan syn libben brekke allegear apt update foardat de kliïnt belutsen is. It reparearjen fan boarnen is in oare taak as it kiezen fan in VPN-kliïnt, en it mingen fan dy twa is hoe't minsken in aktueel systeem nei in ferâldere ferzje wize litte.

Wat apt ferifiearret, en wat in downloadbestân net krijt

In normale ynstallaasje folget in hantekeningkeatling: it argyf ûndertekent syn yndeks, de yndeks draacht hashes foar elk pakket, en it pakket moat oerienkomme. referinsje foar argyfautentikaasje skiedt dy keatling fan it idee om in hantekening te kontrolearjen dy't oan elk yndividueel bestân taheakke is.

In bestân dat fan in âlde HTTP-keppeling bewarre is, hat dêr neat fan. It komt oan sûnder repository-identiteit, it wurdt net bywurke as de distribúsje de kliïnt patcht, en neat registrearret wa't ferantwurdlik is foar it ferfangen. Dat kin noch altyd in legitime kar wêze foar in behearder mei in fêstlein artefakt, mar de kar moat komme mei in eigner, in earne registrearre kontrôlesom en in plan foar de folgjende feiligensfernijing.

It ûnderdrukken fan hantekeningflaters of it útskeakeljen fan TLS-ferifikaasje om in âlde ynstruksje wurkje te litten, ferwideret it ienige part fan it proses dat wat kontrolearre. Werstel ynstee de kontrôle dy't mislearret.

Ynstallearje de kliïnt, debug dan de ferbining apart

As der in ûnderhâlden kandidaat bestiet, ynstallearje dy dan fia de normale beoardiele transaksje en lit de pakketbehearder fêstlizze wat it dien hat.

As de útrôljen echt in upstream-bou nedich hat, folgje dan de aktuele bouynstruksjes fan it projekt en behannelje it as software dy't jo no ûnderhâlde: ûntwikkelingspakketten, pkg-config, de headers fan 'e TLS-bibleteek en de PPP-daemon binne echte ôfhinklikheden, en dat is de ferwideringsproseduere dy't jo letter nedich hawwe ek.

Ynstallaasje is allinnich de lokale softwarestap. It gateway moat it protokol en de autentikaasjefloat fan 'e kliïnt akseptearje, de kliïnt moat it sertifikaat fertrouwe dat it gateway presintearret, en de tunnel hat in wurkjende PPP-laach nedich plus rûtes en in resolver-eigner. In foltôge pakkettransaksje bewiist neat oer oft it gateway it akkount akseptearret of oft it privee berik berikber is. Test elke laach dêr't it brekt ynstee fan 'e ynstallearder op 'e nij te draaien.

It plan dat it âlde bestânsnamme ferfange moat

Skriuw earst de identiteit fan it platfoarm op: OS-ferzje, arsjitektuer en de brûkte boarnelist. Nammje dan it autorisearre plak dêr't it pakket wei komt, oft dat in distribúsje-repository, in leveransiersrepository mei in fêstleine kaai of in bou is dy't jo sels kompilearje en pakkettearje.

Nammje ta beslút de ûnderhâlder en it fernijingspaad. In Pi dy't in kliïnt draait dy't nimmen besit, sil wurkje oant de earste bibleteekfernijing, en dan sil deselde foarumtried wer fûn wurde troch immen mei itselde probleem.

It korrizjearre leauwen is ienfâldich genôch om yn ien rigel te sizzen: it âlde pakket is bewiis dat de kliïnt ea boud waard en rûn, net bewiis dat it jûn op jo board ynstallearret. Kontrolearje de trije assen en kies dan in kanaal dat jo byhâlde kinne.