Nunha caixa combinada de Pi-hole e VPN mestúranse dúas cousas: a familia de distribución que instalou e a versión máis a arquitectura que os compoñentes admiten realmente. Unha placa que arranca unha imaxe demostra que o núcleo funciona; non demostra que o binario FTL de Pi-hole e o seu instalador de VPN apunten ao mesmo espazo de usuario. A proba real é unha superposición cuádrupla de soporte de placa, rama de versión, arquitectura de paquetes e unha ruta de actualización que vostede mesmo poida dirixir. Perda calquera desas catro patas e o aparello funciona esta semana, para deixalo tirado na seguinte actualización de seguridade.

A rama de versión fixa o soporte, non o nome da familia

Pregunte contra que versión segue probando o proxecto e escriba a resposta como unha cadea de versión, non como Debian. A páxina de requisitos de Pi-hole enumera os sistemas operativos admitidos e as arquitecturas FTL precompiladas como dous requisitos separados, limita o soporte ás versións que a propia distribución aínda mantén e advirte de que as variantes ou configuracións pouco habituais poden fallar mesmo dentro da lista admitida. Ese fraseo importa: unha familia admitida non cobre todos os seus membros.

Unha imaxe antiga que aínda arranca no seu Pi non é proba de soporte. A placa está ben, o índice de paquetes está obsoleto, e a discrepancia aparece máis tarde, cando un instalador arrastra unha dependencia que a versión xa non pode satisfacer.

O lado da VPN ten máis pezas, cada unha coa súa propia xanela: o daemon do túnel, o asistente de instalación que escribe a súa configuración, a aplicación cliente do provedor e o paquete de integración da distribución son catro proxectos separados. Un instalador que recoñece a súa distribución e un instalador que produce un servizo que a versión pode manter en marcha son afirmacións distintas. Consulte a lista de plataformas propia do daemon e logo se o asistente que pensa executar foi tocado desde que saíu esa versión. Cando un proxecto declara soporte só ata unha versión nomeada, trate a seguinte como non probada ata que a arrancase vostede.

Faga coincidir o obxectivo binario co espazo de usuario que ten

A arquitectura é o fallo máis silencioso. Un núcleo de 64 bits cun espazo de usuario de 32 bits é unha combinación real e admitida en varias placas, e executa un binario FTL de 32 bits sen queixarse, ata o momento en que instala algo publicado só para arm64. Imprima ambas as metades antes de escoller unha imaxe e garde a saída xunto ás súas notas.

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

Se esas dúas liñas de arquitectura non coinciden, está nunha configuración mixta: viable para Pi-hole só, fráxil en canto un segundo servizo quere bibliotecas nativas. Volver gravar unha imaxe limpa de 64 bits adoita ser máis rápido que reconstruír a cadea de ferramentas que produciu a discrepancia.

O márketing da placa tampouco o resolve. O tamaño da memoria e o modelo de CPU non din nada sobre contra que libc ligan os seus paquetes, así que decida polos valores impresos, nunca pola páxina do produto.

Unha caixa, dous servizos, un dono da rede

Decida quen posúe o direccionamento, o resolutor e o túnel antes de que entre o primeiro paquete, porque se non dous servizos acabarán reclamando o mesmo deber e ningún gañará limpo. Dea ao Pi un enderezo estático fóra do grupo DHCP que reparte o seu router e manteña o túnel na súa propia subrede: 192.168.50.10 para o Pi e 10.42.0.0/24 para o túnel é unha división viable, e os números en si son arbitrarios mentres non choquen co que o seu router xa serve. Logo anote que compoñente responde no porto 53, cal reparte DHCP se o usa e cal posúe a ruta predeterminada mentres o túnel está activo. Nunha imaxe sen contorno gráfico, esa última tarefa pertence a NetworkManager ou systemd-networkd, e instalar un cliente de provedor que tamén reescribe a configuración do resolutor é como a xente acaba cun túnel vivo e un DNS morto.

Compartir a caixa está ben. Compartir un rol non. Pi-hole quere ser o único oínte no porto 53, e o daemon VPN quere empuxar a súa propia configuración de DNS aos clientes, así que escolla en cal dos dous deben confiar os clientes e configure o outro para que non estorbe.

Manteña a ruta de administración fóra do túnel cando poida. Se o resolutor e o túnel fallan xuntos, vostede segue querendo SSH accesible no enderezo LAN, e iso significa que o servizo de xestión non debe depender de ningún dos dous.

Faga da próxima actualización parte da escolla

Unha versión que non pode actualizar é un teito de soporte que xa aceptou. Probe a mecánica de actualización nunha tarxeta de reposto antes de que o aparello leve o DNS da súa casa, e lea o que din os proxectos sobre saltar entre ramas en lugar de supoñer que abonda cunha actualización de paquete.

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

Os paquetes retidos son a razón habitual de que unha actualización pareza exitosa e non cambie nada. Libere as retencións a propósito, unha a unha, e anote que servizo necesitaba a fixación.

Antes do salto, exporte a configuración de Pi-hole, as concesións estáticas e calquera perfil de túnel, e confirme que pode restauralos nunha imaxe nova. Despois do salto, probe o DNS normal dos clientes, o recurso privado detrás do túnel, unha reconexión e calquera regra de reenvío na pasarela. Unha caixa que arranca e responde a ping non superou case nada.

Cando ningunha versión única encaixa cos dous servizos

Ás veces a superposición está baleira: o asistente de VPN pasou a unha versión máis nova que o paquete de Pi-hole que pode instalar, ou a imaxe do fabricante da placa vai por detrás de ambas. Nese caso separe os roles en lugar de editar metadatos de versión para satisfacer un instalador. Dous dispositivos pequenos, ou un dispositivo máis un contedor para o segundo servizo, custan menos que un aparello cuxa historia de soporte depende dunha mentira.

Falsificar a versión é o único atallo que convén rexeitar de plano. Os xestores de paquetes cren no que di o ficheiro de versión, así que un identificador falsificado dálle unha instalación que ningún dos dous proxectos lle axudará a depurar.

Se dúas versións actuais o satisfán todo, escolla a que poida seguir as súas notas de actualización sen adiviñar, e deixe de buscar. Logo rexistre a versión, a arquitectura, os donos dos servizos e o paso de restauración nun só lugar, porque a seguinte persoa que toque a tarxeta SD necesitará as catro cousas.

Artigos relacionados