Er den gamle openfortivpn .deb rigtig til din Raspberry Pi?

Et svar på et forum giver dig et fuldstændigt filnavn, og filnavnet ser ud som løsningen: én .deb, én kommando, færdig. Det, strengen faktisk koder, er en pakkeversion, en CPU-arkitektur og den distributionssuite, den blev bygget mod den dag, nogen skrev indlægget. Ingen af de tre beskriver automatisk det board, der står på dit skrivebord. Den gamle download er et øjebliksbillede af én maskines situation, ikke en installationsplan for din.

Hvad filnavnet stille fastlåser

Læs et navn som openfortivpn_1.17.0-1_armhf.deb fra højre mod venstre. Suffikset er den arkitektur, binæren blev kompileret til, det midterste felt er upstream- og pakningsrevisionen, og det implicitte fjerde felt er det bibliotekssæt, den blev bygget i.

På en 64-bit Raspberry Pi OS-installation er systemarkitekturen arm64, så dpkg -i afviser en armhf-pakke på grund af arkitekturkonflikt. Selv hvor multiarch gør det muligt at installere, forventer binæren biblioteksversioner fra den udgivelse, den blev bygget mod, og et nyere basissystem giver dem måske ikke længere. Resultatet er en installeret pakke, hvis kørbar fil ikke kan starte, og det er den fejl, folk normalt fejltolker som selve klienten, der er ødelagt.

At boardet er en ARM-enhed gør ikke en ARM-pakke passende. Arkitektur er én akse; udgivelse og ABI er de to andre, og de fejler uafhængigt.

Spørg distributionen, før du spørger om et downloadlink

Enhver vedligeholdt kanal kan fortælle dig, hvad den ville installere lige nu. Kør forespørgslen på målmaskinen med de repositories, den faktisk bruger, før du overvejer nogen filoverførsel.

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

En kandidatlinje med en version og et repositorynavn betyder, at distributionen allerede har et build til dette system. Ingen kandidat, eller en kandidat fra en suite, du ikke havde til hensigt at bruge, er information om dine kilder snarere end om, at softwaren findes et sted.

Hvis opdateringen af metadata fejler, så hold den fejl adskilt fra pakkespørgsmålet. Navneopløsning, repository-transport, en manglende Release-signatur og en suite ved slutningen af sin levetid bryder alle apt update, før klienten er involveret. At rette kilder er en anden opgave end at vælge en VPN-klient, og at blande de to er, hvordan folk ender med at pege et aktuelt system mod en forældet udgivelse.

Hvad apt verificerer, og hvad en downloadet fil ikke får

En normal installation følger en signaturkæde: arkivet signerer sit indeks, indekset bærer hashes for hver pakke, og pakken skal matche. reference til arkivgodkendelse adskiller den kæde fra ideen om at kontrollere en signatur, der er knyttet til hver enkelt fil.

En fil gemt fra et gammelt HTTP-link har intet af det. Den ankommer uden repository-identitet, den opdateres ikke, når distributionen patcher klienten, og intet registrerer, hvem der er ansvarlig for at erstatte den. Det kan stadig være et legitimt valg for en administrator med et fastlåst artefakt, men valget skal komme med en ejer, en kontrolsum registreret et sted og en plan for den næste sikkerhedsopdatering.

At undertrykke signaturfejl eller slå TLS-verifikation fra for at holde en gammel instruktion kørende fjerner den eneste del af processen, der kontrollerede noget. Gendan i stedet den fejlende kontrol.

Installer klienten, og fejlfind derefter forbindelsen separat

Når der findes en vedligeholdt kandidat, skal du installere den via den normale gennemgåede transaktion og lade pakkehåndteringen registrere, hvad den gjorde.

Hvis udrulningen virkelig har brug for et upstream-build, følg projektets aktuelle build-instruktioner, og behandl det som software, du nu vedligeholder: udviklingspakker, pkg-config, TLS-bibliotekets headere og PPP-dæmonen er rigtige afhængigheder, og det er fjernelsesproceduren, du får brug for senere, også.

Installation er kun det lokale softwaretrin. Gatewayen skal acceptere klientens protokol og godkendelsesflow, klienten skal stole på det certifikat, gatewayen præsenterer, og tunnelen har brug for et fungerende PPP-lag plus ruter og en resolver-ejer. En gennemført pakketransaktion beviser intet om, hvorvidt gatewayen accepterer kontoen, eller om det private område kan nås. Test hvert lag, hvor det brækker, i stedet for at køre installatøren igen.

Planen, der bør erstatte det gamle filnavn

Skriv først platformens identitet ned: OS-udgivelse, arkitektur og den anvendte kildeliste. Navngiv derefter det autoriserede sted, pakken kommer fra — uanset om det er et distributionsrepository, et leverandørrepository med en fastlåst nøgle eller et build, du selv kompilerer og pakker.

Til sidst skal du navngive vedligeholderen og opdateringsvejen. En Pi, der kører en klient, som ingen ejer, vil fortsætte med at virke indtil den første biblioteksopdatering, og så vil den samme forumtråd blive fundet igen af nogen med det samme problem.

Den rettede overbevisning er enkel nok til at sige på én linje: den gamle pakke er bevis på, at klienten engang blev bygget og kørte, ikke bevis på, at den installerer på dit board i aften. Kontroller de tre akser, og vælg derefter en kanal, du kan blive ved med at opdatere.