Pi-hole e VPN num só Pi: o sistema ainda é suportado?

Numa caixa combinada de Pi-hole e VPN confundem-se duas coisas: a família de distribuição instalada e a versão mais a arquitetura que os componentes realmente suportam. Uma placa que arranca uma imagem prova que o kernel corre; não prova que o binário FTL do Pi-hole e o seu instalador de VPN apontam para o mesmo espaço de utilizador. O teste real é uma sobreposição quádrupla de suporte da placa, ramo de versão, arquitetura de pacotes e um caminho de atualização que consiga conduzir sozinho. Perca qualquer uma destas quatro pernas e o aparelho funciona nesta semana, para depois o deixar pendurado na atualização de segurança seguinte.

O ramo de versão fixa o suporte, não o nome da família

Pergunte contra que versão o projeto ainda testa e escreva a resposta como uma cadeia de versão, não como Debian. A página de pré-requisitos do Pi-hole lista os sistemas operativos suportados e as arquiteturas FTL pré-compiladas como dois requisitos separados, limita o suporte às versões que a própria distribuição ainda mantém e avisa que variantes ou configurações invulgares podem falhar mesmo dentro da lista suportada. Esta formulação importa: uma família suportada não cobre todos os seus membros.

Uma imagem antiga que ainda arranca no seu Pi não é prova de suporte. A placa está bem, o índice de pacotes está desatualizado, e a incompatibilidade aparece mais tarde, quando um instalador puxa uma dependência que a versão já não consegue satisfazer.

O lado da VPN tem mais peças, cada uma com a sua janela: o daemon do túnel, o assistente de instalação que escreve a configuração, a aplicação cliente do fornecedor e o pacote de integração da distribuição são quatro projetos separados. Um instalador que reconhece a sua distribuição e um instalador que produz um serviço que a versão consegue manter a correr são afirmações diferentes. Consulte a lista de plataformas do próprio daemon e depois se o assistente que pretende executar foi mexido desde que essa versão saiu. Quando um projeto declara suporte apenas até uma versão nomeada, trate a seguinte como não testada até a ter arrancado você mesmo.

Faça corresponder o alvo binário ao espaço de utilizador que tem

A arquitetura é a falha mais silenciosa. Um kernel de 64 bits com um espaço de utilizador de 32 bits é uma combinação real e suportada em várias placas, e executa um binário FTL de 32 bits sem queixas, até ao momento em que instala algo publicado apenas para arm64. Imprima as duas metades antes de escolher uma imagem, e guarde a saída junto das suas notas.

uname -m
dpkg --print-architecture
grep -E '^(PRETTY_NAME|VERSION_ID)=' /etc/os-release
apt-cache policy pihole-ftl

Se essas duas linhas de arquitetura não coincidem, está numa configuração mista: viável para o Pi-hole sozinho, frágil assim que um segundo serviço quiser bibliotecas nativas. Voltar a gravar uma imagem limpa de 64 bits costuma ser mais rápido do que reconstruir a cadeia de ferramentas que produziu a incompatibilidade.

O marketing da placa também não resolve isto. O tamanho da memória e o modelo de CPU não dizem nada sobre contra que libc os seus pacotes ligam, por isso decida pelos valores impressos, nunca pela página do produto.

Uma caixa, dois serviços, um dono da rede

Decida quem possui o endereçamento, o resolvedor e o túnel antes de entrar o primeiro pacote, senão dois serviços acabam a reclamar o mesmo dever e nenhum ganha limpo. Dê ao Pi um endereço estático fora do conjunto DHCP que o seu router distribui, e mantenha o túnel na sua própria sub-rede: 192.168.50.10 para o Pi e 10.42.0.0/24 para o túnel é uma divisão viável, e os números em si são arbitrários desde que não colidam com o que o seu router já serve. Depois anote que componente responde na porta 53, qual distribui DHCP se o usar e qual possui a rota predefinida enquanto o túnel está ativo. Numa imagem sem ecrã, essa última tarefa pertence ao NetworkManager ou ao systemd-networkd, e instalar um cliente do fornecedor que também reescreve a configuração do resolvedor é como as pessoas acabam com um túnel vivo e DNS morto.

Partilhar a caixa está bem. Partilhar um papel não. O Pi-hole quer ser o único ouvinte na porta 53, e o daemon VPN quer empurrar a sua própria definição de DNS para os clientes, por isso escolha em qual dos dois os clientes devem confiar e configure o outro para ficar fora do caminho.

Mantenha o caminho de administração fora do túnel quando puder. Se o resolvedor e o túnel falharem juntos, ainda quer SSH acessível no endereço LAN, e isso significa que o serviço de gestão não pode depender de nenhum dos dois.

Faça da próxima atualização parte da escolha

Uma versão que não consegue atualizar é um teto de suporte que já aceitou. Teste a mecânica de atualização num cartão de reserva antes de o aparelho transportar o DNS da sua casa, e leia o que os projetos dizem sobre saltar entre ramos em vez de assumir que uma atualização de pacote basta.

sudo apt update
apt-mark showhold
sudo apt full-upgrade
pihole -up

Os pacotes retidos são a razão habitual para uma atualização parecer bem-sucedida e não mudar nada. Liberte as retenções de propósito, uma a uma, e anote que serviço precisava da fixação.

Antes do salto exporte a configuração do Pi-hole, as concessões estáticas e quaisquer perfis de túnel, e confirme que consegue restaurá-los numa imagem nova. Depois do salto teste o DNS normal dos clientes, o recurso privado atrás do túnel, uma reconexão e qualquer regra de encaminhamento no gateway. Uma caixa que arranca e responde a ping não passou quase nada.

Quando nenhuma versão isolada serve aos dois serviços

Por vezes a sobreposição está vazia: o assistente de VPN passou para uma versão mais recente do que o pacote Pi-hole que consegue instalar, ou a imagem do fabricante da placa fica atrás de ambas. Nesse caso separe os papéis em vez de editar metadados de versão para satisfazer um instalador. Dois aparelhos pequenos, ou um aparelho mais um contentor para o segundo serviço, custam menos do que um aparelho cuja história de suporte assenta numa mentira.

Falsificar a versão é o único atalho que deve recusar de imediato. Os gestores de pacotes acreditam no que o ficheiro de versão diz, por isso um identificador falsificado dá-lhe uma instalação que nenhum dos dois projetos ajudará a depurar.

Se duas versões atuais satisfazem tudo, escolha aquela cujas notas de atualização consegue seguir sem adivinhar, e pare de procurar. Depois registe a versão, a arquitetura, os donos dos serviços e o passo de restauro num só lugar, porque a próxima pessoa a mexer no cartão SD precisará dos quatro.