Pi-hole ja VPN samalla Pi:llä: tukeeko käyttöjärjestelmä vielä?
Sovita yhteen levyn tuki, käyttäjäavaruuden arkkitehtuuri, palvelujen tuki ja päivityspolku ennen kuin laitat Pi-holen ja VPN:n samaan Raspberry Pi:hin.
Yhdistetyssä Pi-hole- ja VPN-laatikossa sekoittuvat kaksi asiaa: asentamasi jakeluperhe sekä julkaisu ja arkkitehtuuri, joita komponentit todella tukevat. Kuvan käynnistävä levy todistaa, että ydin toimii; se ei todista, että Pi-holen FTL-binääri ja VPN-asentajasi kohdistuvat samaan käyttäjäavaruuteen. Todellinen testi on nelisuuntainen leikkaus levyn tuesta, julkaisuhaarasta, pakettiarkkitehtuurista ja päivityspolusta, jota voit itse ajaa. Menetä mikä tahansa näistä neljästä jalasta, niin laite toimii tämän viikon ja jättää sinut seuraavassa tietoturvapäivityksessä.
Julkaisuhaara määrää tuen, ei perheen nimi
Kysy, mitä julkaisua vasten projekti vielä testaa, ja kirjoita vastaus versiomerkkijonona, älä Debianina. Pi-holen edellytyssivu luettelee tuetut käyttöjärjestelmät ja valmiiksi rakennetut FTL-arkkitehtuurit kahtena erillisenä vaatimuksena, rajaa tuen julkaisuihin, joita itse jakelu vielä ylläpitää, ja varoittaa, että variantit tai epätavalliset kokoonpanot voivat epäonnistua jopa tuetun luettelon sisällä. Tämä sanamuoto merkitsee: tuettu perhe ei kata sen jokaista jäsentä.
Vanha kuva, joka vielä käynnistyy Pi:lläsi, ei ole todiste tuesta. Levy on kunnossa, paketti-indeksi on vanhentunut, ja epäsuhta paljastuu myöhemmin, kun asentaja vetää riippuvuuden, jota julkaisu ei enää pysty täyttämään.
VPN-puolella on enemmän osia, kullakin oma ikkunansa: tunnelidaemon, sen kokoonpanon kirjoittava asennusapuohjelma, tarjoajan asiakassovellus ja jakelun integraatiopaketti ovat neljä erillistä projektia. Asentaja, joka tunnistaa jakelusi, ja asentaja, joka tuottaa palvelun, jota julkaisu pystyy pitämään käynnissä, ovat eri väitteitä. Tarkista daemonin oma alustaluettelo ja sitten, onko apuohjelmaa, jonka aiot ajaa, koskettu sen julkaisun ilmestymisen jälkeen. Kun projekti ilmoittaa tuen vain nimettyyn julkaisuun asti, pidä seuraavaa testaamattomana, kunnes olet itse käynnistänyt sen.
Sovita binäärikohde käyttäjäavaruuteesi
Arkkitehtuuri on hiljaisempi epäonnistuminen. 64-bittinen ydin ja 32-bittinen käyttäjämaa on todellinen, tuettu yhdistelmä useilla levyillä, ja se ajaa 32-bittistä FTL-binääriä valittamatta, aina siihen hetkeen, kun asennat jotain, joka julkaistaan vain arm64:lle. Tulosta molemmat puolikkaat ennen kuvan valintaa ja pidä tuloste muistiinpanojesi vieressä.
uname -m
dpkg --print-architecture
grep -E '^(PRETTY_NAME|VERSION_ID)=' /etc/os-release
apt-cache policy pihole-ftl
Jos nuo kaksi arkkitehtuuririviä eivät täsmää, olet sekalaisessa kokoonpanossa: toimiva pelkälle Pi-holelle, hauras heti kun toinen palvelu haluaa natiivikirjastoja. Puhtaan 64-bittisen kuvan uudelleenkirjoitus on yleensä nopeampaa kuin epäsuhdan synnyttäneen työkaluketjun uudelleenrakennus.
Levyn markkinointi ei ratkaise tätäkään. Muistin koko ja CPU-malli eivät kerro mitään siitä, mihin libc:hen pakettisi linkittyvät, joten päätä tulostettujen arvojen perusteella, älä koskaan tuotesivun perusteella.
Yksi laatikko, kaksi palvelua, yksi verkon omistaja
Päätä, kuka omistaa osoitteistuksen, resolverin ja tunnelin ennen kuin ensimmäinen paketti nousee, sillä muuten kaksi palvelua vaatii saman velvollisuuden eikä kumpikaan voita puhtaasti. Anna Pi:lle staattinen osoite DHCP-poolin ulkopuolelta, jonka reitittimesi jakaa, ja pidä tunneli omassa aliverkossaan: 192.168.50.10 Pi:lle ja 10.42.0.0/24 tunnelille on yksi toimiva jako, ja luvut itsessään ovat mielivaltaisia, kunhan ne eivät törmää siihen, mitä reitittimesi jo palvelee. Kirjoita sitten ylös, mikä komponentti vastaa portissa 53, mikä jakaa DHCP:tä jos käytät sitä, ja mikä omistaa oletusreitin, kun tunneli on ylhäällä. Graafisessa ympäristössä olevassa kuvassa tuo viimeinen työ kuuluu NetworkManagerille tai systemd-networkd:lle, ja tarjoajan asiakasohjelman asentaminen, joka kirjoittaa myös resolverin kokoonpanon uudelleen on se tapa, jolla ihmiset päätyvät elävään tunneliin ja kuolleeseen DNS:ään.
Laatikon jakaminen on ok. Roolin jakaminen ei. Pi-hole haluaa olla ainoa kuuntelija portissa 53, ja VPN-daemon haluaa työntää oman DNS-asetuksensa asiakkaille, joten valitse, kumpaan kahdesta asiakkaiden pitäisi luottaa, ja kokoonpano toinen pysymään poissa tieltä.
Pidä hallintapolku tunnelin ulkopuolella, kun voit. Jos resolveri ja tunneli pettävät yhdessä, haluat silti SSH:n olevan tavoitettavissa LAN-osoitteessa, ja se tarkoittaa, ettei hallintapalvelu saa riippua kummastakaan.
Tee seuraavasta päivityksestä osa valintaa
Julkaisu, jota et voi päivittää, on tukikatto, jonka olet jo hyväksynyt. Testaa päivitysmekaniikka vara kortilla ennen kuin laite kantaa kotitaloutesi DNS:n, ja lue, mitä projektit sanovat haarojen välillä hyppäämisestä sen sijaan, että olettaisit pakettipäivityksen riittävän.
sudo apt update
apt-mark showhold
sudo apt full-upgrade
pihole -up
Pidätetyt paketit ovat tavallinen syy siihen, että päivitys näyttää onnistuneelta eikä muuta mitään. Vapauta pidätykset tietoisesti, yksi kerrallaan, ja merkitse muistiin, mikä palvelu tarvitsi kiinnityksen.
Ennen hyppyä vie Pi-holen kokoonpano, staattiset vuokraukset ja kaikki tunneliprofiilit sekä varmista, että voit palauttaa ne tuoreelle kuvalle. Hypyn jälkeen testaa tavallinen asiakas-DNS, tunnelin takana oleva yksityinen resurssi, uudelleenyhdistäminen ja mikä tahansa edelleenlähetyssääntö yhdyskäytävässä. Laatikko, joka käynnistyy ja vastaa pingiin, ei ole läpäissyt juuri mitään.
Kun mikään yksittäinen julkaisu ei sovi molemmille palveluille
Joskus leikkaus on tyhjä: VPN-apuohjelma on siirtynyt uudempaan julkaisuun kuin asennettavissa oleva Pi-hole-paketti, tai levyn valmistajan kuva laahaa molempien perässä. Siinä tapauksessa erota roolit sen sijaan, että muokkaisit julkaisun metatietoja asentajan miellyttämiseksi. Kaksi pientä laitetta tai yksi laite plus säiliö toiselle palvelulle maksaa vähemmän kuin laite, jonka tukitarina nojaa valheeseen.
Version väärentäminen on ainoa oikotie, josta kannattaa kieltäytyä suoraan. Paketinhallinta luottaa siihen, mitä julkaisutiedosto sanoo, joten väärennetty tunniste antaa asennuksen, jonka vianetsinnässä kumpikaan projekti ei auta sinua.
Jos kaksi nykyistä julkaisua täyttää kaiken, valitse se, jonka päivitysmuistiinpanoja voit seurata arvaamatta, ja lopeta etsiminen. Kirjaa sitten versio, arkkitehtuuri, palvelujen omistajat ja palautusvaihe yhteen paikkaan, sillä seuraava SD-korttiin koskeva henkilö tarvitsee kaikki neljä.