Pi-hole és VPN egy Pi-n: még mindig támogatott az operációs rendszer?

Egy kombinált Pi-hole- és VPN-dobozon két dolog keveredik: a telepített disztribúciócsalád, valamint a kiadás és architektúra, amelyet a komponensek valóban támogatnak. Az a kártya, amely elindít egy képet, bizonyítja, hogy a kernel fut; azt nem bizonyítja, hogy a Pi-hole FTL binárisa és a VPN-telepítője ugyanazt a felhasználói teret célozza. Az igazi próba a kártyatámogatás, a kiadási ág, a csomagarchitektúra és egy általad vezethető frissítési útvonal négyes metszete. Ha bármelyik lábat elveszíted, a készülék ezen a héten működik, aztán a következő biztonsági frissítésnél cserben hagy.

A támogatást a kiadási ág határozza meg, nem a családnév

Kérdezd meg, melyik kiadás ellen tesztel még a projekt, majd a választ verziószóként írd le, ne Debianként. A Pi-hole előfeltételek oldala a támogatott operációs rendszereket és az előre elkészített FTL-architektúrákat két külön követelményként sorolja fel, a támogatást azokra a kiadásokra korlátozza, amelyeket maga a disztribúció még gondoz, és figyelmeztet, hogy a változatok vagy szokatlan konfigurációk még a támogatott listán belül is meghiúsulhatnak. Ez a megfogalmazás számít: egy támogatott család nem fedi le minden tagját.

Egy régi kép, amely még elindul a Pi-n, nem bizonyíték a támogatásra. A kártya rendben van, a csomagindex elavult, és az eltérés később mutatkozik meg, amikor a telepítő olyan függőséget húz be, amelyet a kiadás már nem tud kielégíteni.

A VPN oldalán több rész van, mindegyiknek saját ablaka: a tunel démon, a konfigurációját író telepítési segéd, a szolgáltató kliensalkalmazása és a disztribúció integrációs csomagja négy külön projekt. A disztribúciódat felismerő telepítő és az olyan szolgáltatást létrehozó telepítő, amelyet a kiadás futtatva tud tartani, két különböző állítás. Nézd meg a démon saját platformlistáját, majd azt, hogy a futtatni kívánt segédet érték-e hozzá a kiadás megjelenése óta. Ahol egy projekt csak egy megnevezett kiadásig vállal támogatást, a következőt tekintsd nem teszteltnek, amíg magad nem indítottad el.

Illeszd a bináris célt a meglévő felhasználói teredhez

Az architektúra a csendesebb hiba. A 64 bites kernel 32 bites felhasználói tere valódi, támogatott kombináció több kártyán, és panasz nélkül futtat egy 32 bites FTL binárist, egészen addig a pillanatig, amíg olyasmit telepítesz, amit csak arm64-re adnak ki. Nyomtasd ki mindkét felet, mielőtt képet választasz, és tartsd a kimenetet a jegyzeteid mellett.

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

Ha ez a két architektúrasor nem egyezik, vegyes beállításon vagy: önmagában a Pi-hole-nak működik, törékeny, amint egy második szolgáltatás natív könyvtárakat kér. Egy tiszta 64 bites kép újraflashelése általában gyorsabb, mint az eltérést okozó eszközlánc újraépítése.

A kártya marketingje sem dönti el ezt. A memória mérete és a CPU-modell semmit sem mond arról, melyik libc-hez linkelődnek a csomagjaid, ezért a kinyomtatott értékek alapján dönts, soha ne a termékoldal alapján.

Egy doboz, két szolgáltatás, a hálózat egy gazdája

