Serve o vello .deb de openfortivpn para o seu Raspberry Pi?

Unha resposta nun foro dálle un nome de ficheiro completo, e o nome parece a solución: un .deb, unha orde, feito. O que esa cadea codifica en realidade é unha versión de paquete, unha arquitectura de CPU e a suite da distribución contra a que se compilou o día en que alguén escribiu a mensaxe. Ningún deses tres describe automaticamente a placa que ten sobre a mesa. A descarga antiga é unha instantánea da situación dunha máquina, non un plan de instalación para a súa.

O que o nome do ficheiro fixa en silencio

Lea un nome como openfortivpn_1.17.0-1_armhf.deb de dereita a esquerda. O sufixo é a arquitectura para a que se compilou o binario, o campo central é a revisión de upstream e de empaquetado, e o cuarto campo implícito é o conxunto de bibliotecas da suite na que se compilou.

Nunha instalación de 64 bits de Raspberry Pi OS a arquitectura do sistema é arm64, así que dpkg -i rexeita un paquete armhf por un desaxuste de arquitectura. Mesmo cando multiarch permite a instalación, o binario espera versións de biblioteca da versión contra a que se compilou, e un sistema base máis novo pode que xa non as proporcione. O resultado é un paquete instalado cuxo executable non arrinca, e ese é o fallo que a xente adoita interpretar mal como se o cliente mesmo estivese roto.

Que a placa sexa un dispositivo ARM non fai apropiado un paquete ARM. A arquitectura é un eixe; a versión e a ABI son os outros dous, e fallan de forma independente.

Pregunte á distribución antes de pedir unha ligazón de descarga

Cada canle mantida pode dicirlle que instalaría agora mesmo. Execute a consulta na máquina de destino, cos repositorios que realmente utiliza, antes de considerar calquera transferencia de ficheiros.

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

Unha liña de candidato cunha versión e un nome de repositorio significa que a distribución xa ten unha compilación para este sistema. Que non haxa candidato, ou que o candidato veña dunha suite que non pensaba usar, é información sobre as súas fontes, non sobre se o software existe nalgún sitio.

Se falla a actualización de metadatos, manteña ese fallo separado da cuestión do paquete. A resolución de nomes, o transporte do repositorio, unha sinatura Release ausente e unha suite ao final da súa vida útil rompen apt update antes de que o cliente interveña. Arranxar as fontes é unha tarefa distinta de escoller un cliente VPN, e mesturar as dúas é como a xente acaba apuntando un sistema actual a unha versión obsoleta.

Que verifica apt e que non obtén un ficheiro descargado

Unha instalación normal segue unha cadea de sinaturas: o arquivo asina o seu índice, o índice leva os hashes de cada paquete, e o paquete debe coincidir. referencia de autenticación do arquivo separa esa cadea da idea de comprobar unha sinatura anexa a cada ficheiro individual.

Un ficheiro gardado desde unha ligazón HTTP antiga non ten nada diso. Chega sen identidade de repositorio, non se actualiza cando a distribución parchea o cliente, e nada rexistra quen é responsable de substituílo. Iso aínda pode ser unha opción lexítima para un administrador cun artefacto fixado, pero a opción ten que vir cun propietario, unha suma de comprobación rexistrada nalgún sitio e un plan para a próxima actualización de seguridade.

Suprimir erros de sinatura ou desactivar a verificación TLS para que unha instrución antiga siga funcionando elimina a única parte do proceso que comprobaba algo. Restaure mellor a comprobación que falla.

Instale o cliente e logo depure a conexión por separado

Cando exista un candidato mantido, instáleo mediante a transacción revisada normal e deixe que o xestor de paquetes rexistre o que fixo.

Se o despregamento necesita de verdade unha compilación de upstream, siga as instrucións de compilación actuais do proxecto e trátea como software que agora mantén: os paquetes de desenvolvemento, pkg-config, as cabeceiras da biblioteca TLS e o daemon PPP son dependencias reais, e tamén o é o procedemento de desinstalación que quererá máis adiante.

A instalación é só a etapa local do software. A pasarela ten que aceptar o protocolo e o fluxo de autenticación do cliente, o cliente ten que confiar no certificado que presenta a pasarela, e o túnel necesita unha capa PPP funcional máis rutas e un propietario do resolutor. Unha transacción de paquete completada non demostra nada sobre se a pasarela acepta a conta ou se o rango privado é alcanzable. Proba cada capa onde se rompe en lugar de volver executar o instalador.

O plan que debería substituír o nome de ficheiro antigo

Escriba primeiro a identidade da plataforma: versión do sistema, arquitectura e a lista de fontes en uso. Despois nomee o lugar autorizado do que procede o paquete, xa sexa un repositorio de distribución, un repositorio de provedor cunha chave fixada ou unha compilación que vostede mesmo compila e empaqueta.

Por último, nomee o mantedor e a ruta de actualización. Un Pi que executa un cliente que ninguén posúe seguirá funcionando ata a primeira actualización de biblioteca, e entón alguén co mesmo problema volverá atopar o mesmo fío do foro.

A crenza corrixida é o bastante simple para dicila nunha liña: o paquete antigo é evidencia de que o cliente algunha vez se compilou e funcionou, non evidencia de que se vaia instalar na súa placa esta noite. Comprobe os tres eixes e despois escolla unha canle que poida seguir actualizando.