Pi-hole at VPN sa isang Pi: sinusuportahan pa ba ang operating system?

Sa isang pinagsamang kahon ng Pi-hole at VPN, dalawang bagay ang naghahalo: ang pamilya ng distribusyong inilagay mo at ang release kasama ang arkitekturang tunay na sinusuportahan ng mga bahagi. Ang board na nagbo-boot ng image ay nagpapatunay na tumatakbo ang kernel; hindi nito pinatutunayan na ang FTL binary ng Pi-hole at ang installer ng VPN mo ay parehong user space ang tinutumbok. Ang tunay na pagsubok ay apat na panig na overlap ng suporta sa board, sangay ng release, arkitektura ng pakete at landas ng pag-upgrade na kaya mong pangasiwaan. Mawala ang alinman sa apat na paang ito at gagana ang appliance ngayong linggo, saka ka iiwan sa susunod na security update.

Ang sangay ng release ang nagtatakda ng suporta, hindi ang pangalan ng pamilya

Itanong kung aling release pa ang sinusubukan ng proyekto, pagkatapos isulat ang sagot bilang version string, hindi bilang Debian. Ang pahina ng mga paunang kailangan ng Pi-hole ay naglilista ng mga sinusuportahang operating system at mga prebuilt na FTL architecture bilang dalawang hiwalay na kailangan, nililimitahan ang suporta sa mga release na pinapanatili pa ng distribusyon mismo, at nagbababala na ang mga variant o kakaibang configuration ay maaaring mabigo kahit sa loob ng sinusuportahang listahan. Mahalaga ang pananalitang iyon: ang sinusuportahang pamilya ay hindi sumasaklaw sa bawat miyembro nito.

Ang lumang image na nagbo-boot pa sa Pi mo ay hindi ebidensya ng suporta. Maayos ang board, luma na ang index ng pakete, at lumilitaw ang mismatch mamaya, kapag humila ang installer ng dependency na hindi na maibibigay ng release.

Mas maraming bahagi ang panig ng VPN, bawat isa may sariling bintana: ang tunnel daemon, ang install helper na nagsusulat ng configuration nito, ang client app ng provider at ang integration package ng distribusyon ay apat na hiwalay na proyekto. Ang installer na nakikilala ang distribusyon mo at ang installer na gumagawa ng serbisyong kayang panatilihing tumatakbo ng release ay dalawang magkaibang claim. Hanapin ang sariling platform list ng daemon, pagkatapos hanapin kung ang helper na balak mong patakbuhin ay nagalaw mula nang ilabas ang release na iyon. Kung ang isang proyekto ay nagsasaad ng suporta hanggang sa isang pinangalanang release lamang, ituring ang susunod bilang hindi nasubok hanggang ikaw mismo ang nagboot nito.

Itugma ang binary target sa user space na mayroon ka

Ang arkitektura ang mas tahimik na pagkabigo. Ang 64-bit kernel na may 32-bit na user land ay tunay at sinusuportahang kombinasyon sa maraming board, at pinapatakbo nito ang 32-bit FTL binary nang walang reklamo, hanggang sa sandaling mag-install ka ng bagay na inilalathala para sa arm64 lamang. I-print ang dalawang hati bago pumili ng image, at itago ang output sa tabi ng mga tala mo.

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

Kung hindi tugma ang dalawang linyang iyon ng arkitektura, nasa pinagsamang setup ka: kaya para sa Pi-hole lamang, marupok kapag humingi ng native libraries ang ikalawang serbisyo. Ang muling pag-flash sa malinis na 64-bit image ay karaniwang mas mabilis kaysa muling pagbuo ng toolchain na gumawa ng mismatch.

Hindi rin ito pinagpapasyahan ng marketing ng board. Ang laki ng memorya at modelo ng CPU ay walang sinasabi tungkol sa kung aling libc nakalink ang mga pakete mo, kaya magpasya batay sa mga nakalimbag na halaga, hindi kailanman batay sa pahina ng produkto.

Isang kahon, dalawang serbisyo, isang may-ari ng network

