トラブルシューティング — クイック診断集

// QUICK TROUBLESHOOT — 症状別 first-aid コマンド / 最終更新: 2026-05-14

運用中 困ったときの first response 集。 「これ試してダメなら個別ページへ」

2026-05-14 構成前提: WG は maguro 側に移植済 (wg-clients / wg-customers / wg-storage)。 NC + mikyun-portal も maguro。 R640 は WP公開 + nginx SNI router 専用。 Collabora は fabric 直結。
1. WG で接続できない
# maguro でハンドシェイク確認
ssh maguro@192.168.70.30
sudo wg show wg-clients      # クライアント VPN
sudo wg show wg-customers    # 業務カスタマー
sudo wg show wg-storage      # ストレージ用

# 最近 handshake してるか
sudo wg show wg-clients latest-handshakes

# RTX1300 で NAT 確認 (telnet/ssh で RTX1300 へ)
show nat descriptor address 20000
#   20000/10  udp 54024 → 192.168.70.30:54024  (wg-clients)
#   20000/13  udp 61001 → 192.168.70.30:61001  (wg-customers)
#   20000/14  udp 62001 → 192.168.30.30:62001  (wg-storage)

# パケットキャプチャ
sudo tcpdump -i any -n udp port 54024

チェックポイント:

  • ✓ RTX1300 NAT が maguro 側 (192.168.70.30) を指してるか (旧R640 192.168.20.21 のまま残ってないか)
  • ✓ maguro 側 wg-quick@wg-clients が active か
  • ✓ クライアント側 PSK / endpoint が vpn.k2-o.net:54024 か
2. Nextcloud にアクセスできない (403)
# maguro 側で nginx vhost 確認
ssh maguro@192.168.70.30
grep -E "allow|deny" /etc/nginx/sites-available/cloud.k2-o.net

# 期待される allow:
#   192.168.20.0/24 (社内VLAN20)
#   192.168.30.21   (R640 SNI 経由分)
#   10.200.0.0/16   (wg-clients ピア)
#   173.0.0.0/29    (fabric)
#   119.26.175.225  (外部経由バックアップ)

# trusted_domains 確認
sudo docker exec -u www-data nextcloud-stack-app-1 \
  php occ config:system:get trusted_domains

# nginx アクセスログ (source IP 確認)
sudo tail -f /var/log/nginx/access.log | grep cloud.k2-o.net
注意: R640 SNI passthrough を経由すると source IP が 192.168.30.21 (R640 出口) に置換される。 これを allow から消すと 内部LANユーザー全員が 403 になる。
3. Nextcloud が白画面のまま
# maguro 側
ssh maguro@192.168.70.30
sudo docker ps | grep nextcloud-stack

# overwriteprotocol が https か確認
sudo docker exec -u www-data nextcloud-stack-app-1 \
  php occ config:system:get overwriteprotocol

# 違ったら修正
sudo docker exec -u www-data nextcloud-stack-app-1 \
  php occ config:system:set overwriteprotocol --value=https

# Docker MariaDB の生存確認
sudo docker exec nextcloud-stack-db-1 mysqladmin ping

# nginx エラーログ
sudo tail -f /var/log/nginx/error.log
4. Collabora でドキュメントが開かない
# 1. hirame の Collabora が動いてるか
ssh hirame@192.168.10.40
docker ps | grep collabora
docker logs --tail 30 collabora

# 2. Discovery が正しい URL を返すか
curl -s http://173.0.0.10:9980/hosting/discovery | grep urlsrc | head -3
#   urlsrc="https://office.wan-secure.net/browser/..." が正

# 3. Collabora → maguro fabric 接続確認 (現用経路)
docker exec collabora getent hosts cloud.k2-o.net
#   173.0.0.5 cloud.k2-o.net (--add-host で固定済) が正

# 4. maguro 側で WOPI ログ確認
ssh maguro@192.168.70.30
sudo tail -f /var/log/nginx/access.log | grep wopi
#   remote_addr が 173.0.0.6 (hirame SM-fabric IF) なら正常

詳細は「障害・トラブル (id:19)」ページの Collabora 統合記録参照。 過去の苦戦ポイントが全部書いてある。

5. R640 nginx が落ちた / katuocloud.com が開かない
# 外部から
curl -sI https://katuocloud.com/ | head -5

# R640 内部から
ssh katuo@192.168.20.21
sudo systemctl status nginx
sudo nginx -t                     # 文法チェック
sudo journalctl -u nginx --since "10 min ago" --no-pager

