一台のPiでPi-holeとVPN：OSはまだサポート対象か？

Pi-holeとVPNを同居させた箱では、二つのことが混同されます。導入したディストリビューションの系統と、各コンポーネントが実際にサポートするリリースおよびアーキテクチャです。イメージが起動するボードはカーネルが動くことの証拠にすぎず、Pi-holeのFTLバイナリとVPNインストーラが同じユーザー空間を狙っていることの証拠にはなりません。本当の試験は、ボード対応、リリース系列、パッケージのアーキテクチャ、自分で進められるアップグレード経路という四つの重なりです。どれか一つ欠ければ、今週は動いても、次のセキュリティ更新で行き止まりになります。

サポートを決めるのはリリース系列であり、系統の名前ではない

プロジェクトがまだどのリリースで試験しているかを尋ね、答えはDebianではなくバージョン文字列として書き留めます。Pi-holeの前提条件ページは、対応するオペレーティングシステムとビルド済みFTLアーキテクチャを二つの別個の要件として挙げ、サポートをディストリビューション自身がまだ保守しているリリースに限定し、対応リストの内側でも派生版や特殊な構成は失敗しうると警告しています。この表現は重要です。対応する系統が、そのすべての成員を覆うわけではありません。

Piでまだ起動する古いイメージは、サポートの証拠ではありません。ボードは問題なく、パッケージ索引は古く、ずれは後になって表面化します。インストーラが、そのリリースではもう満たせない依存関係を引いてきたときです。

VPN側には部品が多く、それぞれに窓があります。トンネルのデーモン、その設定を書き込むインストール補助、プロバイダのクライアントアプリ、ディストリビューションの統合パッケージは四つの別プロジェクトです。あなたのディストリビューションを認識するインストーラと、そのリリースが動かし続けられるサービスを生み出すインストーラは、別の主張です。デーモン自身の対応プラットフォーム一覧を調べ、次に、動かそうとしている補助がそのリリースの公開以降に手を入れられているかを調べます。プロジェクトが特定のリリースまでしか対応を明示していない場合は、次のリリースを自分で起動するまで未検証として扱ってください。

バイナリの対象を、手元のユーザー空間に合わせる

アーキテクチャはより静かな失敗です。32ビットのユーザーランドを載せた64ビットカーネルは複数のボードで実在する対応済みの組み合わせで、32ビットのFTLバイナリを不平もなく動かします。arm64向けにしか公開されていないものを入れる瞬間まで。イメージを選ぶ前に両方を出力し、その結果をメモの隣に置いてください。

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

この二つのアーキテクチャ行が食い違うなら、混成構成です。Pi-hole単体なら動きますが、二つ目のサービスがネイティブライブラリを求めた時点でもろくなります。きれいな64ビットイメージに焼き直すほうが、ずれを生んだツールチェーンを組み直すよりたいてい速いです。

ボードの宣伝もこれを決めません。メモリ容量とCPUの型番は、あなたのパッケージがどのlibcにリンクするかを何も語りません。判断は出力された値で行い、製品ページで行ってはいけません。

一つの箱、二つのサービス、ネットワークの所有者は一人

最初のパッケージを載せる前に、アドレス管理、リゾルバ、トンネルの所有者を決めてください。さもないと二つのサービスが同じ役目を主張し、どちらもきれいに勝てません。Piにはルータが配るDHCPプールの外の固定アドレスを与え、トンネルは独自のサブネットに置きます。Piに192.168.50.10、トンネルに10.42.0.0/24という分割は一つの現実的な案で、数字自体は、ルータがすでに提供しているものと衝突しない限り任意です。次に、どのコンポーネントが53番ポートで応答するか、使うならどれがDHCPを配るか、トンネルが上がっている間どれが既定ルートを持つかを書き留めます。画面のないイメージでは最後の仕事はNetworkManagerかsystemd-networkdのもので、リゾルバ設定まで書き換えるプロバイダのクライアントを入れるのが、生きたトンネルと死んだDNSに至る道です。

箱を共有するのは構いません。役割を共有するのは違います。Pi-holeは53番ポートの唯一の待ち受けでありたがり、VPNデーモンは自前のDNS設定をクライアントに押し付けようとします。クライアントがどちらを信じるかを選び、もう一方は道を空けるように設定してください。

できる限り管理経路はトンネルの外に置きます。リゾルバとトンネルが同時に落ちても、LANアドレスでSSHに届いてほしいはずです。つまり管理サービスはどちらにも依存してはいけません。

次のアップグレードを選択の一部にする

アップグレードできないリリースは、すでに受け入れたサポートの天井です。家のDNSをこの機器が担う前に、予備のカードでアップグレードの仕組みを試し、パッケージ更新で足りると決めつけるのではなく、系列をまたぐことについてプロジェクトが何と言っているかを読んでください。

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

更新が成功したように見えて何も変わらないのは、たいてい保留にされたパッケージのせいです。保留は一つずつ意図的に外し、どのサービスが固定を必要としたかを書き留めます。

跳ぶ前に、Pi-holeの設定、固定リース、トンネルのプロファイルを書き出し、新しいイメージへ復元できることを確認します。跳んだ後は、通常のクライアントDNS、トンネルの先の私有リソース、再接続、ゲートウェイ上の転送規則を試します。起動してpingに応答する箱は、ほとんど何も合格していません。

どの単一リリースも二つのサービスに合わないとき

重なりが空になることがあります。VPNの補助が、入れられるPi-holeパッケージより新しいリリースへ移ったか、ボードのベンダーイメージが両方より遅れている場合です。その場合は、インストーラを満足させるためにリリースのメタデータを書き換えるのではなく、役割を分けてください。小さな機器二台、あるいは機器一台と二つ目のサービス用のコンテナのほうが、サポートの物語が嘘に支えられた機器より安く済みます。

バージョンを偽るのは、きっぱり拒むべき唯一の近道です。パッケージマネージャはリリースファイルの記述を信じるので、偽の識別子は、どちらのプロジェクトもデバッグを手伝わない導入を生みます。

現行のリリースが二つともすべてを満たすなら、推測なしにアップグレード手順を追えるほうを選び、探すのをやめてください。そしてバージョン、アーキテクチャ、サービスの所有者、復元手順を一か所に記録します。次にSDカードへ触れる人は、その四つすべてを必要とするからです。