Magpasya kung kanino ang addressing, resolver at tunnel bago ipasok ang unang pakete, kung hindi ay may dalawang serbisyong mag-aangkin ng parehong tungkulin at walang mananalo nang malinis. Bigyan ang Pi ng static na address sa labas ng DHCP pool na ipinamimigay ng router mo, at panatilihin ang tunnel sa sarili nitong subnet: 192.168.50.10 para sa Pi at 10.42.0.0/24 para sa tunnel ay isang praktikal na paghahati, at ang mga numero mismo ay arbitraryo hangga't hindi sila bumabangga sa ibinibigay na ng router mo. Pagkatapos itala kung aling bahagi ang sumasagot sa port 53, alin ang namimigay ng DHCP kung ginagamit mo ito, at alin ang may default route habang nakataas ang tunnel. Sa image na walang screen, ang huling gawaing iyon ay sa NetworkManager o systemd-networkd, at ang pag-install ng client ng provider na nagsusulat muli ng configuration ng resolver ang paraan kung paano nauuwi ang mga tao sa buhay na tunnel at patay na DNS.

Maayos lang ang pagbabahagi ng kahon. Ang pagbabahagi ng tungkulin ay hindi. Gusto ng Pi-hole na siya lang ang tagapakinig sa port 53, at gustong itulak ng VPN daemon ang sarili nitong setting ng DNS sa mga client, kaya piliin kung alin sa dalawa ang dapat pagkatiwalaan ng mga client at i-configure ang isa para lumayo sa daan.

Ilayo ang daan ng administrasyon sa tunnel kapag kaya mo. Kung sabay na mabigo ang resolver at tunnel, gusto mo pa ring maabot ang SSH sa LAN address, at ibig sabihin noon ay hindi dapat umasa ang serbisyo ng pamamahala sa alinman sa dalawa.

Gawing bahagi ng pagpili ang susunod na upgrade

Ang release na hindi mo ma-upgrade ay kisame ng suporta na tinanggap mo na. Subukan ang mekaniks ng upgrade sa ekstrang card bago pasanin ng appliance ang DNS ng sambahayan mo, at basahin ang sinasabi ng mga proyekto tungkol sa paglundag sa pagitan ng mga sangay imbes na ipagpalagay na sapat na ang package upgrade.

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

Ang mga naka-hold na pakete ang karaniwang dahilan kung bakit mukhang matagumpay ang upgrade at wala namang nabago. Bitawan ang mga hold nang sadya, isa-isa, at itala kung aling serbisyo ang nangailangan ng pin.

Bago ang paglundag, i-export ang configuration ng Pi-hole, ang mga static lease at anumang tunnel profile, at kumpirmahing maibabalik mo ang mga ito sa bagong image. Pagkalundag, subukan ang ordinaryong client DNS, ang pribadong resource sa likod ng tunnel, ang muling pagkonekta, at anumang forwarding rule sa gateway. Ang kahon na nagbo-boot at sumasagot sa ping ay halos wala pang napasa.

Kapag walang isang release na umaangkop sa dalawang serbisyo

May pagkakataong walang laman ang overlap: lumipat ang VPN helper sa mas bagong release kaysa sa Pi-hole package na maaari mong i-install, o nahuhuli ang vendor image ng board sa dalawa. Sa ganoong kaso, paghiwalayin ang mga tungkulin imbes na i-edit ang metadata ng release para masiyahan ang installer. Dalawang maliliit na device, o isang device at isang container para sa ikalawang serbisyo, ay mas mura kaysa sa appliance na nakasalalay sa kasinungalingan ang kuwento ng suporta.

Ang pagpeke sa version ang tanging shortcut na dapat mong tanggihan nang tahasan. Naniniwala ang mga package manager sa sinasabi ng release file, kaya ang pekeng identifier ay nagbibigay sa iyo ng installation na walang tulong sa pag-debug mula sa alinman sa dalawang proyekto.

Kung dalawang kasalukuyang release ang tumutugon sa lahat, piliin ang isa na kayang sundan ang mga tala ng upgrade nang walang hula, at itigil ang paghahanap. Pagkatapos itala ang version, arkitektura, mga may-ari ng serbisyo at hakbang ng pag-restore sa isang lugar, dahil ang susunod na taong hahawak sa SD card ay mangangailangan ng apat.