Pi-hole și VPN pe un singur Pi: sistemul de operare mai este acceptat?

Pe o cutie combinată cu Pi-hole și VPN se amestecă două lucruri: familia de distribuție pe care ați instalat-o și versiunea plus arhitectura pe care componentele le acceptă de fapt. O placă ce pornește o imagine dovedește că nucleul rulează; nu dovedește că binarul FTL al Pi-hole și instalatorul dumneavoastră de VPN țintesc același spațiu de utilizator. Testul real este o suprapunere în patru direcții: suportul plăcii, ramura de versiune, arhitectura pachetelor și o cale de actualizare pe care o puteți conduce singur. Pierdeți oricare dintre aceste patru picioare și aparatul funcționează săptămâna aceasta, ca apoi să vă lase baltă la următoarea actualizare de securitate.

Ramura de versiune stabilește suportul, nu numele familiei

Întrebați împotriva cărei versiuni testează încă proiectul, apoi scrieți răspunsul ca șir de versiune, nu ca Debian. Pagina de prerechizite a Pi-hole listează sistemele de operare acceptate și arhitecturile FTL precompilate ca două cerințe separate, limitează suportul la versiunile pe care distribuția însăși le mai întreține și avertizează că variantele sau configurațiile neobișnuite pot eșua chiar și în lista acceptată. Formularea aceea contează: o familie acceptată nu acoperă fiecare membru al ei.

O imagine veche care încă pornește pe Pi-ul dumneavoastră nu este dovadă de suport. Placa este în regulă, indexul pachetelor este învechit, iar nepotrivirea apare mai târziu, când un instalator trage o dependență pe care versiunea nu o mai poate satisface.

Partea de VPN are mai multe piese, fiecare cu fereastra ei: demonul tunelului, ajutorul de instalare care îi scrie configurația, aplicația client a furnizorului și pachetul de integrare al distribuției sunt patru proiecte separate. Un instalator care recunoaște distribuția dumneavoastră și un instalator care produce un serviciu pe care versiunea îl poate ține în funcțiune sunt două afirmații diferite. Căutați lista de platforme proprie a demonului și apoi dacă ajutorul pe care intenționați să îl rulați a fost atins de la apariția acelei versiuni. Unde un proiect declară suport doar până la o versiune numită, tratați-o pe următoare ca netestată până când nu ați pornit-o singur.

Potriviți ținta binară cu spațiul de utilizator pe care îl aveți

Arhitectura este eșecul mai silențios. Un nucleu pe 64 de biți cu un spațiu de utilizator pe 32 de biți este o combinație reală și acceptată pe mai multe plăci, iar el rulează un binar FTL pe 32 de biți fără reclamații, până în momentul în care instalați ceva publicat doar pentru arm64. Imprimați ambele jumătăți înainte de a alege o imagine și păstrați rezultatul lângă notele dumneavoastră.

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

Dacă acele două linii de arhitectură nu coincid, sunteți pe o configurație mixtă: viabilă pentru Pi-hole singur, fragilă de îndată ce un al doilea serviciu vrea biblioteci native. Rescrierea unei imagini curate pe 64 de biți este de obicei mai rapidă decât reconstruirea lanțului de unelte care a produs nepotrivirea.

Marketingul plăcii nici nu rezolvă asta. Dimensiunea memoriei și modelul CPU nu spun nimic despre libc-ul către care se leagă pachetele dumneavoastră, așa că decideți după valorile imprimate, niciodată după pagina produsului.

O cutie, două servicii, un singur proprietar al rețelei

Decideți cine deține adresarea, resolverul și tunelul înainte de a intra primul pachet, altfel două servicii vor revendica aceeași datorie și niciunul nu va câștiga curat. Dați Pi-ului o adresă statică în afara pool-ului DHCP pe care îl împarte routerul dumneavoastră și țineți tunelul în propria subrețea: 192.168.50.10 pentru Pi și 10.42.0.0/24 pentru tunel este o împărțire viabilă, iar numerele în sine sunt arbitrare cât timp nu se ciocnesc cu ce servește deja routerul. Apoi notați care componentă răspunde pe portul 53, care împarte DHCP dacă îl folosiți și care deține ruta implicită cât timp tunelul este activ. Pe o imagine fără ecran, ultima sarcină aparține NetworkManager sau systemd-networkd, iar instalarea unui client de furnizor care rescrie și configurația resolverului este calea pe care oamenii ajung cu un tunel viu și un DNS mort.

A împărți cutia este în regulă. A împărți un rol nu. Pi-hole vrea să fie singurul ascultător pe portul 53, iar demonul VPN vrea să împingă propria setare DNS către clienți, așa că alegeți pe care dintre cei doi ar trebui să se bazeze clienții și configurați-l pe celălalt să stea la o parte.

Țineți calea de administrare în afara tunelului când puteți. Dacă resolverul și tunelul cad împreună, tot doriți ca SSH să fie accesibil pe adresa LAN, iar asta înseamnă că serviciul de administrare nu trebuie să depindă de niciunul dintre ele.

Faceți din următoarea actualizare parte a alegerii

O versiune pe care nu o puteți actualiza este un plafon de suport pe care l-ați acceptat deja. Testați mecanica de actualizare pe un card de rezervă înainte ca aparatul să ducă DNS-ul gospodăriei dumneavoastră, și citiți ce spun proiectele despre sărirea între ramuri în loc să presupuneți că o actualizare de pachet este suficientă.

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

Pachetele ținute pe loc sunt motivul obișnuit pentru care o actualizare pare reușită și nu schimbă nimic. Ridicați reținerile cu bună știință, una câte una, și notați cărui serviciu i-a trebuit fixarea.

Înainte de salt, exportați configurația Pi-hole, lease-urile statice și orice profil de tunel, și confirmați că le puteți restaura pe o imagine nouă. După salt, testați DNS-ul obișnuit al clienților, resursa privată din spatele tunelului, o reconectare și orice regulă de redirecționare de pe gateway. O cutie care pornește și răspunde la ping nu a trecut aproape nimic.

Când nicio versiune unică nu se potrivește ambelor servicii

Uneori suprapunerea este goală: ajutorul VPN a trecut la o versiune mai nouă decât pachetul Pi-hole pe care îl puteți instala, sau imaginea producătorului plăcii rămâne în urma ambelor. În acest caz separați rolurile în loc să editați metadatele versiunii pentru a mulțumi un instalator. Două dispozitive mici, sau un dispozitiv plus un container pentru al doilea serviciu, costă mai puțin decât un aparat a cărui poveste de suport se sprijină pe o minciună.

Falsificarea versiunii este singura scurtătură pe care trebuie să o refuzați direct. Managerii de pachete cred ce spune fișierul de versiune, așa că un identificator falsificat vă dă o instalare la care niciunul dintre cele două proiecte nu vă va ajuta să depanați.

Dacă două versiuni actuale satisfac totul, alegeți-o pe cea ale cărei note de actualizare le puteți urma fără să ghiciți și opriți căutarea. Apoi consemnați versiunea, arhitectura, proprietarii serviciilor și pasul de restaurare într-un singur loc, fiindcă următoarea persoană care atinge cardul SD va avea nevoie de toate patru.