Ist das alte openfortivpn-.deb für Ihren Raspberry Pi geeignet?

Eine Forumsantwort liefert Ihnen einen vollständigen Dateinamen, und der Dateiname sieht wie die Lösung aus: ein .deb, ein Befehl, fertig. Was diese Zeichenkette tatsächlich kodiert, ist eine Paketversion, eine CPU-Architektur und die Distributionssuite, gegen die sie an dem Tag gebaut wurde, an dem jemand den Beitrag schrieb. Keines dieser drei Dinge beschreibt automatisch die Platine auf Ihrem Schreibtisch. Der alte Download ist eine Momentaufnahme der Situation einer Maschine, kein Installationsplan für Ihre.

Was der Dateiname stillschweigend festlegt

Lesen Sie einen Namen wie openfortivpn_1.17.0-1_armhf.deb von rechts nach links. Das Suffix ist die Architektur, für die das Binary kompiliert wurde, das mittlere Feld ist die Upstream- und Paketierungsrevision, und das implizite vierte Feld ist der Bibliothekssatz der Suite, in der es gebaut wurde.

Bei einer 64-Bit-Installation von Raspberry Pi OS ist die Systemarchitektur arm64, also lehnt dpkg -i ein armhf-Paket wegen einer Architekturabweichung ab. Selbst wo multiarch die Installation ermöglicht, erwartet das Binary Bibliotheksversionen aus der Version, gegen die es gebaut wurde, und ein neueres Basissystem stellt sie möglicherweise nicht mehr bereit. Das Ergebnis ist ein installiertes Paket, dessen ausführbare Datei sich nicht starten lässt, und das ist der Fehler, den Leute gewöhnlich fälschlich dem Client selbst zuschreiben.

Dass die Platine ein ARM-Gerät ist, macht ein ARM-Paket nicht passend. Architektur ist eine Achse; Release und ABI sind die anderen beiden, und sie scheitern unabhängig voneinander.

Fragen Sie die Distribution, bevor Sie nach einem Download-Link fragen

Jeder gepflegte Kanal kann Ihnen sagen, was er gerade jetzt installieren würde. Führen Sie die Abfrage auf der Zielmaschine aus, mit den Repositories, die sie tatsächlich nutzt, bevor Sie irgendeine Dateiübertragung erwägen.

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

Eine Kandidatenzeile mit einer Version und einem Repository-Namen bedeutet, dass die Distribution bereits einen Build für dieses System hat. Kein Kandidat oder ein Kandidat aus einer Suite, die Sie nicht verwenden wollten, ist eine Information über Ihre Quellen und nicht darüber, dass die Software irgendwo existiert.

Wenn das Aktualisieren der Metadaten fehlschlägt, halten Sie diesen Fehler vom Paketproblem getrennt. Namensauflösung, Repository-Transport, eine fehlende Release-Signatur und eine Suite am Ende ihres Lebenszyklus brechen alle apt update, bevor der Client überhaupt beteiligt ist. Quellen zu reparieren ist eine andere Aufgabe als einen VPN-Client auszuwählen, und beides zu vermischen ist der Weg, auf dem Leute ein aktuelles System auf eine veraltete Version zeigen lassen.

Was apt prüft und was eine heruntergeladene Datei nicht bekommt

Eine normale Installation folgt einer Signaturkette: Das Archiv signiert seinen Index, der Index trägt Hashes für jedes Paket, und das Paket muss dazu passen. Die Referenz zur Archivauthentifizierung trennt diese Kette von der Vorstellung, eine an jede einzelne Datei angehängte Signatur zu prüfen.

Eine aus einem alten HTTP-Link gespeicherte Datei hat davon nichts. Sie kommt ohne Repository-Identität an, wird nicht aktualisiert, wenn die Distribution den Client patcht, und nichts hält fest, wer für ihren Ersatz verantwortlich ist. Das kann für einen Administrator mit einem fixierten Artefakt noch eine legitime Wahl sein, aber die Wahl muss mit einem Eigentümer, einer irgendwo festgehaltenen Prüfsumme und einem Plan für das nächste Sicherheitsupdate einhergehen.

Signaturfehler zu unterdrücken oder die TLS-Prüfung abzuschalten, damit eine alte Anleitung weiter funktioniert, entfernt den einzigen Teil des Prozesses, der überhaupt etwas prüfte. Stellen Sie stattdessen die fehlschlagende Prüfung wieder her.

Installieren Sie den Client und debuggen Sie die Verbindung dann getrennt

Wenn ein gepflegter Kandidat existiert, installieren Sie ihn über die normale geprüfte Transaktion und lassen Sie den Paketmanager festhalten, was er getan hat.

Wenn das Deployment wirklich einen Upstream-Build braucht, folgen Sie den aktuellen Build-Anweisungen des Projekts und behandeln Sie ihn als Software, die Sie jetzt pflegen: Entwicklungspakete, pkg-config, die Header der TLS-Bibliothek und der PPP-Daemon sind echte Abhängigkeiten, und das gilt auch für das Entfernungsverfahren, das Sie später brauchen werden.

Die Installation ist nur die lokale Softwarestufe. Das Gateway muss Protokoll und Authentifizierungsablauf des Clients akzeptieren, der Client muss dem Zertifikat vertrauen, das das Gateway vorlegt, und der Tunnel braucht eine funktionierende PPP-Schicht plus Routen und einen Resolver-Eigentümer. Eine abgeschlossene Pakettransaktion beweist nichts darüber, ob das Gateway das Konto akzeptiert oder ob der private Bereich erreichbar ist. Testen Sie jede Schicht dort, wo sie bricht, statt den Installer erneut auszuführen.

Der Plan, der den alten Dateinamen ersetzen sollte

Schreiben Sie zuerst die Plattformidentität auf: Betriebssystemversion, Architektur und die verwendete Quellenliste. Benennen Sie dann den autorisierten Ort, von dem das Paket kommt — ob Distributions-Repository, Anbieter-Repository mit fixiertem Schlüssel oder ein Build, den Sie selbst kompilieren und paketieren.

Benennen Sie schließlich den Betreuer und den Update-Pfad. Ein Pi, der einen Client ohne Eigentümer ausführt, funktioniert weiter bis zum ersten Bibliotheks-Update, und dann wird jemand mit demselben Problem denselben Forenthread wiederfinden.

Die korrigierte Überzeugung ist einfach genug, um sie in einer Zeile zu sagen: Das alte Paket ist ein Beleg dafür, dass der Client einmal gebaut wurde und lief, kein Beleg dafür, dass es sich heute Abend auf Ihrer Platine installiert. Prüfen Sie die drei Achsen und wählen Sie dann einen Kanal, den Sie weiter aktualisieren können.