ポート使用一覧と変更禁止ポート
// 最終更新: 2026-05-14 — R640 役割変更 (DMZ SNI router + WP) + maguro 移植反映、 全 3 ホスト網羅
CRITICAL 印のポートは絶対に変更しないこと。 既存顧客 (数百台) + 自動化スクリプト + RTX NAT に直接影響する。
R640 (DMZ + WordPress) 使用ポート
| Port | Proto | サービス | 用途 | 変更可否 |
|---|---|---|---|---|
| 22 | TCP | SSH | 管理アクセス | CRITICAL 自動化前提 |
| 80 | TCP | nginx | ACME challenge + HTTPS redirect | CRITICAL Let’s Encrypt 必須 |
| 443 | TCP | nginx stream | SNI 振り分け (cloud.k2-o.net + katuocloud.com) | CRITICAL 公開フロント |
| 8443 | TCP | nginx (inner) | katuocloud.com WP の内部 HTTPS 終端 (127.0.0.1 のみ) | 変更可 (但し SNI router の upstream も同時変更) |
| 3306 | TCP | MariaDB | katuocloud_wp DB (127.0.0.1 のみ) | 変更可 (但し wp-config + backup script 同時変更) |
| 9000 | TCP | php-fpm | WP の PHP 処理 | 変更可 |
maguro (Nextcloud + Portal + WG) 使用ポート
| Port | Proto | サービス | 用途 | 変更可否 |
|---|---|---|---|---|
| 22 | TCP | SSH | 管理 | CRITICAL |
| 443 | TCP | nginx | cloud.k2-o.net (NC) 終端 | CRITICAL |
| 9000 | TCP | mikyun-cloud | 運営ポータル API (Docker host network) | CRITICAL 自動化スクリプト依存 |
| 9081 | TCP | mikyun-vpn-engine | VPN 管理 Engine (Docker host network) | CRITICAL |
| 54024 | UDP | wg-clients | 顧客 VPN 終端 (10.200.0.0/16) | CRITICAL 数百台の顧客設定に影響 |
| 61001 | UDP | wg-customers | 業務カスタマー (10.251.0.0/24) | CRITICAL |
| 62001 | UDP | wg-storage | ストレージ用 (10.220.0.0/24) | CRITICAL |
| 3306 | TCP | Docker MariaDB (compose-db-1) | NC + mikyun_cloud DB (127.0.0.1) | 変更可 (要全関連設定更新) |
| 2049 | TCP | NFS | fabric 経由のストレージ共有 | 標準推奨、 変更非推奨 |
| 53 | UDP/TCP | dnsmasq | WG クライアント向け内部 DNS | 標準推奨 |
| 55413-55415, 35623 | TCP/UDP | UrBackup | FastCGI / WebUI / client data / UDP discovery | 変更可 (各 UrBackup クライアント設定同時更新) |
hirame (Collabora Online) 使用ポート
| Port | Proto | サービス | 用途 | 変更可否 |
|---|---|---|---|---|
| 22 | TCP | SSH | 管理 | CRITICAL |
| 9980 | TCP | Collabora (coolwsd) | WOPI + cool WebSocket | CRITICAL NC 設定 + nginx proxy upstream に影響 |
RTX1300 (公開エッジ) NAT 一覧
| ID | 外部 | 内部 | 用途 | 変更可否 |
|---|---|---|---|---|
| 20000/10 | UDP 54024 | 192.168.70.30:54024 | wg-clients (maguro) | CRITICAL |
| 20000/11 | TCP 443 | 192.168.20.21:443 | R640 nginx SNI | CRITICAL |
| 20000/12 | TCP 80 | 192.168.20.21:80 | R640 nginx (ACME) | CRITICAL |
| 20000/13 | UDP 61001 | 192.168.70.30:61001 | wg-customers | CRITICAL |
| 20000/14 | UDP 62001 | 192.168.30.30:62001 | wg-storage | CRITICAL |
現在使用中のポートを確認
# maguro / R640 / hirame それぞれで実行
ss -tlnp | grep LISTEN # TCP LISTEN
ss -ulnp # UDP LISTEN
wg show all | grep "listening port" # WireGuard
lsof -i :<port> # 特定ポートのプロセス
# Docker container の port
docker ps --format 'table {{.Names}}\t{{.Ports}}'
ポート変更時のチェックリスト
絶対に確認:
- このページの「CRITICAL」 印が無いことを確認
- バックアップを取った (systemd unit / nginx config / .env / wg conf / iptables / RTX NAT)
- 変更が必要な全ファイルをリストアップ (systemd, nginx, .env, WireGuard, iptables, RTX NAT)
- 変更手順を文書化 (どのファイル → どのサービス再起動 → どう確認 → ロールバック)
- メンテナンス時間を確保 (営業時間外、 顧客事前通知)
よくある失敗例
❌ ダメな例 1: 「ポート9000が使われてるから9001に変えよう」
→ nginx の upstream + systemd unit + mikyun-portal の .env + Docker compose の portsマッピング を全部変更しないと、 運営ポータルにアクセスできなくなる。
→ nginx の upstream + systemd unit + mikyun-portal の .env + Docker compose の portsマッピング を全部変更しないと、 運営ポータルにアクセスできなくなる。
❌ ダメな例 2: 「SSH (22番) がスキャンされてるから22222に変えよう」
→ Ansible、 自動デプロイ、 全自動化スクリプト (rsync, scp, git push 経由) が動かなくなる。 変更するなら、 すべての自動化スクリプト + RTX側のフィルタ設定も修正が必要。
→ Ansible、 自動デプロイ、 全自動化スクリプト (rsync, scp, git push 経由) が動かなくなる。 変更するなら、 すべての自動化スクリプト + RTX側のフィルタ設定も修正が必要。
❌ ダメな例 3: 「WireGuardの 54024 を変えよう」
→ 既存の全顧客 (数百台) が接続できなくなる。 全顧客に新しい設定ファイル + QR を再配布する必要。 mikyun-portal の API + add_customer_full.sh + RTX NAT も同時変更。
→ 既存の全顧客 (数百台) が接続できなくなる。 全顧客に新しい設定ファイル + QR を再配布する必要。 mikyun-portal の API + add_customer_full.sh + RTX NAT も同時変更。
緊急時の対応
// 誤ってポートを変更してしまった場合
# 1. バックアップから復元 sudo cp /root/backup/<service>.backup.YYYYMMDD_HHMMSS /etc/systemd/system/<service> # 2. systemd reload sudo systemctl daemon-reload # 3. サービス再起動 sudo systemctl restart <service> # 4. 動作確認 sudo systemctl status <service> curl http://127.0.0.1:<port>/health
// サービスが起動しない場合
# ログでエラーを確認 sudo journalctl -u <service> -n 100 --no-pager # Docker container の場合 sudo docker logs <container> --tail 100
設計判断・教訓 (温存)
- SSH 22 を変更しなかった理由: R640 / maguro / hirame の3ノード間 + 内部自動化が ssh コマンド前提。 ポート変更によるリスク (鍵分散、 Ansible 動作不可、 自動デプロイ停止) が攻撃面の縮小効果を上回る。 代わりに fail2ban + IP制限 (内部VLAN+WG経由のみ許可) で守る方針。
- WG 54024 を保持する理由: 既存顧客の conf を書き換えるコストが膨大。 RTX NAT で外側のポートだけ変えるアプローチも検討したが、 顧客側 conf の Endpoint も書き換え必要なので結局同じ。
- 9000 + 9081 を分けた理由: mikyun-cloud (UI) と mikyun-vpn-engine (VPN管理) を プロセス分離。 障害切り分けと再起動独立性のため。
- WG 顧客VPN を maguro に集約した理由 (Phase 2): R640 を DMZ 公開フロントに転換するため、 WG 機能を R640 から剥がした。 物理的に役割分離。