障害・トラブル — Collabora 統合の苦戦記録

解決済 2026-03-30 Collabora 統合作業 参考 「過去のハマりポイント」として残す

• Nextcloud で office ファイル (.docx, .xlsx) をクリックしても開かない
• エラーメッセージなし、 読み込み中のまま停止
• hirame の Collabora コンテナログに 何も出てこない = リクエスト到達せず

# R640 → hirame 疎通
ping 173.0.0.10                                # OK 0.2ms
curl http://173.0.0.10:9980/hosting/discovery  # OK XML返ってくる

! 問題発見: Discovery XML の中に https://173.0.0.10:9980 が含まれていた。 ブラウザから到達不可なプライベートIPが返ってる。

Collabora コンテナ起動時に server_name 環境変数が未設定だったため、 Collabora が WOPI discovery レスポンスで自身のIP (173.0.0.10) をそのまま返していた。

curl -s http://173.0.0.10:9980/hosting/discovery | grep urlsrc | head -3

# 誤 (修正前):
<action ... urlsrc="https://173.0.0.10:9980/browser/..." />

# 正 (修正後):
<action ... urlsrc="https://office.wan-secure.net/browser/..." />

docker stop collabora && docker rm collabora
docker run -d --name collabora -p 9980:9980 \
  -e "server_name=office.wan-secure.net" \   # ← これを追加
  -e "aliasgroup1=https://cloud\\.k2-o\\.net" \
  -e "extra_params=--o:ssl.enable=false --o:ssl.termination=true" \
  -e "username=admin" -e "password=***" \
  --restart always collabora/code

ERR  #31: WOPI::CheckFileInfo returned 403 (Forbidden)
認証されていない WOPI ホストです。

根本原因: aliasgroup1 に :443 を含めていたため、 Collabora が cloud.k2-o.net を識別できなかった。

# 誤
-e "aliasgroup1=https://cloud\\.k2-o\\.net:443"

# 正
-e "aliasgroup1=https://cloud\\.k2-o\\.net"

173.0.0.10 - - [30/Mar/2026:09:23:58 +0900] "GET /index.php/apps/richdocuments/wopi/files/test HTTP/2.0" 403 162

根本原因: nginx で allow 173.0.0.0/30; としていたが、 これは 173.0.0.0 〜 173.0.0.3 しか許可しない。 hirame の 173.0.0.10 は範囲外。

# /etc/nginx/sites-available/cloud.k2-o.net
location ^~ /index.php/apps/richdocuments/wopi/ {
    allow 173.0.0.8/29;   # 173.0.0.8〜15 を許可
    allow 192.168.20.0/24;
    deny all;
    proxy_pass http://127.0.0.1:9080;
    ...
}

R640 nginx access log:

119.26.175.225 - - "GET /index.php/apps/richdocuments/wopi/files/... HTTP/1.1" 403 162

! 問題: Collabora コンテナからのリクエストが 外部IP (119.26.175.225) 経由で届いている。 これは内部通信として想定外。

1. hirame の /etc/hosts に 2行: 173.0.0.9 cloud.k2-o.net + 192.168.20.21 cloud.k2-o.net
2. hirame は VLAN20 を持たない → 192.168.20.21 に到達不可
3. DNS フォールバックで外部DNS (パブリックIP) を解決
4. Docker コンテナは /etc/hosts を参照せず、 独自にDNS問い合わせを実行

• hirame /etc/hosts から 192.168.20.21 行を削除
• R640 nginx の allow に 119.26.175.225; を追加
• Nextcloud wopi_allowlist にも 119.26.175.225 を追加

# 当時の設定
sudo docker exec -u www-data nextcloud-stack-app-1 php occ config:list richdocuments
{
  "apps": {
    "richdocuments": {
      "wopi_allowlist": "173.0.0.10"   # ← 119.26.175.225 が無い
    }
  }
}

# 修正
php occ config:app:set richdocuments wopi_allowlist --value="173.0.0.10,119.26.175.225"

Docker コンテナはホストの /etc/hosts を そのまま参照しない。 独自のDNS解決を行う。 ホストの hosts をコンテナに反映させるには --add-host オプションが必要。

173.0.0.10 を許可するには /30 では不足、 /29 以上が必要。

• nginx: allow/deny ディレクティブ
• Nextcloud richdocuments: wopi_allowlist 設定

両方を一致させる必要がある。 片方だけ通っても 403 になる。

• server_name: Discovery XML の URL 生成に使用
• aliasgroup1: WOPI host 認証 (ポート番号 不要)
• extra_params: net.post_allow.host で Nextcloud IP を許可

2026-05-14 の R640 再構築 + maguro 集約により、 Collabora 問題は本質的に解消した。

# fabric 疎通
ping 173.0.0.5    # maguro fabric (現用)
ping 173.0.0.10   # hirame

# Collabora discovery
curl -s http://173.0.0.10:9980/hosting/discovery | grep urlsrc | head -3
# https://office.wan-secure.net が含まれていればOK

ssh hirame@192.168.10.40
docker logs collabora -f

# 成功パターン:
#   INF  WOPI::CheckFileInfo succeeded
#   INF  Loaded document from storage

# 失敗パターン:
#   ERR  WOPI::CheckFileInfo returned 403 (Forbidden)

ssh maguro@192.168.70.30
sudo tail -f /var/log/nginx/access.log | grep wopi
# remote_addr が 173.0.0.6 になっていれば正常 (fabric直結経路)

# maguro Docker
sudo docker exec -u www-data nextcloud-stack-app-1 \
  php occ config:list richdocuments

# wopi_allowlist のみ
sudo docker exec -u www-data nextcloud-stack-app-1 \
  php occ config:app:get richdocuments wopi_allowlist

• Docker のDNS は独立 — ホストの /etc/hosts は効かない。 --add-host で明示する。
• CIDR を確認しろ — /30 は 4個しか入らない。 ホストIPを許可するときは要計算。
• 多段 allowlist は両方合わせる — nginx allow と app側 allowlist は別物。 片方だけだと無音で 403。
• ログを見る順番: 1) ブラウザ DevTools 2) nginx access 3) Collabora docker logs 4) Nextcloud 内部ログ。 1段ずつ進む。
• L4 passthrough は source IP を消す — nginx stream で SNI 振り分けすると source は nginx の出口IFになり、 内部識別不能になる。 fabric 直結に逃がせるなら逃がす方が良い。