画面なしPiでのProton VPN：アプリかWireGuardファイルか

画面のないPiでLinuxアプリをインストールするのは一つの指示のように聞こえますが、サポート範囲の異なる二つの導入経路の選択が隠れています。一つはプロバイダーの公式アプリで、独自のディストリビューション要件とアーキテクチャ要件を伴います。もう一つは、OSがすでにパッケージ化している標準クライアントが使う手動の設定ファイルです。どちらも同じサービスに到達しますが、保守の面では互換ではありません。

アーキテクチャの問いが先です。64ビットのボードが32ビットのユーザー空間を動かしていることがあり、アプリはそのどちらか一方しか提供しないからです。

サポート境界は二つ、インストーラーは二つではない

使おうとしているアプリについて、プロバイダーの現在のインストールページを読み、ボードと突き合わせます。ディストリビューションのリリース、パッケージのアーキテクチャ、デスクトップやセッションの要件です。Piが64ビット動作に対応していても、いまインストールされているユーザー空間がどちらかは分かりません。パッケージマネージャーが確認するのはまさにその値です。dpkg --print-architectureとuname -mがそれぞれ一行で答えます。リリースやアーキテクチャが文書化された範囲外なら、インストールできてもその環境ではサポートされません。

サポートはパッケージ方法によっても変わります。あるパッケージ形式について文書化された制限は、リポジトリのビルドに自動的に当てはまるわけではなく、Debian派生のディストリビューションが自動的にサポート対象環境になるわけでもありません。コミュニティのパッケージや古いインストール手順には独自の保守モデルがあり、意図して受け入れることはできても、偶然に採用すべきではありません。

アプリが与え、プロファイルが与えないもの

公式アプリは単なる接続ではありません。通常はプロバイダーのキルスイッチ、DNS処理、機能の切り替えを備え、プロバイダーはそれらを一組としてサポートします。標準クライアントに渡した手動プロファイルは、そのどれも引き継ぎません。手動クライアントは接続のライフサイクルとローカルの障害ポリシーを自分で持ちます。自分で設定すれば問題ありませんが、付いてくると想定すると驚きます。どちらの選択肢も同じサーバーに到達しますが、周辺のロジックを含むのは一方だけです。

機能が重要なら、たとえばトンネル外の通信を遮断するなら、それはプロバイダーのアプリではなく自分の設定に存在しなければなりません。

WireGuardを手動で：重要な手順

プロバイダーは標準準拠クライアント向けのWireGuard設定の生成を文書化し、手動設定にはその経路を勧めています。古い端末向けにはOpenVPNを残します。アカウントのダッシュボードでプロファイルを生成し、Piに持ち込み、所有者だけが読める場所に置きます。ファイルをサポートスレッドに貼り付けないでください。親しみやすいファイル名でも、埋め込まれた秘密鍵を公開可能にはしません。その後、他の何かをつなぐ前に一回のリクエストでトンネルを試します。

サーバーの廃止は忘れられがちな運用上の詳細です。手動で選んだエンドポイントは取り下げられることがあり、プロバイダーは代替設定が必要になる場合があると記しています。プロファイルが使うエンドポイントを記録し、後日の障害を診断できるようにします。

Piがゲートウェイも兼ねるかを決める

Pi自身のアプリが使うトンネルは、その背後にある端末のゲートウェイに自動的になるわけではありません。転送、戻り経路、リゾルバーの所有、トンネル外への通信を防ぐポリシーは、それぞれ独自の障害モードを持つ別設計です。他の端末が範囲に入るなら、Piの接続がそれらを覆うと想定せず、個別のケースとして評価します。その切り分けが小さな導入を保守可能に保ちます。

次にライフサイクルを受け入れます。Piからの新しい要求、意図したリゾルバーによる名前解決、そして計画した起動時や再接続時の動作です。アプリやプロファイルが提供すると想定せず、それぞれを確認します。

手放すべき俗説は、LinuxのインストーラーとWireGuardファイルが同じ判断を表すというものです。両者は所有者の異なる二つの運用モデルです。