# stream module + ssl_preread が読み込めてるか
sudo nginx -V 2>&1 | tr ' ' '\n' | grep stream

# inner WP (127.0.0.1:8443) の生存
curl -ksI https://127.0.0.1:8443/ | head -5

# WP DB 生存
sudo systemctl status mariadb
mysql -uroot -e "USE katuocloud_wp; SHOW TABLES" | head
6. 証明書が期限切れそう / 切れた
# R640 (apt certbot)
sudo certbot certificates | grep -E "Certificate Name|Expiry"

# maguro (snap certbot)
sudo certbot certificates | grep -E "Certificate Name|Expiry"

# 手動更新 (R640)
sudo certbot renew --cert-name katuocloud.com --force-renewal
sudo systemctl reload nginx

# 手動更新 (maguro)
sudo certbot renew --cert-name cloud.k2-o.net --force-renewal
sudo systemctl reload nginx

cert-watch (06:30 daily) が 残14日で警告飛ばすので、 通常はそれで気付ける。 過去の DuckDNS 期限切れ事件以来、 監視体制を強化した。

7. ディスクが満杯
# 全ホスト共通
df -h | awk '$5+0 > 80 {print}'

# maguro storage
ssh maguro@192.168.70.30
df -h /srv/storage
du -sh /srv/storage/* 2>/dev/null | sort -h | tail -10
du -sh /srv/storage/nextcloud-data/* 2>/dev/null | sort -h | tail -10

# R640 /mnt/data
ssh katuo@192.168.20.21
df -h /mnt/data
du -sh /mnt/data/* 2>/dev/null | sort -h | tail
ls -lt /mnt/data/backup/wp/katuocloud_wp/ | head   # 古いバックアップ確認

supermicro-watch は 使用率 90%+ で通知してくれる。 alert 来てから慌てるのではなく、 月次点検で 80% 超えたら理由を調べる。

8. maguro LUKS 自動アンロックが失敗した

maguro の LUKS auto-unlock は keyfile 方式 (/etc/cryptsetup-keys.d/) + bcache + storage-cache (NVMe md127) の組み合わせ。

# 状態確認
ssh maguro@192.168.70.30
sudo cryptsetup status raid1-4
sudo cryptsetup status storage-cache
ls -lh /etc/cryptsetup-keys.d/

# 手動アンロック (緊急時)
sudo cryptsetup luksOpen /dev/sdX raid1
sudo cryptsetup luksOpen /dev/sdY storage-cache

# bcache attach
echo /dev/bcache0 > /sys/fs/bcache/register
過去の既知問題: 旧 maguro 時代、 initramfs で USB キーボードドライバが未読込で LUKS パスフレーズ入力不可になる事件があった。 現在は keyfile auto-unlock に切り替えたため発生しない。 keyfile が壊れたときは USB キーボード問題が再発する可能性あるので留意。
9. R640 PERC / SMART アラート
ssh katuo@192.168.20.21

# perc-watch が拾った最新
sudo journalctl -u perc-watch.service --since "1 day ago" --no-pager | tail -50

# 手動 SMART (megaraid 配下)
sudo smartctl -a -d megaraid,0 /dev/bus/0
sudo smartctl -a -d megaraid,1 /dev/bus/0
# ... 0〜7 (SAS×8)

# NVMe
sudo smartctl -a /dev/nvme0
sudo smartctl -a /dev/nvme1

# megaraid kernel ログ
sudo dmesg | grep -i megaraid | tail
10. Telegram 通知が来ない
# 全ホスト共通: telegram_send のテスト
echo "test from $(hostname)" | telegram_send --stdin

# bot token / chat_id 確認
cat /etc/telegram_send.conf

# 監視 unit から手動呼び出し
sudo systemctl start perc-watch.service        # R640
sudo systemctl start supermicro-watch.service  # maguro
sudo journalctl -u perc-watch.service -e --no-pager
クイック判定フロー
症状発生 ↓ ┌───────┴───────┐ │ どこから繋がらない? │ └───────┬───────┘ ↓ ┌──────┼──────┐ ↓ ↓ ↓ 外部 内部 内部 全部 LAN WG ダメ のみ のみ ↓ ↓ ↓ DNS/ nginx maguro RTX allow wg-quick 確認 確認 確認
関連ページ: 「障害・トラブル (id:19)」(過去の詳細記録) / 「運用 switch コマンド (id:313)」(apt update 系) / 「運用・保守 (id:858)」(日次/週次点検)