Döntsd el, kié a címzés, a feloldó és a tunel, mielőtt az első csomag felmegy, különben két szolgáltatás ugyanarra a feladatra tart igényt, és egyik sem nyer tisztán. Adj a Pi-nek statikus címet a routered által osztott DHCP-készleten kívül, és tartsd a tunelt a saját alhálózatán: 192.168.50.10 a Pi-nek és 10.42.0.0/24 a tunelnek egy működő felosztás, és maguk a számok tetszőlegesek, amíg nem ütköznek azzal, amit a routered már kiszolgál. Aztán írd le, melyik komponens válaszol az 53-as porton, melyik oszt DHCP-t, ha használod, és melyik birtokolja az alapértelmezett útvonalat, amíg a tunel áll. Grafikus felület nélküli képen az utolsó feladat a NetworkManageré vagy a systemd-networkd-é, és egy olyan szolgáltatói kliens telepítése, amely a feloldó konfigurációját is átírja az az út, amelyen az emberek élő tunelhez és halott DNS-hez jutnak.

A doboz megosztása rendben van. A szerep megosztása nem. A Pi-hole az egyetlen hallgató akar lenni az 53-as porton, a VPN démon pedig a saját DNS-beállítását akarja a kliensekhez tolni, ezért válaszd ki, melyikükben bízzanak a kliensek, és állítsd be a másikat, hogy maradjon ki az útból.

Tartsd az adminisztrációs útvonalat a tunelen kívül, ahol tudod. Ha a feloldó és a tunel együtt hibázik, még mindig el akarod érni az SSH-t a LAN-címen, és ez azt jelenti, hogy a kezelőszolgáltatás nem függhet egyiktől sem.

Tedd a következő frissítést a választás részévé

Egy kiadás, amelyet nem tudsz frissíteni, olyan támogatási plafon, amelyet már elfogadtál. Teszteld a frissítés mechanikáját egy tartalékkártyán, mielőtt az eszköz a háztartásod DNS-ét hordozza, és olvasd el, mit mondanak a projektek az ágak közötti ugrásról, ahelyett hogy feltételeznéd, elég egy csomagfrissítés.

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

A visszatartott csomagok a szokásos oka annak, hogy egy frissítés sikeresnek látszik és semmit sem változtat. Oldd fel a visszatartásokat szándékosan, egyenként, és jegyezd fel, melyik szolgáltatásnak kellett a rögzítés.

Az ugrás előtt exportáld a Pi-hole konfigurációját, a statikus bérleteket és minden tunelprofilt, és igazold, hogy vissza tudod állítani őket egy friss képen. Az ugrás után teszteld a szokásos kliens-DNS-t, a tunel mögötti privát erőforrást, az újracsatlakozást és az átjárón lévő bármilyen továbbítási szabályt. Egy doboz, amely elindul és válaszol a pingre, szinte semmit sem teljesített.

Amikor egyetlen kiadás sem felel meg mindkét szolgáltatásnak

Néha a metszet üres: a VPN segéd újabb kiadásra lépett, mint amilyen Pi-hole csomagot telepíteni tudsz, vagy a kártya gyártói képe mindkettő mögött kullog. Ebben az esetben válaszd szét a szerepeket, ahelyett hogy kiadás-metaadatokat szerkesztenél egy telepítő kedvéért. Két kis eszköz, vagy egy eszköz plusz egy konténer a második szolgáltatásnak, kevesebbe kerül, mint egy eszköz, amelynek támogatási története hazugságon nyugszik.

A verzió hamisítása az az egyetlen rövidítés, amelyet egyenesen el kell utasítani. A csomagkezelők elhiszik, amit a kiadásfájl mond, így egy hamisított azonosító olyan telepítést ad, amelynek hibakeresésében egyik projekt sem segít.

Ha két jelenlegi kiadás mindent kielégít, válaszd azt, amelynek frissítési jegyzeteit találgatás nélkül követheted, és hagyd abba a keresést. Aztán jegyezd fel a verziót, az architektúrát, a szolgáltatások gazdáit és a visszaállítási lépést egy helyen, mert a következő embernek, aki az SD-kártyához nyúl, mind a négyre szüksége lesz.