目的

• 顧客アクセスを WireGuard 経由に限定 する。
• R640 を外部へ直接公開しない。
• VPS を唯一の公開入口として使う。
• Nextcloud / Portal / 将来のWebサイトを、顧客が迷わない導線で提供する。
• WebDAV、OnlyOffice iPhone、FE File Explorer での利用を成立させる。

今回の結論は、「VPS の前に WireGuard を置く」 ことです。

つまり、顧客が最初に触る入口は公開 443 ではなく、WireGuard 接続後の内部経路 とします。

これにより、顧客はグローバルIPで直接 443 に入るのではなく、まず WireGuard で認証され、その後に Portal や Nextcloud へ進む構造になります。

• VPS の 443 をそのまま公開すると、顧客は WireGuard を通らなくても入口に到達できてしまう。
• その場合、VPS と R640 の間で WireGuard を使っていても、それは裏側の配送路でしかなく、顧客の入場制御 としての WireGuard の意味が弱くなる。
• R640 を直接さらす構成は、攻撃面・障害面・思想面のどれを見ても避けたい。
• 将来サービスが増えても、入口を統一しておくほうが運用しやすい。

[ 顧客端末 ]
      ↓
  WireGuard
      ↓
[ VPS ]
  ├ WG終端
  ├ nginx / 443終端
  ├ 内部DNS
  └ R640へ転送
      ↓
  WireGuard / 閉域経路
      ↓
[ R640 ]
  ├ Nextcloud
  ├ 顧客ポータル
  ├ API
  └ その他内部サービス

顧客は IP やポート番号を意識しません。役割ごとのドメインだけを案内します。

公開DNSでは、各ドメインの表向きの向き先を管理します。

ただし、WG 必須のサービスについては、顧客が最終的に使う経路を 内部DNS 側で上書き する前提で設計します。

WireGuard 接続後に使う名前解決は、内部DNSで統一します。

基本思想は、顧客は WG 接続後だけ正しい内部向きの名前解決結果を受け取る ことです。

例
cloud.k2-o.net  → VPS の WG内IP
portal.k2-o.net → VPS の WG内IP

今回の方針では、顧客の入口が VPS 側にあるため、顧客向け内部DNSは VPS 側に寄せる のが筋です。

R640 側に内部DNSを持たせる案もあるが、顧客がまず到達する場所は VPS なので、顧客向け名前解決も VPS 側に寄せたほうが構造が自然です。

R640 側の DNS は、内部運用用途や将来の補助用途として持つのは可です。

現在、R640 と VPS の双方に各ドメインの証明書が入っているとのことだが、顧客が実際に見る証明書は VPS 側 に統一して考えるのがよいです。

最初の安定化段階では、VPS で 443 終端 し、VPS から R640 へは HTTP 転送にするのが切り分けしやすいです。

将来的に必要であれば、VPS から R640 への区間も HTTPS 化します。

• OnlyOffice や WebDAV は、ホスト名認識やヘッダ不足で壊れやすい。
• 多段TLSにすると、切り分け対象が増える。
• まずは 顧客から見えるURLと証明書を VPS 側で一本化 するほうが安定する。

この構成でも、Nextcloud Web、WebDAV、OnlyOffice iPhone、FE File Explorer は成立可能です。

ただし、成立条件を満たさないと不安定になります。

FE File Explorer 等では、基本的に次のような考え方になります。

接続先ホスト: cloud.k2-o.net
プロトコル: HTTPS
ポート: 443
DAVパス: /remote.php/dav/files/ユーザー名/

• IPアクセスを使わないこと。
• 自己署名や内部だけの証明書に頼らないこと。
• Nextcloud の外部URL認識がズレないこと。
• リバプロ経由でも https://cloud.k2-o.net として一貫して見えること。

Nextcloud は、公開URLを cloud.k2-o.net と認識している必要があります。

設定の考え方としては、Trusted Domains、overwritehost、overwriteprotocol、overwrite.cli.url、trusted_proxies を VPS 経由前提でそろえる必要があります。

'trusted_domains' => [
  'cloud.k2-o.net',
],

'overwritehost' => 'cloud.k2-o.net',
'overwriteprotocol' => 'https',
'overwrite.cli.url' => '[https://cloud.k2-o.net](https://cloud.k2-o.net)',

'trusted_proxies' => [
'VPSの転送元IP',
],

実際の値は本番のネットワーク設計に合わせて調整するが、思想としてはこの方向で統一すること。

VPS 側 nginx は、顧客が見る唯一の 443 終端 です。

役割は次のとおりです。

• WG 接続後の顧客からの 443 を受ける。
• 正規証明書を提示する。
• Host ヘッダを維持したまま R640 の Nextcloud や Portal に転送する。
• 必要な X-Forwarded 系ヘッダを渡す。
• WebDAV や OnlyOffice を壊さないように、必要に応じて buffering や request body 制限を調整する。

以前は VPS 側で 403 を返す構成になっていたため、WG 接続済みでも検証できない状態になっていました。

今後は、一般の外部アクセスは遮断しつつ、WG 内からの内部向けアクセスは通す という設計に切り替える必要があります。

提示された client_ui.py は、顧客ポータルUI、QR表示、conf配布、端末状態表示、親端末昇格、停止・復帰・削除などを担うコードです。

これは 顧客ポータル機能として重要 ですが、OnlyOffice や WebDAV が通るかどうかの本質は、このコードではなく、ネットワーク経路 / DNS / リバプロ / Nextcloud自己認識 側にあります。

• 契約IDとパスフレーズによるログイン
• 契約情報と端末情報の表示
• WireGuard 接続状態表示
• QR 表示
• conf ダウンロード
• 端末追加・停止・復帰・昇格・削除

今回の構成の大きな利点は、将来サービスが増えても、顧客導線を名前で固定できることです。

• 入口が WireGuard に統一される。
• 役割ごとにドメインを固定できる。
• VPS / R640 / ポート番号 / 内部IP を顧客に意識させない。
• 将来サービス実体を別サーバへ移しても、ドメインは維持できる。

• VPS は必須。
• R640 は外部へ直接見せない。
• 顧客の最前段は WireGuard にする。
• VPS が WG終端 + DNS + 443終端 + 転送 を担う。
• R640 は Nextcloud / Portal / API の実体 に集中させる。
• cloud.k2-o.net を Nextcloud の正規公開名として扱う。
• WebDAV、OnlyOffice iPhone、FE File Explorer はこの構成で成立可能。
• 顧客導線は、サービスごとのドメイン名で固定する。

1. VPS を顧客用 WireGuard の最前段として整理する。
2. 顧客が使う内部DNSの返答先を VPS 側の内部向きに統一する。
3. VPS nginx を 403 固定構成から、WG内アクセスを受けて R640 へ転送する構成へ修正する。
4. Nextcloud の公開URL認識を https://cloud.k2-o.net で統一する。
5. FE File Explorer で WebDAV 接続確認を行う。
6. OnlyOffice iPhone の動作確認を行う。
7. 安定後、必要に応じて VPS→R640 の HTTPS 化を検討する。
8. 将来の portal / cloud / www のドメイン整理を本番運用前提で固定する。

次回以降の作業では、絶対に「公開443が入口」の発想に戻さないこと。

今回の本質は、WG が最前段 であり、その後ろに VPS の 443 終端があり、さらにその後ろに R640 の実サービス群がある、という順序です。

Portal、Nextcloud、将来Web のどれも、顧客にとっては「役割ごとの名前」で見えるようにし、サーバ配置や内部経路を意識させないこと。