Pacotes de VPN offline: pergunte ao sistema de destino o que ele precisa

Precisa do cliente VPN para chegar à rede que normalmente fornece os seus pacotes, e isso é um belo círculo vicioso. Descarregar um único DEB do OpenVPN noutra máquina costuma terminar numa segunda dependência em falta, depois numa terceira, e depois numa noite inteira a correr atrás de versões de bibliotecas. A alternativa é deixar a máquina desconectada dizer, nos seus próprios termos, do que precisa o seu gestor de pacotes. Tudo o que se segue resulta dessa inversão de quem pergunta.

Nos sistemas da família Debian essa conversa acontece através do apt-offline, um fluxo de pedido e retorno. O seu próprio runtime tem de estar presente primeiro no destino, instalado a partir de suporte aprovado ou de outro bootstrap gerido pelo administrador, porque nenhuma ferramenta consegue arrancar a partir do nada.

Comece pelo estado de pacotes do destino, não pelo do auxiliar

Registe a versão da distribuição, a arquitetura do espaço de utilizador e as fontes de pacotes configuradas do destino antes de qualquer outra coisa. Esses três factos decidem que implementação de VPN e que integração com o ambiente de trabalho são adequadas, e são factos que um auxiliar ligado não consegue fornecer.

O auxiliar descarrega ficheiros; não passa a ser a base das dependências. Um portátil mais recente que já tenha o OpenVPN instalado tem um estado de pacotes completamente diferente do destino, por isso o seu sucesso não prova nada sobre o que o destino pode aceitar.

Decida também o que quer realmente. O motor VPN, um plugin de serviço do NetworkManager e um editor gráfico são pacotes separados, e a escolha correta depende da versão e de como o utilizador vai gerir a ligação. Um servidor sem interface precisa do motor e de um ficheiro de configuração; um ambiente de trabalho precisa do plugin que deixa as suas definições de rede serem donas do túnel. Pedir o conjunto errado produz uma instalação que tem sucesso e uma ligação que ninguém consegue iniciar.

Duas viagens de ida e volta, por esta ordem

O manual separa três operações: gerar um pedido no sistema desconectado, descarregar num auxiliar ligado e importar de volta no destino. Atualize os metadados do repositório do destino antes de pedir pacotes, porque o pedido de pacotes é construído a partir desses metadados e índices desatualizados produzem pedidos que o auxiliar não consegue satisfazer.

No destino, um comando de administrador na forma apt-offline set vpn-meta.sig --update escreve o pedido de atualização. Leve esse ficheiro para a máquina ligada e descarregue um pacote agregado com apt-offline get vpn-meta.sig --bundle vpn-meta.zip. Traga o pacote agregado de volta e importe-o no destino com apt-offline install vpn-meta.zip, novamente como administrador.

Agora gere o pedido de pacotes a partir dos metadados atualizados, por exemplo apt-offline set vpn-deps.sig --install-packages openvpn, e repita a viagem com um novo nome de pacote agregado. Mantenha cada pedido emparelhado com o pacote agregado que produziu; um pacote gerado contra metadados antigos não é o mesmo pedido, mesmo quando os nomes dos ficheiros parecem intercambiáveis.

Adicione os pacotes de integração apenas quando o desenho precisar deles

Se o ambiente de trabalho deve gerir o túnel através das suas definições de rede, o pedido precisa do plugin correspondente além do motor. Inclua os nomes específicos de pacotes que a sua versão fornece em vez de uma lista lembrada de outra distribuição, e gere um novo pedido sempre que a lista mudar. Fixar versões também merece reflexão: um pacote criado para uma versão mais recente pode satisfazer o nome e ainda assim falhar em execução. É aqui que um conjunto fixo de quatro pacotes se torna um problema, porque a lista correta é uma propriedade do destino e só o destino a consegue calcular.

É também aqui que um conjunto fixo de quatro pacotes se torna um problema. A lista correta é uma propriedade do destino, e o destino é a única máquina que a consegue calcular corretamente.

Importar um pacote agregado não é instalar a VPN

Apesar do nome, a operação de instalação deposita dados APT no ambiente de gestão de pacotes. Não realiza a transação de pacotes. Conclua e reveja a instalação APT real do destino a partir dos dados fornecidos localmente, e leia a saída em vez de assumir que o sucesso do ZIP significa que o software está presente.

Se essa transação ainda pedir ficheiros indisponíveis, guarde a dependência em falta ou o erro de repositório específico e gere o pedido seguinte a partir dele. Não substitua um DEB de uma versão diferente e não desative as verificações de checksum ou de autenticação do repositório para o forçar. O manual avisa explicitamente contra saltar a verificação dos ficheiros descarregados, e com razão: um pacote não verificado é um resultado pior do que uma instalação falhada.

Os pacotes são apenas a primeira metade

Instalar software é separado de obter o endpoint, o perfil, o material de confiança e as credenciais aprovados, cada um dos quais pode ter a sua própria entrega controlada. Um conjunto de pacotes funcional sem um perfil válido não se liga a nada.

Depois mantenha vivo o caminho de transferência offline para atualizações futuras. Tratar a primeira ligação bem-sucedida como o fim da manutenção significa que a próxima atualização de segurança espera até alguém com um carro poder aparecer, e é assim que uma rede offline fica silenciosamente anos atrasada.