Är den gamla openfortivpn .deb-filen rätt för din Raspberry Pi?

Ett svar på ett forum ger dig ett fullständigt filnamn, och namnet ser ut som lösningen: en .deb, ett kommando, klart. Det strängen faktiskt kodar är en paketversion, en CPU-arkitektur och den distributionssuite som den byggdes mot den dag någon skrev inlägget. Ingen av de tre beskriver automatiskt kortet på ditt skrivbord. Den gamla nedladdningen är en ögonblicksbild av situationen för en maskin, inte en installationsplan för din.

Vad filnamnet tyst låser fast

Läs ett namn som openfortivpn_1.17.0-1_armhf.deb från höger till vänster. Ändelsen är den arkitektur som binären kompilerades för, mittfältet är upstream- och paketeringsrevisionen, och det implicita fjärde fältet är biblioteksuppsättningen för den suite den byggdes i.

På en 64-bitars Raspberry Pi OS-installation är systemarkitekturen arm64, så dpkg -i avvisar ett armhf-paket på grund av arkitekturkonflikt. Även där multiarch gör installationen möjlig förväntar sig binären biblioteksversioner från den utgåva den byggdes mot, och ett nyare bassystem kanske inte längre tillhandahåller dem. Resultatet är ett installerat paket vars körbara fil inte startar, och det är felet som folk vanligtvis feltolkar som att själva klienten är trasig.

Att kortet är en ARM-enhet gör inte ett ARM-paket lämpligt. Arkitektur är en axel; utgåva och ABI är de andra två, och de misslyckas oberoende.

Fråga distributionen innan du frågar efter en nedladdningslänk

Varje underhållen kanal kan berätta vad den skulle installera just nu. Kör frågan på målmaskinen, med de förråd den faktiskt använder, innan du överväger någon filöverföring.

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

En kandidatrad med en version och ett förrådsnamn betyder att distributionen redan har en byggnad för detta system. Ingen kandidat, eller en kandidat från en suite du inte tänkte använda, är information om dina källor, inte om huruvida programvaran finns någonstans.

Om uppdateringen av metadata misslyckas, håll det felet åtskilt från paketfrågan. Namnuppslagning, förrådstransport, en saknad Release-signatur och en suite vid slutet av sin livstid bryter alla apt update innan klienten ens är inblandad. Att reparera källor är en annan uppgift än att välja en VPN-klient, och att blanda de två är hur folk hamnar i att peka ett aktuellt system mot en föråldrad utgåva.

Vad apt verifierar, och vad en nedladdad fil inte får

En normal installation följer en signaturkedja: arkivet signerar sitt index, indexet bär hashar för varje paket, och paketet måste stämma. referens för arkivautentisering skiljer den kedjan från idén att kontrollera en signatur som är kopplad till varje enskild fil.

En fil som sparats från en gammal HTTP-länk har inget av detta. Den anländer utan förrådsidentitet, den uppdateras inte när distributionen patchar klienten, och ingenting registrerar vem som ansvarar för att ersätta den. Det kan fortfarande vara ett legitimt val för en administratör med en fastnålad artefakt, men valet måste komma med en ägare, en någonstans registrerad kontrollsumma och en plan för nästa säkerhetsuppdatering.

Att undertrycka signaturfel eller stänga av TLS-verifiering för att hålla en gammal instruktion igång tar bort den enda delen av processen som kontrollerade något. Återställ i stället kontrollen som misslyckas.

Installera klienten och felsök sedan anslutningen separat

När det finns en underhållen kandidat installerar du den genom den vanliga granskade transaktionen och låter pakethanteraren registrera vad den gjorde.

Om driftsättningen verkligen behöver en byggnad från upstream följer du projektets aktuella bygginstruktioner och behandlar den som programvara du nu underhåller: utvecklingspaket, pkg-config, TLS-bibliotekets huvuden och PPP-demonen är verkliga beroenden, och det är borttagningsproceduren du behöver senare också.

Installation är bara det lokala programvarusteget. Gatewayen måste acceptera klientens protokoll och autentiseringsflöde, klienten måste lita på certifikatet som gatewayen presenterar, och tunneln behöver ett fungerande PPP-lager plus rutter och en resolver-ägare. En slutförd pakettransaktion bevisar ingenting om huruvida gatewayen accepterar kontot eller om det privata området är nåbart. Testa varje lager där det bryts i stället för att köra installationsprogrammet igen.

Planen som borde ersätta det gamla filnamnet

Skriv först ner plattformens identitet: OS-utgåva, arkitektur och den använda källistan. Namnge sedan den auktoriserade platsen som paketet kommer från, vare sig det är ett distributionsförråd, ett leverantörsförråd med en fastnålad nyckel eller en byggnad du kompilerar och paketerar själv.

Namnge slutligen underhållaren och uppdateringsvägen. En Pi som kör en klient som ingen äger fortsätter att fungera till den första biblioteksuppdateringen, och då kommer någon med samma problem att hitta samma forumtråd igen.

Den korrigerade uppfattningen är enkel nog att sägas på en rad: det gamla paketet är bevis för att klienten en gång byggdes och kördes, inte bevis för att det installeras på ditt kort i kväll. Kontrollera de tre axlarna och välj sedan en kanal du kan fortsätta uppdatera.