ネットワーク設計方針
// NETWORK DESIGN POLICY — 完成版 (2026-05-13 大改定後) / 最終更新: 2026-05-14
【2026-08-26 実機照合による現況】このページの構成図は設計を示すもので、稼働状態とは一致していない。
- hirame は撤去済み — 物理的に存在しない。 hirame 上の Collabora Online も消滅し、 Nextcloud のオフィス編集は現在利用できない
- maguro は停止中 — 本体 192.168.10.31 は応答せず IPMI (192.168.10.30) のみ生存。 Nextcloud / mikyun-portal / WireGuard / SM ストレージはすべて停止
- Mellanox 25G Fabric は全系統ダウン — R640 側 2 本とも DOWN で
173.0.0.xの IP 自体が未設定 - 稼働中の物理サーバーは R640 のみ — nginx (katuocloud.com) とメール (postfix/dovecot) は active。 docker コンテナは 0 個
- WAN は暫定構成 — OCN 固定IP を喪失し共有Wi-Fi 上流の二重NAT。 外部からの着信は全て不可。 VLAN40 は 192.168.41.0/24 へ改番
- LACP 合計 80 Gbps は未成立 — 実効 30 Gbps (Po30 20G + Po20 10G)。 R640-DATA2 が 1G ネゴのまま LACP から外れている
確定 Zero Trust + 用途別ネットワーク物理分離 + DMZ/プライベート役割分担 + 25G fabric メッシュ
設計目的
本構成は以下を同時に成立させる:
- Zero Trust 管理 (VLAN+ACL 多層防御)
- 顧客通信と管理通信の完全分離
- ストレージ高速同期 (LACP 20G × 4 + 25G fabric)
- 更新通信の強制制御 (VLAN50 → Proxy 経由)
- OS のルーティング暴走防止 (Default GW 一本化)
- 将来 DC 拡張可能 (三層構造 + Po70 で WG ingress 独立済)
最重要思想: VLAN だけで分離しない
VLAN は L2 の論理分離だが、 単独ではノードが間違えれば貫通する。 本設計では 用途ごとにネットワーク層を物理分離 し、 L3 / ACL / FW で多層に守る。
| 層 | 役割 | 性質 |
|---|---|---|
| MGMT (VLAN10) | 管理 | 閉域 / GW なし運用 (NUTのみ DATA経由) |
| DATA (VLAN20) | 顧客通信主回線 | 唯一の Default GW |
| STG (VLAN30) | サーバ内部ストレージ | 高速 / GW なし / DNS なし |
| UPDATE (VLAN50) | OS 更新 | 制限付き (Proxy のみ許可) |
| WG (VLAN70 NEW) | WireGuard ingress | maguro 専用 / Po70 LACP 20G |
| FABRIC (173.0.0.0/29) | クラスタバックボーン | 完全閉域 25G Mellanox メッシュ |
ネットワーク命名 (確定)
| 名前 | VLAN | サブネット | 用途 |
|---|---|---|---|
| MGMT | VLAN10 | 192.168.10.0/24 | 管理 / SSH / iDRAC / IPMI / UPS |
| DATA | VLAN20 | 192.168.20.0/24 | 顧客通信 / Default GW |
| STG | VLAN30 | 192.168.30.0/24 | R640 ⇄ maguro ストレージ (Po2/Po30) |
| UPD | VLAN50 | 192.168.50.0/24 | OS 更新専用 |
| WAN-LINK | VLAN60 | 192.168.60.0/24 | RTX1300 LAN3 ↔ 12XS |
| WG-PUBLIC | VLAN70 | 192.168.70.0/24 | WireGuard ingress (maguro) |
| FABRIC | 直結 (Mellanox 25G) | 173.0.0.0/29 + 173.0.0.16/30 | R640 / maguro / hirame / D-Link メッシュ |
三層ネットワーク構成
Internet
│
┌─────▼─────┐
│ RTX1300 │ Edge Router (MAP-E)
└─────┬─────┘
│
┌─────▼──────────────────┐
│ Cisco 3850-12XS │
│ CORE / L3 │
│ VLAN10/20/30/50/60/70 │
└──┬─────────────────┬───┘
│ │
┌──────▼──────┐ ┌─────▼─────────┐
│ 3850-48T │ │ Servers + WG │
│ ACCESS/OOB │ │ Po2/20/30/70 │
│ MGMT/UPDATE │ │ 80G LACP合計 │
└──────────────┘ └───────────────┘
セキュリティ原則 (絶対ルール)
// Default Gateway 原則
各サーバの Default GW は VLAN20 のみ
禁止: VLAN10 / VLAN30 / VLAN50 / VLAN70 / WG interface に GW
禁止: VLAN10 / VLAN30 / VLAN50 / VLAN70 / WG interface に GW
理由: Linux / Windows カーネルは metric / reverse path / auto route で出口を勝手に変える。 結果:
- ✗ 応答が別 IF から出る
- ✗ VPN セッション崩壊
- ✗ 二重出口で漏洩リスク
対策: 出口 = VLAN20 ONLY + FW で補強 + Policy routing で固定
// SSH ポリシー
| 経路 | SSH |
|---|---|
| VLAN10 (MGMT) | ✓ 許可 |
| WG 越し (顧客 / 運営) | ✓ 許可 |
| VLAN20 (DATA, 内部) | ▲ 限定 |
| Internet 直 (外部から) | ✗ 不可 |
// VLAN 役割詳細
VLAN10 — MGMT: 機器管理 / iDRAC / IPMI / UPS / OOB。 Internet へ直接出ない閉域管理 LAN。
VLAN20 — DATA: 唯一の 外部出口。 サーバの Default GW はこれ。 顧客サービス・WP・NC・Collabora の主トラフィック。
VLAN30 — STG: R640 ⇄ maguro のストレージ専用。 サーバのみ接続 / クライアント禁止 / GW なし / DNS なし。 LACP 20G ×2 (Po2 + Po30)。
VLAN50 — UPDATE: OS 更新専用。 ACL で「Proxy のみ許可」。 直接 Internet 接続禁止。
VLAN70 — WG-PUBLIC (NEW 2026-05-13): WireGuard ingress 専用。 maguro が一手に終端 (wg-clients UDP54024 / wg-customers 61001 / wg-storage 62001)。 Po70 LACP 20G。
更新通信フロー (VLAN50)
Server (R640 / maguro / hirame)
│
│ VLAN50 (UPDATE)
▼
12XS ACL (VLAN50 → Proxy のみ許可、 他VLAN 禁止)
│
▼
Proxy (R640 or 外部)
│
▼
VLAN20 (Default GW)
│
▼
RTX1300 → Internet
制御内容: XS ACL で VLAN50 → Proxy のみ許可、 サーバ FW で UPD IF → 外部直接通信 DROP。 これで OS が誤って自動 metric で VLAN50 から外に出るのを防ぐ。
DMZ / プライベート役割分担 (2026-05-14 改定後)
| レイヤ | ホスト | 外部到達 | サービス |
|---|---|---|---|
| DMZ Front | R640 (katuo) | TCP443 (katuocloud.com) のみ | nginx stream SNI router + WP |
| Secure Storage | maguro | cloud.k2-o.net 経由 (SNI passthrough) + WG UDP×3 | Nextcloud / mikyun-portal / WG |
| Office Layer | hirame | 無し (fabric 直結のみ) | Collabora (Docker) |
2026-05-14 改定: 旧構成 (R640 が WG / NC / Portal を全部抱える) から、 R640 = DMZ 専用 + maguro = プライベート全部に分離。 R640 が万一侵入されても WG 鍵・NC データ・Portal は影響受けない。
FABRIC ネットワーク (DC 設計)
R640 / maguro / hirame の三角形を 25G Mellanox で完全メッシュ化。 GW なし / DNS なし / 完全閉域。
| サブネット | 接続 | 用途 |
|---|---|---|
| 173.0.0.0/30 | maguro(.1) ↔ R640(.2) | SNI passthrough + WP 移行時 rsync |
| 173.0.0.4/30 | maguro(.5) ↔ hirame(.6) | NC ⇄ Collabora WOPI (2026-05-14 直結化) |
| 173.0.0.8/30 | R640(.9) ↔ hirame(.10) | 予備 / クラスタ監視 |
| 173.0.0.16/30 | maguro(.17) ↔ D-Link 25G | 将来拡張 / 大容量バックアップ |
知見: NC ⇄ Collabora は元々 R640 SNI 経由で繋いでいたが、 ホップ数 3 + source IP 置換問題があった。 fabric 直結化により ホップ数 1 + remote_addr 正確 + 帯域 25G。 ただし内部 LAN ユーザーが cloud.k2-o.net を外部DNSで解決すると 192.168.30.21 (R640 SNI 出口) に見えるため、 nginx allow からこの IP を消すと内部ユーザー forbidden 発生。
R640 構成 (Control + DMZ)
| ポート | ネット | 役割 |
|---|---|---|
| eno3 (1G) | VLAN10 MGMT | SSH / iDRAC 隣接 |
| eno4 (1G) | VLAN50 UPDATE | apt 更新専用 |
| bond0 (10G×2) | VLAN20 DATA | Po20 / Default GW / 公開サービス |
| bond1 (10G×2) | VLAN30 STG | Po30 / NFS 等 |
| enp59s0 (25G) | Fabric 173.0.0.2/30 | maguro 直結 |
| enp59s0d1 (25G) | Fabric 173.0.0.9/30 | hirame 直結 |
ルーティング: Default GW = 192.168.20.1 (VLAN20) ONLY。
maguro 構成 (Storage + WG + Portal)
| ポート | ネット | 役割 |
|---|---|---|
| enp4s0f0 (1G) | VLAN10 MGMT | SSH 管理 |
| enp3s0f1 (1G) | VLAN50 UPDATE | apt |
| SM-STG bond (10G×2) | VLAN30 STG | Po2 / NC データ |
| SM-WG bond (10G×2) | VLAN70 WG (NEW) | Po70 / WireGuard ingress |
| enp129s0 (25G) | Fabric 173.0.0.1/30 | R640 直結 |
| enp129s0d1 (25G) | Fabric 173.0.0.5/30 | hirame 直結 |
| (別 25G) | Fabric 173.0.0.17/30 | D-Link 25G スイッチ |
Default GW: 192.168.20.1 (VLAN20 DATA 経由)。
hirame 構成 (Collabora)
| ポート | ネット | 役割 |
|---|---|---|
| (Cu 1G) | VLAN10 MGMT (192.168.10.40) | 管理 |
| (SFP+ 10G) | VLAN20 DATA (192.168.20.40) | Default GW |
| (SFP+ 10G) | VLAN50 UPDATE (192.168.50.40) | apt |
| (Mellanox 25G) | Fabric 173.0.0.6/30 | maguro 直結 (WOPI 経路) |
| (Mellanox 25G) | Fabric 173.0.0.10/30 | R640 直結 |
Collabora Docker は --add-host cloud.k2-o.net:173.0.0.5 で fabric 直結。 R640 SNI を経由しない。
なぜ GW を 1 本にする?
Linux / Windows は metric / reverse path / auto route で出口を勝手に変える性質がある。 結果、 応答が別 IF から出て VPN セッション崩壊 / NAT 不整合 / 監視盲点が発生する。
解決:
- 出口 = VLAN20 ONLY
- FW で他 IF からの外向き DROP
- Policy routing で固定
- 監視で「想定外 IF からの外向き通信」を検知
設計レベル評価
| 項目 | 状態 |
|---|---|
| Zero Trust | ✓ |
| DC 三層 (Edge / Core / Access) | ✓ |
| Storage Fabric | ✓ (25G ×3 メッシュ) |
| WG ingress 独立 (VLAN70) | ✓ (2026-05-13) |
| Update Segmentation | ✓ |
| DMZ / プライベート分離 | ✓ (2026-05-14 完遂) |
| 監視 (Telegram 全ホスト) | ✓ |
| Ceph Ready | ▲ (fabric は準備済、 ノード未追加) |
| Fail2ban | ! 未実装 |
過去の試行錯誤メモ (記録として)
- NFS チューニング (2026-05-04): 旧
173.0.0.1:/srv/storage/nextcloud/backup nfs defaults,_netdev→ 新nfs vers=4.1,nconnect=8,hard,noatime,nocto,nodiratime,rsize=1048576,wsize=1048576,_netdev。 ベンチ: NFSv3 151MB/s → NFSv4.1 156MB/s (5400RPM 物理上限)。 バックアップ:/etc/fstab.bak.20260504_183127 - DarkHero WG 無効化 + Static route (旧):
route -p add 192.168.20.21 mask 255.255.255.255 192.168.20.1 metric 1。 bmon 観測: bond0 (VLAN20) Avg 2.48 Gbps、 MGMT 6 kbit/s、 UPD 0 — 設計通り。 - R640 SNI passthrough の source IP 挙動: stream module は L4 で remote_addr が R640 VLAN30 IF (192.168.30.21) に置換。 内部 LAN も外部 DNS 経由だと同じ IP に見える。 nginx allow から消すと内部ユーザーが forbidden になるため要注意。
2026-05-14 時点での設計成熟度: 家庭ラボというより小規模 DC 設計レベル。 80Gbps LACP + 25G fabric メッシュ + Tier1 監視 + UPS 2-of-3 自動停止 + Zero Trust 多層防御。