Pi VPNサーバー：レシピではなくスマホアプリから始める

Pi での VPN 構築の多くはサーバーのレシピから始まり、接続できないスマホで終わります。順序が逆なのです。スマホのクライアントは特定のプロトコルを特定の認証交換で実装しており、サーバーはその交換に合わせる必要があり、逆ではありません。アプリを先に決めれば、丸一日のデバッグが短いチェックリストに変わります。

作り直しを避ける順序

Pi に何かをインストールする前に、スマホの OS と正確な VPN アプリを書き留めます。この組み合わせが、そもそもどのプロトコルが可能かを決めます。プロファイルに見慣れたフィールドがあるからといって、クライアントアプリが別のクライアントになるわけではありません。

プロファイル内の共有シークレットや、見慣れたポート番号があっても、あるプロトコルが別のプロトコルになるわけではありません。交換はアプリの実装と一致するか、ほとんど何も読めない段階で失敗するかのどちらかです。「プロトコルが違う」と平易な言葉で示す診断はありません。タイムアウト、証明書エラー、あるいは無言の再試行ループが返ってきて、どれもサーバーの問題のように見えます。

アプリが決まればサーバーの選択肢は狭まり、残りの構築に目標ができます。

スマホのアプリが実際に実装しているもの

公開されているクライアント一覧が説明しているのはアプリケーションであり、サービスではありません。Android 用の OpenVPN Connect アプリは OpenVPN サーバーを前提としており、サーバー側を提供するものではありません。プロファイルが似ていても、IPsec や L2TP のクライアントになるわけでもありません。

この区別が最も重要になるのは、古いガイドに従うときです。現在のアプリが廃止したプロトコル向けに書かれたレシピは、Pi にはきれいにインストールできてもスマホでは失敗し続け、これはプロトコルの不一致ではなく設定ミスに見えます。

サーバーパッケージに決める前に、アプリがどのプロファイル形式を読み込むかを現在のドキュメントで確認してください。五分の読書は作り直しに勝ります。

四項目の合意

四つの事柄を書き留めて一緒に保管します。スマホの OS とアプリのバージョン、Pi 上のサーバー実装、認証と信頼の方針、そして外部エンドポイントであり、四つのうちどれか一つが残り三つを無効にすることがあります。

アプリのアップグレード、サーバーパッケージの変更、新しい認証局の導入はどれも合意を壊し、その失敗は毎回スマホから見て同じに見えます。四つを書き留めておくことが、どの部分が動いたのかを特定できる理由です。

資格情報の役割は別々

プロファイルがクライアント証明書を使うのか、ユーザー名とパスワードを使うのか、対応する組み合わせを使うのかを決め、両端を一致させます。サーバーの身元と信頼された CA の素材も、クライアントが受け入れるものと一致している必要があります。

CA の公開証明書とその署名用の秘密鍵は別のオブジェクトです。スマホのプロファイルに入るのは公開部分だけです。署名用の鍵をスマホに置くことは、身元を作る能力を渡すことであり、CA の目的とは正反対です。そのファイルは構築全体で最も機密性の高いものとして扱ってください。

プロファイルを手作業で組み立てるのではなく、サービスが対応しているエクスポートとインポートの流れを使ってください。手作業で作ったプロファイルは、モバイルアプリが無視したり拒否したりするデスクトップ専用の指示を含みがちです。

何よりも、古い例をつなぐために証明書の検証を「どのサーバーも受け入れる」に置き換えないでください。それは互換性の問題を認証の回避に変えてしまい、動くために本番まで残ることがよくあります。

到達性は別の契約

スマホは実際の上流の構成を通じてサーバーの外部エンドポイントに到達しなければなりません。家庭用ルーターの変換、フィルタリング、通信事業者の NAT がすべて両者の間にあります。 動的 DNS 名はエンドポイントに安定した名前を与えるだけであり、内向きの経路は作りません。

次に、接続後にクライアントが何に到達できるか——プライベートなプレフィックスか完全なインターネット出口か、それらの転送経路と応答経路、DNS の挙動、そして IPv6 が範囲内かどうか——を定義します。ログインの成功はそれらのどれも証明しません。

想定したスマホとプロファイルを直接受け入れ、権限のないリソースが到達不能なままであること、失効が実際にアクセスを奪うことを確認します。デスクトップクライアントでの成功が証明するのはそのデスクトップクライアントであり、手元のスマホではありません。OpenVPN Connect の一覧は、対応するサービスを前提とするクライアントアプリケーションの具体的な例です。