Nextcloud は VPN 経由のみで：先にすべての入口を洗い出す

VPN 経由のみの Nextcloud 計画は、ブラウザを守って同期クライアントを忘れると失敗します。Web ページ、デスクトップ同期エンジン、モバイルからのアップロード、WebDAV ツール、共有リンクの受信者は、いずれも同じサービスへの経路を必要とし、それぞれが異なる入口を露出し得ます。何かを閉じる前にそれらを洗い出してください。その一覧こそが実際の境界です。

チェックリストを順番に進めます。最初の項目はこの配備にとってプライベートとは何かを定義し、後の項目は配備が本当にその定義に合っているかを試します。

境界を変える前にプライベートを定義する

要件を一文で書き留めてください：すべての利用者がアプリケーションに到達する前に VPN へ参加する必要がある、あるいはアプリケーションは公開のままでそのオリジンだけをプライベートに保つことです。これは別々の設計であり、プライベートなトンネルへ転送する公開リバースプロキシは二つ目だけを満たします。

プライベートなバックエンドアドレスは、アプリケーションをプライベートにはしません。公開マッピング、二つ目のホスト名、IPv6 リスナーが同じ Nextcloud インスタンスに到達するなら、バックエンドがどこにあっても入口は存在します。サービスをプライベートと宣言する前に、各名前を外から試してください。DNS レコードの欠落は、閉じたポートと同じではありません。

想定する利用者も合意します。従業員、家庭、パートナー組織、またはアカウントの一部です。その答えが、公開共有リンクを機能とするか矛盾とするかを決めます。その利用者をアクセス計画に書けば、それが続くすべての例外の判断基準になります。

すべての入口とすべての名前を洗い出す

公開アドレスマッピング、リバースプロキシ、代替ホスト名、IPv6 リスナー、およびサービスに到達するトンネルやメッシュのアドレスを列挙し、それらのアドレスに解決する名前も含めてください。忘れられた DNS レコードは、親しみやすいラベルの付いた入口だからです。

プロキシ設定で、転送ヘッダーと代替サーバーブロックを確認します。別のアプリケーション用に追加されたプロキシが、経路や残った仮想ホストを通じて同じ上流を露出することがあります。意図した図ではなく実際の設定を読んでください。両者はアプリケーションを移した後に最も食い違います。

次に、選ばなかった入口を遮断します。公開フロントを持つプライベートなバックエンドは VPN のみの設計ではなく、IPv4 だけを対象にしたファイアウォール規則は IPv6 リスナーを開いたままにします。同じ変更で両方の系列と両方の名前を閉じてください。

すべてのクライアントに一つのサービス名を与える

プライベート DNS をサービスに向け、その名前を VPN 経由で経路化し、その証明書を発行します。名前はプライベート経路で解決し、警告なしに検証される必要があります。IP に直接到達するクライアントでも、名前が機能する必要があります。

無関係な IP アドレスで接続するクライアントが、設計を機能させるために証明書エラーを無視する必要はないはずです。安定した名前は、アドレスが変わったときに同期クライアントが重複したサーバー項目を作るのも防ぎます。それがプライベートなサービスとプライベートな IP の違いです。

証明書の検証は有効のままにします。プライベートネットワークは露出を減らしますが、検証されていない TLS 接続を許容可能にはしませんし、警告を無視する習慣のあるクライアントは他のネットワークでも無視します。

ネットワークアクセスを範囲限定し、LAN 全体を許さない

登録済み利用者が Nextcloud サービスと必要な依存関係に到達できるようにし、サーバー管理は別の経路に保ちます。VPN が クライアントを家庭やオフィスのネットワーク全体に入れる と、そのクライアントにアプリケーションが求める以上のものを与えてしまいます。

VPN への参加は、Nextcloud のアカウント、権限、追加認証の代わりにはなりません。どの利用者がどのファイルを読めるかはアプリケーションが決め続け、ネットワーク層が唯一の制御であるべきではありません。

承認された送信元範囲とサービスポートを記録します。対象の所有者には観測された送信元が必要であり、NAT やプロキシが要求がアプリケーションに届く前に書き換えることがあります。

ブラウザ以外のワークフローをすべて見直す

デスクトップ同期とモバイルアップロードは、それぞれのタイミングで独自の接続を開きます。接続時には承認されたプライベート経路が必要で、VPN がないときは再試行、一時停止、エラー表示など動作が変わるかもしれません。ブラウザだけでなく、それぞれを試してください。

WebDAV ツールやカレンダー・連絡先クライアントは、独自の設定を持つ別の統合です。公開 URL をキャッシュしたクライアントは、境界変更後もその URL を試し続け、障害はアプリケーションの問題のように見えます。

共有リンクには明示的な判断が必要です。リンクは受信者に VPN アクセスを与えないため、真に VPN のみの設計では、リンクが有効でも外部の受信者は使えません。外部共有が必要なら、それは独自のアクセス経路を持つ意図的な例外であり、後で見つかる見落としではありません。

フェデレーションとサーバー間の統合も同じ扱いが必要です。それらは設置間の到達性の関係であり、プライベートのみの配備はそれらを支援するかどうかを明言しなければなりません。

許可された場合と拒否された場合の両方を受け入れる

承認されたクライアントから、Web インターフェースと通常のファイルのアップロードまたはダウンロードを確認します。次に同期クライアントとブラウザ以外のワークフローを一つ確認します。ブラウザだけで成功しても受け入れにはなりません。

未承認の経路から、一覧にあるすべての入口を通じてアプリケーションに到達できないことを確認します。代替ホスト名と IPv6 アドレスを試し、主要な URL だけに頼らないでください。

最後に、ネットワークポリシーと混同しやすいアプリケーション設定を見直します。trusted_domainsはインスタンスが受け入れる名前を列挙するものであり、クライアント IP の許可リストではありません。リバースプロキシがアドレス情報を提供する場合、trusted_proxiesは実際のプロキシを指定しなければならず、転送ヘッダーはそこからのみ受け入れるべきです。

ネットワーク変更と並行して通常の強化作業を続け、データとバックアップを意図しない Web 経路の外に置き、アプリケーションにパッチを当て、管理者アクセスを保護し、復旧を使える状態に保ちます。VPN は一つの入口の面を取り除きますが、登録済みクライアントを信頼できるものにはしません。