ネットワークのブラッシュアップ

また現在の構成をよく表しているのが、
https://wanchance.com/infra/
https://wanchance.com/ip-daichou/
である
この表にないものとして
darkheroZ790からVLAN20で192.168.20.10がXS-12の4番portに追加されています。またdarkheroZ790のファブリックR640とのQSFP+は廃止されました。

新しくメディアserverとしてhiramePCが追加されました現在はVLAN10192.168.10.40とR640とのファブリック接続のみです。

ネットワーク機器検査レポート - みーきゅんクラウド

🔍 ネットワーク機器 検査レポート

みーきゅんクラウド インフラ — SSH接続による設定・障害診断

検査日時:2026年3月26日
対象機器:3台
WS-C3850-12XS:192.168.10.1
WS-C3850-48T:192.168.10.2
RTX1300:192.168.10.254

📊 エグゼクティブサマリー

5
高優先度問題
6
中優先度問題
4
低優先度問題
2
対応済み
  • 🔴
    【高】Ciscoスイッチ全体で大量のoutput drops — 通信速度低下の直接原因
    12XS の複数ポートで数千万〜1億超のパケットドロップ。RTX1300方向27M、WiFi方向80M、SMストレージ方向95M など。
  • 🔴
    【高】Te2/0/9 (SM_STORAGE_LACP) が suspended — ストレージ帯域50%喪失
    Po2 (SMストレージ LACP) の片側メンバーが suspended。94M出力ドロップ+1億3800万 PAUSE frames。
  • 🔴
    【高】Po30 (R640-STG-BOND) で PAUSE frames が 42億超 — カウンタオーバーフロー
    R640ストレージポートからのEthernet PAUSE frameが異常多発。フロー制御が連続発動しているためストレージ通信が断続的に停止。
  • 🔴
    【高】48T: Gi1/0/1 (RTX1300-OOB) に281M output drops + 頻繁なリンクフラップ
    3月24日に約1分間隔でup/downを繰り返す。OOB管理通信の信頼性が著しく低下。
  • 【対応済】RTX1300 再起動後にNextcloud NATポートフォワードが消失 → 復旧完了
    config-main.txt適用後にWireGuard(UDP:54024)/HTTPS/HTTP の静的NATが消えていた。今回の検査中に即時修復・save済み。
  • 【対応済】RTX1300 LAN1/LAN3 同一IPで1G回線のみ使用 → rebootで10G切替完了
    再起動前はLAN1(1G)・LAN3(10G)が同じIPを持ち1Gのみ使用。reboot後はLAN3(10G)が正しく内部GWに。
  • 🟡
    【中】両Ciscoスイッチで NTP 未設定
    %NTP is not enabled. ログのタイムスタンプが不正確で障害調査が困難。
  • 🟡
    【中】RTX1300: MAP-E アドレス解決サーバへの通知が毎時間失敗
    "Not response from the address resolution server." ログが2026/03/06から継続記録。WAN疎通自体は正常だが監視が必要。
  • 🟡
    【中】IOS-XE バージョン不一致 (12XS: 03.07.05E / 48T: 03.06.07E)
    どちらも2017年リリース。セキュリティパッチ・バグフィックスが未適用の可能性。統一アップデートを推奨。
  • 🟡
    【中】VLAN40 の STP priority が未明示設定 (32768 vs 他VLANは 4096)
    VLAN10/20/30/50はpriority 4096が明示設定だがVLAN40だけデフォルト32768。今は問題ないが将来のトポロジ変化でrootが変わるリスク。
  • 🟡
    【中】48T: Gi1/0/13 (MAIN_PC_Z790), Gi1/0/15 (R640-MGMT) 等でリンクフラップ
    Mar 22〜24 にかけて複数ポートで断続的なup/down。ケーブル品質またはNIC側の問題が疑われる。
  • 🔵
    【低】Logging level debugging 設定 — 実エラーがSSHデバッグログに埋もれる
    12XS のログバッファがSSH MAC計算ログで埋まっており実障害の検知が困難。informational に変更推奨。
  • 🔵
    【低】RTX1300: 冗長・矛盾フィルターエントリ
    400212は400202と重複(WAN_PC outbound)。存在しない192.168.100.0/24向けfilter(400003,400030-037)が残存。
  • 🔵
    【低】Te2/0/2 (DARKHERO_WAN) notconnect — 2本中1本のみ使用
    DarkHeroへの10G接続は1本のみ使用中。冗長性なし。

🗺️ ネットワーク全体構成図

🌐 インターネット OCN MAP-E (IPv4/IPv6) RTX1300 YAMAHA WANエッジルーター GW: 192.168.10.254 | LAN3(10G)→12XS | LAN2(WAN) MAP-E/10G WS-C3850-12XS Cisco コアL3スイッチ (VLAN GW) 192.168.10.1 | IOS-XE 03.07.05E | 16x10GbE 10G (LAN3) Te2/0/1 WS-C3850-48T Cisco アクセス・OOBスイッチ 192.168.10.2 | IOS-XE 03.06.07E | 48GbE+4x10G Po1 20G LACP 💻 DarkHero 192.168.40.x WAN_PC VLAN40 🖥️ Nextcloud PC 192.168.20.21 DATA VLAN20 / 10G 🖥️ Dell R640 DATA: Po20 (2x10G) STG: Po30 (2x10G) 🗄️ Supermicro ⚠️ Po2 片側 SUSPEND STORAGE VLAN30 📡 WiFi Router 192.168.40.x WAN_PC VLAN40/10G Te2/0/3 10G Te2/0/4 10G Po20+Po30 ⚠️ Po2(1本) Te2/0/12 10G 🔧 OOB管理 (VLAN10) — 48T経由 RTX1300-OOB / XS12-OOB / R640-iDRAC / SM-OOB MAIN_PC_MGMT / UPS1-3 / R640-MGMT / SM-MGMT ⚠️ Gi1/0/1 281M drops / リンクフラップ多発 凡例 10G 正常リンク LACP ポートチャネル ⚠️ 問題あり接続 1G 接続 WAN / OOB (論理)
🔀

WS-C3850-12XS — コア L3 スイッチ

192.168.10.1 | IOS-XE 03.07.05E | 16x 10GbE | 稼働: 4週3日17時間

問題あり

📌 ポート配線図

WS-C3850-12XS — ポート配線図 Te2/0/1 RTX1300 VLAN10 27M drops⚠ Te2/0/2 DarkHero VLAN40 notconnect Te2/0/3 DarkHero VLAN40 7.6M drops Te2/0/4 Nextcloud VLAN20 0 drops ✓ Te2/0/5 R640 DATA Po20 VLAN20 23.6M drops⚠ Te2/0/6 R640 DATA Po20 VLAN20 1.8M drops Te2/0/7 R640 STG Po30 VLAN30 7.5M drops Te2/0/8 R640 STG Po30 VLAN30 47.6M drops⚠ Te2/0/9 SM STG ⚠️SUSPENDED 94.7M drops! Te2/0/10 SM STG Po2 VLAN30 0 drops ✓ Te2/0/11 未使用 VLAN1 notconnect Te2/0/12 WiFi Router VLAN40 80.2M drops! Te2/1/1 notconnect Te2/1/2 notconnect Te2/1/3 UPLINK_A→48T Po1 / 10G Te2/1/4 UPLINK_B→48T Po1 / 10G Po1 (20G LACP) → 48T CORE_TO_ACCESS 0 drops ✓ Po2 (10G LACP) SM_STORAGE (1本のみ) 84.9M drops ⚠️ Po20 (20G LACP) R640-DATA-BOND 25.4M drops ⚠️ Po30 (20G LACP) R640-STG-BOND ⚠️ PAUSE frames: 42億超 (オーバーフロー!) VLAN構成 VLAN10: MGMT/DATA_10G (GW: .10.1) VLAN20: DATA (GW: .20.1) | VLAN30: STORAGE (GW: .30.1) VLAN40: WAN_PC (GW: .40.1) | VLAN50: UPDATE (GW: .50.1) | VLAN999: Native ⚠️ NTP未設定 ⚠️ VLAN40 STP priority未明示 STP Root: 12XS (VLAN10/20/30/40/50)

📋 インターフェース エラーカウンター詳細

ポート接続先VLAN/役割状態Output DropsPause InputCRC/Frame
Te2/0/1RTX1300 LAN3VLAN10connected 10G27,288,209 ⚠️00
Te2/0/2DarkHero WANVLAN40notconnect000
Te2/0/3DarkHero WANVLAN40connected 10G7,614,6786,618,3520
Te2/0/4Nextcloud PCVLAN20connected 10G000
Te2/0/5R640 DATA (Po20)VLAN20connected 10G23,655,269 ⚠️685,2130
Te2/0/6R640 DATA (Po20)VLAN20connected 10G1,792,199175,1440
Te2/0/7R640 STG (Po30)VLAN30connected 10G7,456,4164,1610
Te2/0/8R640 STG (Po30)VLAN30connected 10G47,626,224 ⚠️00
Te2/0/9SM STG (Po2)VLAN30⚠️ SUSPENDED94,735,344 ⚠️138,158,681 ⚠️0
Te2/0/10SM STG (Po2)VLAN30connected 10G000
Te2/0/11VLAN1notconnect000
Te2/0/12WiFi RouterVLAN40connected 10G80,207,641 ⚠️26,338,486 ⚠️0
Po148T (LACP 20G)trunkconnected000
Po2SM StorageVLAN301本のみ84,883,524 ⚠️11,512,7020
Po20R640 DATAVLAN20connected25,447,468 ⚠️860,3570
Po30R640 STGVLAN30connected7,456,4164,294,963,347 🔴オーバーフロー0

🔒 ACL検査結果

  • MGMT_ONLY: 192.168.10.0/24のみSSH許可 — 適切
  • VLAN20/30/40/50 のセグメント間分離ACL — 適切に設定
  • VLAN50_EGRESS: UPDATEセグメントはプロキシ経由のみ許可 — 適切
  • 🟡
    VLAN50_EGRESS rule 90: deny ip any any — 65,528 matches (UPDATEからの外部直接通信が大量にブロック)
    プロキシ設定が正しく機能しているか確認推奨。頻繁なdenyはプロキシ経由が機能していない可能性。
  • 🔵
    AutoQos ACL群 — 自動生成エントリ、実運用に影響なし

⚙️ STP・NTP状態

VLANSTP RolePriorityTCN回数最終変化
VLAN10Root410623週3日前
VLAN20Root411652日5時間前
VLAN30Root412652日5時間前
VLAN40Root32808 ⚠️31日1時間前
VLAN50Root414623週1日前
VLAN999非Root3376713週3日前
NTP状態
未設定
%NTP is not enabled. — ログのタイムスタンプが不正確

CPU使用率 (5分平均)
7%
正常範囲内

メモリ使用率
41%
1.6GB / 3.9GB — 正常
🔌

WS-C3850-48T — アクセス・OOBスイッチ

192.168.10.2 | IOS-XE 03.06.07E | 48x GbE + 4x 10GbE | 稼働: 4週3日18時間

要確認

📌 ポート配線図

WS-C3850-48T — ポート配線図 (VLAN10 MGMT / OOB) Gi1/0/1 RTX1300-OOB VLAN10 1G 281M drops! Gi1/0/2 RESERVED VLAN10 Gi1/0/3 XS12-OOB VLAN10 1G 0 drops ✓ Gi1/0/4 RESERVED Gi1/0/5 48T-OOB VLAN10 1G Gi1/0/6 RESERVED Gi1/0/7 R640-iDRAC VLAN10 1G Gi1/0/8 RESERVED Gi1/0/9 SM-OOB VLAN10 1G Gi1/0/10 RESERVED Gi1/0/11 DarkHero MGMT notconnect Gi1/0/12 RESERVED Gi1/0/13 MAIN_PC ⚠️ フラップ多 Gi1/0/14 RESERVED Gi1/0/15 R640-MGMT ⚠️ フラップ多 Gi1/0/17 SM-MGMT VLAN10 1G Gi1/0/19 SM-MGMT#2 ⚠️ フラップ多 Gi1/0/25 R640-UPD VLAN50 Gi1/0/27 SM-UPD VLAN50 Gi1/0/37 UPS1-MGMT 100M Gi1/0/39 UPS2-MGMT 100M Gi1/0/41 UPS3-MGMT 100M Gi1/0/30〜36, 38, 40, 42〜48: UNUSED_SHUTDOWN (disabled) ✓ 適切に閉塞済み Gi1/1/1, Gi1/1/2: disabled (VLAN999) Te1/1/3 + Te1/1/4 Po1 → 12XS (20G LACP) STP VLAN999: Root VLAN10/50: Root Port (Po1) ⚠️ ログ検出: リンクフラップ履歴 (Mar 22〜25) Gi1/0/1 (RTX1300-OOB): Mar 24 18:40〜22:07 — 約1分毎にup/down × 6回以上 | Gi1/0/13 (MAIN_PC): Mar 22, 24 — 複数回 Gi1/0/15 (R640-MGMT): Mar 23 — 複数回 | Gi1/0/19 (SM-MGMT): Mar 23 — 複数回 | Gi1/0/25 (R640-UPD): Mar 23 — 連動フラップ

📊 重要指標

Gi1/0/1 output drops
281M
RTX1300-OOBポートへの大量ドロップ
リンクフラップ発生ポート
5本
Gi1/0/1, 13, 15, 19, 25 (過去4日間)
NTP状態
未設定
%NTP is not enabled.
🛡️

RTX1300 — YAMAHA WANエッジルーター

192.168.10.254 | Rev.23.00.16 | 8LAN | 起動時刻: 2026/03/26 14:11

要確認

🌐 インターフェース構成

IFアドレス速度状態用途
LAN1192.168.100.1/241G (PORT1のみ)Up旧管理/未使用セグ
LAN2DHCP (WAN)10GUpOCN インターネット
LAN3192.168.10.254/2410G (PORT10)Up ✅内部GW (12XS接続)
TUNNEL1114.164.250.167MAP-EUpWAN IPv4カプセル

📡 ルーティングテーブル

宛先ゲートウェイIF種別
0.0.0.0/0TUNNEL[1]static
192.168.10.0/24192.168.10.254LAN3implicit
192.168.20.0/24192.168.10.1LAN3static
192.168.30.0/24192.168.10.1LAN3static
192.168.40.0/24192.168.10.1LAN3static
192.168.50.0/24192.168.10.1LAN3static

🔒 フィルター・NAT検査

  • 【対応済】Nextcloud NATポートフォワード (UDP:54024 / TCP:443 / TCP:80) — 本検査中に復旧
    config-main.txtにstatic NATエントリが欠如していたため追加。sd1:/config-main.txtに保存済み。
  • WAN inbound: プライベートアドレス詐称 (400000-002) 拒否 — 適切
  • NetBIOS/SMB (135, 445, NetBIOS) 拒否 (400020-025) — 適切
  • WAN outbound: MGMT/UPDATE/WAN_PCセグメントのみ許可 — セグメント制御適切
  • 🟡
    MAP-E address resolution server 通知失敗ログ — 2026/03/06から毎時間記録
    "Not response from the address resolution server." — WAN疎通は正常だが、OCN側のサーバ応答なし。ISP側の仕様変更の可能性あり。
  • 🔵
    ip filter 400212 が 400202 と重複 (両方 pass 192.168.40.0/24)
    機能上の問題はないが不要エントリ。削除推奨。
  • 🔵
    192.168.100.0/24向けフィルター群 (400003, 400030-037) が残存
    現在LAN1が192.168.100.1/24になったため一部は有効だが、tunnelのinboundに含まれる400003は不要ロジック。整理推奨。

⚙️ リソース状況

CPU使用率
0〜1%
非常に低負荷
メモリ使用率
31%
正常範囲
NATセッション数
172
再起動後。上限250,000/host

🚨 通信速度低下 — 根本原因分析

原因① 出力キュー枯渇 (Output Queue Drop)

最大の問題。スイッチの出力バッファが満杯になりパケットを廃棄している状態。CRC/フレームエラーは0件のため物理層の問題ではなく、受信側の処理能力を超えたトラフィックが送信されていることが原因。

ポート接続先Output Drops主因
Te2/0/12WiFi Router80,207,641WiFiルーターがパケット処理しきれない / フロー制御未設定
Po2SM Storage (1本)84,883,524Te2/0/9 suspend により実効帯域50%減少
Te2/0/9SM STG (suspended)94,735,344LACP片側断 → Po2に集中 → overload
Te2/0/8R640 STG47,626,224R640からの大量PAUSE frame → バッファ圧迫
Te2/0/1RTX1300 LAN327,288,209reboot前は1G経由→ 現在は10G改善済
Gi1/0/1 (48T)RTX1300-OOB281,690,858OOBポートへのトラフィック集中 + リンクフラップ

原因② Ethernet PAUSE Frame 異常多発

接続先デバイスがバッファ満杯を通知するPAUSE frameを大量送信。スイッチ側が送信を停止し、実効帯域が大幅に低下。

ポートPAUSE Input 件数意味
Po30 (R640-STG)4,294,963,347 (カウンタオーバーフロー🔴)R640のストレージ側NICが限界を超えて連続PAUSE送信
Te2/0/9 (SM SUSP)138,158,681suspended前に大量受信。SMが1本に過負荷状態だった
Te2/0/12 (WiFi)26,338,486WiFiルーターが処理しきれず頻繁にPAUSE送信
Po2 (SM STG)11,512,702SMストレージからのPAUSE

原因③ Te2/0/9 (SM_STORAGE_LACP) suspended による帯域半減

  • 🔴
    Po2 (SMストレージ LACP) の片側ポートが suspended 状態
    本来 20Gbps (2×10G) の帯域が 10Gbps に低下。LACPネゴシエーション失敗の可能性。SM側のbondingデバイス設定またはケーブルの確認が必要。
    確認コマンド: show etherchannel 2 detail

原因④ RTX1300 LAN1/LAN3 IP重複 (reboot前) — 対応済

  • reboot前: LAN1(1G)・LAN3(10G)が同じ192.168.10.254/24を持ち1G経由でルーティングされていた
    reboot後は LAN3(10G) のみ 192.168.10.254/24。LAN3の送信パケット数が 5 → 145,000+ に増加。内部⇄WAN間の実効帯域が大幅改善。

📋 改善アクション一覧(優先度順)

優先度対象機器問題推奨アクション効果
🔴 高 12XS Te2/0/9 suspended (Po2片側断) SMストレージ側bonding設定確認・ケーブル再挿し・LACP再ネゴシエーション SMストレージ帯域を20Gに回復 / ドロップ解消
🔴 高 12XS Po30 PAUSE frames オーバーフロー R640ストレージNICのフロー制御設定確認・OS側でPAUSE制御を調整 ストレージ転送速度安定化
🔴 高 12XS Te2/0/12 WiFi Router 80M drops WiFiルーター側の受信バッファ設定確認・接続先をGbEに変更検討・QoS設定 WiFiトラフィック安定化
🔴 高 48T Gi1/0/1 リンクフラップ + 281M drops RTX1300-OOBポート (LAN1 PORT1) のケーブル交換・ポート変更 OOB管理の安定化
🟡 中 12XS / 48T NTP未設定 NTPサーバ設定を追加 (RTX1300を参照元に推奨) ログタイムスタンプ正確化・障害調査改善
🟡 中 12XS VLAN40 STP priority未設定 spanning-tree vlan 40 priority 4096 を追加 STP安定性向上
🟡 中 12XS logging level debugging no logging buffered debugginglogging buffered informational 実エラーの検知精度向上
🟡 中 48T リンクフラップポート (Gi1/0/13, 15, 19) ケーブル交換・NIC確認。再発するなら errdisable recovery + carrier-delay 設定 管理通信安定化
🟡 中 12XS / 48T IOS-XE バージョン古い 03.07.05E → 最新版へアップデート (メンテウィンドウで実施) セキュリティ・バグ修正
🔵 低 RTX1300 冗長フィルター (400212重複等) 不要フィルターを整理・削除 設定の可読性向上
🔵 低 12XS Te2/0/2 notconnect (DarkHero 2本目) 未使用ならshutdown設定推奨 設定明確化
みーきゅんクラウド ネットワーク検査レポート — 2026年3月26日 | Claude Code により自動生成
🔧 VLAN60新設・ネットワーク大規模再設計 計画書
作成日: 2026-03-27 | 作成者: みーきゅんわんわん + Claude | ステータス: 計画確定・実施待ち
1. 背景と目的
1-1. 現状の問題

現在のネットワーク設計では、RTX1300がVLAN10(MGMT: 192.168.10.0/24)経由でNATを行っている。この設計により以下の問題が発生している。

問題詳細
重大 VLAN10が外部と接触MGMT用のVLAN10がRTX1300経由でインターネットに接続可能な状態。管理系機器が意図せず外部に露出するリスクがある。
重大 IPv6 RAの制御不能RTX1300からのIPv6 RA(Router Advertisement)がVLAN10に流入し、VLAN10上の全機器にグローバルIPv6アドレスが付与される。R640にグローバルIPv6が付いた原因。
重大 外部アクセス制御の分散12XSのACLで外部アクセス制御を実施しているが、本来はWAN境界(RTX1300)またはアクセス層(48T)で実施すべき。役割分担が不明確。
Squid依存の脆弱性R640上のSquidでVLAN50の外部通信をフィルタリングしているが、R640に過度な役割集中。設定ミスやSquid障害時に全VLAN50通信が停止するリスク。
ブラウザ制御の限界Chrome等の個別アプリにProxy設定をしても、他のプロセス(curl、wget、pip等)は制御できない。ネットワーク層での制御が本質的解決。
1-2. 再設計の目的
#目的達成方法
1VLAN10の完全閉域化RTX1300との接続をVLAN60(新設)に変更し、VLAN10を外部から完全遮断
2IPv6のVLAN単位制御IPv6 RAはVLAN60にのみ流入させ、VLAN40とWGのみIPv6許可
3役割の明確化WAN境界フィルタはRTX1300、アクセス層フィルタは48T、L3ルーティングは12XS
4Squid廃止48TのACLでVLAN50のフィルタリングを実施。R640の役割集中を解消
5シンプルな設計12XSの外部向けACLを削除。各装置が本来の役割のみを担当
2. 新ネットワーク設計
2-1. トポロジー図
┌──────────────┐ │ インターネット │ │ (IPv4/IPv6) │ └──────┬───────┘ │ ┌──────┴───────┐ │ RTX1300 │ │ WAN edge │ │ NAT/Filter │ │ LAN3→VLAN60 │ └──────┬───────┘ │ VLAN60 (192.168.60.0/24) │ ★ NATはここだけ │ ★ IPv6 RAはここにのみ流入 ┌──────┴───────┐ │ Cisco 3850 │ │ 12XS (Core) │ │ L3 Routing │ │ VLAN間分離 │ └──┬───┬───┬───┘ │ │ │ ┌────────────┤ │ ├────────────┐ │ │ │ │ VLAN40 │ VLAN50 │ │ VLAN20 VLAN30 (DH) │ (UPDATE)│ │ (DATA/WG) (STORAGE) │ │ │ │ ┌───────┴──┐ ┌──────┴───┴──┐ ┌─────┴─────┐ │DarkHero │ │ R640 │ │Supermicro │ │自作PC │ │ サーバー │ │SSG6048R │ │制限なし │ │ WG/Portal │ │NFS/約90TB │ └──────────┘ └──────────────┘ └───────────┘ │ ┌──────┴───────┐ │ Cisco 3850 │ │ 48T (Access) │ │ VLAN50 ACL │ │ VLAN10完結 │ └──────┬───────┘ │ VLAN10 (MGMT) ★ 外部接続なし ★ 48T内で完結 ★ IPv6なし
2-2. VLAN設計一覧
VLAN名称サブネット外部接続IPv6GW備考
10MGMT192.168.10.0/24不可不可48T内完結管理用。完全閉域。48Tから外に出さない
20DATA / WG192.168.20.0/24WGのみ許可12XSWG接続クライアントのみ外部アクセス可
30STORAGE192.168.30.0/24不可不可なしNFS/内部ストレージ専用。完全閉域
40DarkHero192.168.40.0/24制限なし許可12XS→VLAN60→RTX唯一のフルアクセスVLAN
50UPDATE192.168.50.0/24ACL制限不可12XS→VLAN60→RTX48TのACLでフィルタ。許可先のみ
60WAN-LINK192.168.60.0/24★ RTX接続専用RA受信RTX1300新設。RTX↔12XS間トランク
999NATIVEトランクNative(未使用VLAN)
2-3. IPv6ポリシー
VLANIPv6理由
VLAN60 (WAN-LINK)RA受信RTX1300からのIPv6 RAはここにのみ到達
VLAN40 (DarkHero)許可12XSがVLAN60のIPv6をVLAN40にルーティング
VLAN20 (WG)許可WGクライアント向けにIPv6提供
VLAN10/30/50不可12XSでIPv6ルーティング対象外。RA到達不可
2-4. IPアドレス台帳(VLAN60 新設分)
機器VLAN60 IP役割
RTX1300 LAN3192.168.60.1VLAN60 GW / NAT / WAN境界
12XS SVI192.168.60.2VLAN60側 L3ルーティング
※ VLAN60にはRTX1300と12XSの2台のみ。他の機器は接続しない。
3. 各装置の役割分担
装置役割詳細
RTX1300 WAN境界
NAT
フィルター
・インターネット接続の唯一の出入口
・NATをVLAN60経由で実施(現VLAN10から変更)
・VLAN40/50のみWAN通過許可(VLAN10/20/30は遮断)
・VLAN20はWGクライアントの戻りパケットのみ許可
・IPv6 RAをVLAN60にのみ配信
12XS L3ルーティング
VLAN間分離
・VLAN間ルーティング(default route → VLAN60 192.168.60.1)
・VLAN30(STORAGE)への到達制御
・IPv6ルーティング:VLAN40/20のみ許可
・外部向けACLは持たない(RTX1300に委譲)
48T アクセス層
VLAN50フィルタ
VLAN10完結
・VLAN10をこのスイッチ内で完結させる(外に出さない)
・VLAN50のACL(現VLAN10 ACLを転用)でフィルタリング
・許可先IPアドレス/ポートのみ通過
R640 サーバー専任 ・WireGuard終端(wg0, wg-admin)
・Nextcloud / Portal / Docker
Squid廃止(フィルタリング役割から解放)
・デフォルトルートはVLAN20 GW経由→12XS→VLAN60→RTX
設計原則: スイッチは自発的な行動がないため設定が崩れない。フィルタリングはスイッチ/ルーターの本来の役割。R640に特殊設定(Squid等)を集中させると将来必ず事故る。
4. Before / After 比較
項目Before(現状)After(新設計)
RTX↔12XS接続VLAN10(192.168.10.254)VLAN60(192.168.60.0/24)新設
NATVLAN10経由VLAN60経由
VLAN10RTXに到達可能(外部接触あり)48T内完結(完全閉域)
IPv6 RAVLAN10に流入(制御不能)VLAN60のみ。40/20にルーティング
外部アクセス制御12XS ACL + R640 SquidRTX1300フィルタ + 48T ACL
VLAN50フィルタR640上のSquid(プロキシ)48TのACL(L2/IP層制御)
12XS ACLVLAN20/40/50の外部向けACL多数VLAN間分離のみ(外部向け削除)
DarkHero外部VLAN40→12XS→RTX(ACL経由)VLAN40→12XS→VLAN60→RTX(制限なし)
5. 実施手順(作業順序)
⚠️ 重要: この作業はネットワーク全体に影響する大規模変更です。メンテナンスウィンドウを設け、ロールバック手順を準備してから実施してください。全手順の所要時間目安: 3〜5時間。
Phase A: 事前準備(作業前日推奨)
#作業コマンド/詳細リスク
A1全装置の現行config保存 RTX1300: save /flash/backup-20260327.config
12XS: copy running-config flash:backup-20260327.cfg
48T: copy running-config flash:backup-20260327.cfg
R640: sudo cp /etc/netplan/*.yaml /root/backup-netplan/
なし
A2R640 Squid設定の記録 cp /etc/squid/squid.conf /root/backup-squid/
cp /etc/squid/allowed-domains.txt /root/backup-squid/
※ 廃止前の記録として保存
なし
A348T VLAN50 ACL許可リスト作成 Squidのallowed-domains.txtをIPアドレスに変換し、48TのACLに落とし込む準備。
dig +short ubuntu.com 等で主要ドメインのIP確認。
※ CDN利用サービスはIPレンジでの許可が必要
なし
A4ロールバック手順書の準備各Phaseのロールバックコマンドを事前に用意なし
Phase B: VLAN60新設(12XS + RTX1300)
#作業コマンド/詳細リスク
B112XSにVLAN60を作成
conf t
vlan 60
 name WAN-LINK
exit
interface vlan 60
 ip address 192.168.60.2 255.255.255.0
 no shutdown
exit
B212XS→RTX間ポートにVLAN60追加 RTX接続ポートをtrunkにしVLAN60を許可。
※ 既存VLAN10のtrunkも維持(Phase D完了まで)
interface [RTX接続ポート]
 switchport trunk allowed vlan add 60
exit
B3RTX1300 LAN3をVLAN60に設定 ※ この手順はRTXのconfigを確認してから確定する。
VLAN60のIP: 192.168.60.1/24
NATの内側インターフェースをVLAN60に変更。
ip lan3 address 192.168.60.1/24
(NATおよびフィルタの変更は Phase C で実施)
B4疎通確認 12XS から: ping 192.168.60.1
RTX から: ping 192.168.60.2
なし
Phase C: RTX1300 NATとフィルター移行
#作業コマンド/詳細リスク
C1RTX1300の現行config確認 show config で現在のNAT/フィルター/ルーティング全体を確認。
特に nat descriptor, ip filter, ip route を記録。
なし
C2NATをVLAN60経由に変更 nat descriptorの内側アドレスレンジを変更。
192.168.60.0/24(および12XS経由の40/50/20)をNAT対象に。
※ 具体的なconfigはC1の結果を元に確定
C3RTXフィルター設定
# VLAN40(制限なし)
ip filter 600100 pass 192.168.40.0/24 * * * *

# VLAN50(許可先のみ — 48T ACLと二重防御)
ip filter 600110 pass 192.168.50.0/24 * * * *

# VLAN20(WGクライアント戻りのみ)
ip filter 600120 pass 192.168.20.0/24 * * * *

# VLAN10/30 は遮断(デフォルトdeny)
ip filter 600190 reject * * * * *

# LAN3適用
ip lan3 secure filter in 600100 600110 600120 600190
※ 具体的なフィルター番号は現行configに合わせて調整
C4IPv6 RA制御 RTX1300のIPv6 RAがVLAN60にのみ流れることを確認。
LAN3(VLAN60)以外のインターフェースでRA無効化。
C5疎通確認 DarkHero(VLAN40)からインターネット到達確認
R640(VLAN20)からインターネット到達確認
traceroute 8.8.8.8 でVLAN60経由を確認
なし
⚠️ Phase Cは全サービス停止リスクあり。DarkHeroとR640の外部接続が一時切断される可能性大。深夜帯に実施推奨。
Phase D: 12XS ルーティング変更・ACL整理
#作業コマンド/詳細リスク
D112XS default route変更
no ip route 0.0.0.0 0.0.0.0 192.168.10.254
ip route 0.0.0.0 0.0.0.0 192.168.60.1
D212XSの外部向けACL削除 VLAN20_INGRESS, VLAN40_EGRESS, VLAN50_EGRESS 等の外部向けACLを削除。
VLAN間分離用ACL(STORAGE保護等)のみ残す。
※ 削除対象は現行configを確認してからリストアップ
D3IPv6ルーティング設定 VLAN40/20にのみIPv6ルーティングを許可。
VLAN10/30/50へのIPv6ルーティングは設定しない。
D4疎通確認 各VLANからのインターネット到達確認。
VLAN10/30からインターネットに到達しないことを確認。
なし
Phase E: VLAN10のXSからの切り離し
#作業コマンド/詳細リスク
E112XSからVLAN10 SVIを削除
conf t
no interface vlan 10
exit
※ VLAN10のGWが消えるため、VLAN10機器の外部到達性が失われる(意図通り)
E212XS→48Tトランクからvlan10除外
interface [48T uplink]
 switchport trunk allowed vlan remove 10
exit
E348T内でVLAN10 GW設定(必要なら) VLAN10機器同士の通信がL2のみで完結するなら不要。
管理用に48T内にVLAN10 SVIを置く場合:
interface vlan 10
 ip address 192.168.10.1 255.255.255.0
 no ip route-cache
exit
E4確認 VLAN10機器から ping 8.8.8.8 → 到達不可を確認 ✅
VLAN10機器間の通信は正常を確認 ✅
なし
Phase F: 48T VLAN50 ACL設定
#作業コマンド/詳細リスク
F1現VLAN10 ACLを確認・転用設計 show access-lists で現VLAN10 ACLの内容を確認。
VLAN50向けに許可IPリストを作成。
なし
F2VLAN50 ACL作成 Squidのallowed-domains.txtの内容をIP/CIDRベースに変換し、ACLに設定。
許可対象例:
・Ubuntu APTリポジトリ(archive.ubuntu.com系)
・Docker Hub(registry-1.docker.io系)
・PyPI(pypi.org系)
・GitHub
※ 具体的なIPレンジは事前調査(Phase A3)の結果を使用
F3ACL適用 48TのVLAN50ポートにACLを適用
F4確認 R640(VLAN50)から apt update → 成功を確認
R640(VLAN50)から curl https://example.com → 拒否を確認
なし
Phase G: Squid廃止・R640整理
#作業コマンド/詳細リスク
G1Squid停止・無効化
sudo systemctl stop squid
sudo systemctl disable squid
G2Chrome .desktop復元
sudo cp /usr/share/applications/google-chrome.desktop.bak \
       /usr/share/applications/google-chrome.desktop
プロキシ設定を削除(Squid不要のため)
G3APT proxyを削除
sudo rm /etc/apt/apt.conf.d/01proxy
※ 48T ACLで制御するため、プロキシ経由は不要
G4R640 netplan確認 デフォルトルートがVLAN20 GW(192.168.20.1)経由であることを確認。
VLAN50のGWが正しいことを確認。
Phase H: 最終確認テスト
テスト項目期待結果コマンド例
VLAN40(DarkHero)→ インターネット到達ping 8.8.8.8 / ブラウザ確認
VLAN40 IPv6到達ping6 google.com
VLAN50(R640 UPDATE)→ apt update成功sudo apt update
VLAN50 → 許可外ドメイン拒否curl https://twitter.com
VLAN20(WG Client)→ インターネット到達WG接続端末からブラウザ確認
VLAN20 IPv6到達WG端末から ping6
VLAN10 → インターネット到達不可ping 8.8.8.8 → timeout
VLAN10 → VLAN10内通信正常VLAN10機器間ping
VLAN30 → インターネット到達不可ping 8.8.8.8 → timeout
VLAN30 NFS → R640正常showmount -e
WireGuard(外部→R640)正常外部端末からWG接続確認
Nextcloud(WG経由)正常WG接続後ブラウザでcloud.k2-o.net
R640 IPv6 グローバルなしip -6 addr でグローバルIPv6なし確認
6. ロールバック手順
ロールバック判断基準: Phase C/D実施後にDarkHero(VLAN40)がインターネットに到達できない場合、即時ロールバック。
Phaseロールバック方法
Phase B12XSからVLAN60削除。RTX LAN3を元に戻す。影響なし。
Phase CRTX1300のconfigをバックアップから復元: load /flash/backup-20260327.config
Phase D12XSのdefault routeを元に戻す: ip route 0.0.0.0 0.0.0.0 192.168.10.254。ACLをバックアップから復元。
Phase E12XSにVLAN10 SVIを再作成。トランクにVLAN10追加。
Phase F/GSquid再有効化: sudo systemctl enable --now squid。APT proxy復元。
7. 本日(2026-03-27)の作業ログ
7-1. 完了した作業
時刻作業結果
14:44R640 Chrome をSquid経由で起動テストroot権限ではX11接続不可。katuoユーザーで実行して成功。
14:47Squidログ確認TCP_DENIED/403 で全ドメイン拒否を確認。allowed-domains.txt更新。
14:48ブラウザだけでなくOS全体の制御が必要と判断みーきゅん指摘: ブラウザ制御は人的ミスリスク軽減に過ぎない。ネットワーク層制御が本質。
14:57Squid起動失敗allowed-domains.txtのサブドメイン重複エラー(.dl.google.comが.google.comの重複)。整理後に復旧。
15:00Squid復旧確認active (running) 確認。
15:12大規模ネットワーク再設計を決定VLAN60新設、NAT移行、VLAN10閉域化、Squid廃止、48T ACL化。
15:19設計詳細の議論VLAN10をXSから切り離す理由を確認。IPv6制御の方針確定。
15:28IPv6ポリシー確定VLAN60→40/20のみIPv6許可。10/30/50は不可。
15:31計画書作成開始本ドキュメント。
7-2. 現在のSquid設定(廃止前記録)
# /etc/squid/allowed-domains.txt(整理後)
.github.com
.githubusercontent.com
.chatgpt.com
.openai.com
.anthropic.com
.claude.ai
.ubuntu.com
.launchpad.net
.google.com
.googleapis.com
.gstatic.com
.googleusercontent.com
.youtube.com
.googlevideo.com
.ytimg.com
.pypi.org
.pythonhosted.org
.docker.io
.docker.com
.wanchance.com
.cloudflare.com
7-3. Chrome .desktop変更(記録)
# 変更済み(Phase Gで復元予定)
/usr/share/applications/google-chrome.desktop
→ Exec行に --proxy-server="http://192.168.50.10:3128" を追加
→ バックアップ: google-chrome.desktop.bak
8. 次回作業予定(Next Mission)
優先度作業備考
最優先RTX1300 現行config取得show config の全文をClaude に貼り付け。NATとフィルターの現状把握が最初のステップ。
最優先12XS 現行config取得show running-config の全文。ACL/VLAN/SVI/ルーティング把握。
最優先48T 現行config取得show running-config の全文。VLAN10 ACLの転用準備。
Phase A 事前準備config保存、IPレンジ調査、ロールバック手順書
Phase B〜G 実施メンテウィンドウを設けて順次実行
Phase 2 ロードマップ続行Step 1(Switch安定化)は本計画で吸収。Step 2以降を継続。
9. 次チャット引き継ぎサマリ
次のClaude へ: このドキュメントを冒頭で渡してください。以下が最重要コンテキストです。

状況: Mikyun Cloud のネットワーク大規模再設計を計画中。VLAN60新設、RTX1300のNAT移行、VLAN10閉域化、Squid廃止が主な変更。計画書は完成。実施は未着手。

次にやること:
① RTX1300 / 12XS / 48T の現行 show config を取得し、Phase B〜G の具体的なコマンドを確定する。
② メンテウィンドウを決めて Phase B から順次実施。
③ 各Phase完了後にテスト項目を実行し、問題があれば即ロールバック。

設計原則(みーきゅん判断):
・R640に特殊設定を集中させない(Squid廃止の理由)
・スイッチは自発的行動がないから設定が崩れない
・フィルタリングはスイッチ/ルーターの本来の役割
・VLAN10は完全閉域(IPv6含む)
・IPv6はVLAN40とWGのみ

🔧 VLAN60新設・大規模ネットワーク再設計 計画書(完全版)
作成日: 2026-03-27 | 作成者: みーきゅんわんわん + Claude | ステータス: 計画確定・実施待ち
参照元: wanchance.com/infra/ ・ /ip-daichou/ ・ /next-mission/ ・ 検査レポート(2026-03-26)
📋 目次
1. 背景と目的 | 2. 現行構成の完全整理 | 3. 新設計(VLAN60・Po1変更) | 4. 全体ルール集 | 5. Before/After比較 | 6. 物理配線変更マップ | 7. 実施手順(Phase A〜H) | 8. ロールバック | 9. 最終テスト | 10. 引き継ぎサマリ
1. 背景と目的
1-1. 現状の問題(5件)
#問題詳細深刻度
1VLAN10が外部と接触RTX1300 LAN3が192.168.10.254でVLAN10に直接参加。MGMT機器(iDRAC, UPS, スイッチOOB)がRTX経由でインターネットに到達可能。検査レポートでGi1/0/1(RTX1300-OOB)に281M output dropsも確認。重大
2IPv6 RAの制御不能RTX1300のIPv6 RAがVLAN10に流入→R640を含む全VLAN10機器にグローバルIPv6が付与される。R640にIPv6グローバルアドレスが付いた根本原因。重大
3外部アクセス制御の分散12XSのACL(VLAN20_INGRESS, VLAN40_EGRESS, VLAN50_EGRESS等)で外部制御を実施中。本来はWAN境界(RTX)またはアクセス層(48T)の役割。12XSに不要な複雑さが集中。重大
4R640へのSquid集中R640上のSquid(port 3128)でVLAN50フィルタリング。Squid障害→全UPDATE通信停止。3/27にallowed-domains.txtサブドメイン重複でSquid起動失敗を実際に経験。
5Po1トランクの過剰設計48T↔12XS間のPo1(10G×2 LACP)がVLAN10/50をトランクで搬送。VLAN10を48T内完結にすればPo1はVLAN50専用で十分。トランクの複雑さが不要。
1-2. 再設計の目的(6項目)
#目的実現方法
1VLAN10の完全閉域化RTXとの接続をVLAN60(新設)に移行。VLAN10は48T内でL2完結。12XSからVLAN10 SVIを削除。
2IPv6のVLAN単位制御IPv6 RAはVLAN60のみに流入。12XSからVLAN40/20のみにIPv6ルーティング。10/30/50はIPv6なし。
3役割の明確化RTX1300=WAN境界フィルタ/NAT、12XS=L3ルーティング/VLAN間分離のみ、48T=VLAN50フィルタ/VLAN10完結
4Squid廃止48TのACLでVLAN50をIP/ポートベースでフィルタ。R640からフィルタリング役割を完全に解放。
5Po1をVLAN50専用に変更48T↔12XS間のPo1(10G×2 LACP)をVLAN50アクセスポートに変更。トランク不要化。
6設計のシンプル化12XSの外部向けACLを全削除。各装置が本来の役割のみ担当。
2. 現行構成の完全整理
2-1. 現行トポロジー
Internet OCN MAP-E (v4/v6) │ ┌────────┴────────┐ │ RTX1300 │ │ LAN3: .10.254 │ ← VLAN10でNAT(問題の根源) │ LAN2: WAN 10G │ │ LAN1: .100.1 │ ← 旧セグメント残存 └────────┬────────┘ │ Te2/0/1 (VLAN10 trunk) ┌────────┴────────┐ │ WS-C3850-12XS │ CORE L3 │ SVI: .10.1 │ ← VLAN10 GW │ SVI: .20.1 │ ← VLAN20 GW(唯一の出口) │ SVI: .30.1 │ ← VLAN30 GW │ SVI: .40.1 │ ← VLAN40 GW │ SVI: .50.1 │ ← VLAN50 GW │ default → .10.254 (RTX) └─┬──┬──┬──┬──┬───┘ │ │ │ │ │ Te2/0/3────────┘ │ │ │ └──── Po1 (Te2/1/3+Te2/1/4) DarkHero │ │ │ 20G LACP trunk VLAN40 │ │ │ → 48T (VLAN10,50搬送) │ │ │ Po20 ──────────────┘ │ └─── Po2 (Te2/0/9[SUSPENDED]+Te2/0/10) R640 DATA │ SM STORAGE VLAN30 Te2/0/5+Te2/0/6 │ ⚠️ 片側断 84M drops VLAN20 10G×2 │ │ Po30 ──────────────────┘ R640 STG Te2/0/7+Te2/0/8 VLAN30 10G×2 ⚠️ PAUSE 42億超 ┌─────────────────┐ │ WS-C3850-48T │ ACCESS / OOB │ VLAN10ポート群 │ Gi1/0/1,3,5,7,9,11,13,15,17,37,39,41 │ VLAN50ポート群 │ Gi1/0/25, Gi1/0/27 │ Po1 ↑ 12XS │ Te1/1/3+Te1/1/4 trunk └─────────────────┘
2-2. 現行VLAN・IPアドレス台帳
VLAN名称CIDRGW(12XS SVI)外部接続収容ポート
10MGMT192.168.10.0/24192.168.10.1RTX経由で可能(問題)48T: Gi1/0/1,3,5,7,9,11,13,15,17,37,39,41
20DATA192.168.20.0/24192.168.20.1★唯一の出口(DGW)12XS: Te2/0/4(NC-PC), Po20(R640)
30STORAGE192.168.30.0/24192.168.30.1なし(閉域)12XS: Po30(R640), Po2(SM)
40WAN_PC192.168.40.0/24192.168.40.1制限なし12XS: Te2/0/3(DH), Te2/0/12(WiFi)
50UPDATE192.168.50.0/24192.168.50.1Squid経由のみ48T: Gi1/0/25(R640), Gi1/0/27(SM)
999NATIVEトランクNative(未使用)
2-3. 現行サーバIPアドレス台帳
機器IF名Linux IFIPVLAN接続先ポートDGWDNS
R640R640-IDRAC(iDRAC)192.168.10.201048T Gi1/0/7
R640-MGMTeno3192.168.10.211048T Gi1/0/15
R640-UPDeno4192.168.50.105048T Gi1/0/25
R640-DATA1enop216sof0192.168.20.202012XS Te2/0/5 (Po20)192.168.20.11.1.1.1
R640-DATA2eno1192.168.20.212012XS Te2/0/6 (Po20)192.168.20.11.1.1.1
R640-STG1enop216sof1192.168.30.203012XS Te2/0/7 (Po30)
R640-STG2eno2192.168.30.213012XS Te2/0/8 (Po30)
R640-FAB1enp59s0172.31.20.1FAB-BSM直結 QSFP
R640-FAB2enp59s0d1172.31.21.1FAB-BSM直結 QSFP
R640-DH1ibp94s0172.31.22.1FAB-BDH直結 QSFP
R640-DH2ibp94s0d1172.31.23.1FAB-BDH直結 QSFP
SupermicroSM-WEBconsole192.168.10.301048T Gi1/0/9
SM-MGMTeno3192.168.10.311048T Gi1/0/17
SM-STG1eno1192.168.30.303012XS Te2/0/9 (Po2)
SM-STG2enp1311sf1192.168.30.313012XS Te2/0/10 (Po2)
SM-UPDeno2192.168.50.305048T Gi1/0/27
SM-FAB-Aeno4172.31.10.1FAB-ADH直結 10G
SM-FAB-B1ens6172.31.20.2FAB-BR640直結 QSFP
SM-FAB-B2enos6d1172.31.21.2FAB-BR640直結 QSFP
spareenp1311sf0
DarkHeroDH-MGMT192.168.10.101048T Gi1/0/13
DH-WAN192.168.40.104012XS Te2/0/3192.168.40.11.1.1.1
DH-FAB-A172.31.10.2FAB-ASM直結 10G
DH-FAB-B1172.31.22.2FAB-BR640直結 QSFP
DH-FAB-B2172.31.23.2FAB-BR640直結 QSFP
RTX1300LAN3192.168.10.2541012XS Te2/0/1
2-4. 現行12XSポートマップ
ポート接続先VLAN/モード速度検査結果
Te2/0/1RTX1300 LAN3trunk (VLAN10)10G⚠️ 27M output drops
Te2/0/2DarkHero WAN #2VLAN40notconnect未使用
Te2/0/3DarkHero WAN #1VLAN4010G7.6M drops
Te2/0/4Nextcloud PCVLAN2010G✅ 0 drops
Te2/0/5R640-DATA1 (Po20)VLAN2010G⚠️ 23.6M drops
Te2/0/6R640-DATA2 (Po20)VLAN2010G1.8M drops
Te2/0/7R640-STG1 (Po30)VLAN3010G7.5M drops
Te2/0/8R640-STG2 (Po30)VLAN3010G⚠️ 47.6M drops
Te2/0/9SM-STG1 (Po2)VLAN30⚠️ SUSPENDED🔴 94.7M drops / 138M PAUSE
Te2/0/10SM-STG2 (Po2)VLAN3010G✅ 0 drops
Te2/0/11VLAN1notconnect未使用
Te2/0/12WiFi RouterVLAN4010G🔴 80.2M drops / 26M PAUSE
Te2/1/348T (Po1)trunk10G
Te2/1/448T (Po1)trunk10G
3. 新ネットワーク設計
3-1. 新トポロジー図
Internet OCN MAP-E (v4/v6) │ ┌────────┴────────┐ │ RTX1300 │ │ LAN3: .60.1 │ ★ VLAN60に変更(NAT/フィルタ) │ LAN2: WAN 10G │ └────────┬────────┘ │ Te2/0/1 → VLAN60 access │ ★ 新設: RTX↔12XS間専用リンク ┌────────┴────────┐ │ WS-C3850-12XS │ CORE L3 │ SVI: .20.1 │ ← VLAN20 GW │ SVI: .30.1 │ ← VLAN30 GW │ SVI: .40.1 │ ← VLAN40 GW │ SVI: .50.1 │ ← VLAN50 GW │ SVI: .60.2 │ ★ VLAN60 GW 新設 │ ★ VLAN10 SVI 削除 │ ★ 外部向けACL 全削除 │ default → .60.1 (RTX) └─┬──┬──┬──┬──┬───┘ │ │ │ │ │ Te2/0/3────────┘ │ │ │ └── Po1 (Te2/1/3+Te2/1/4) DarkHero │ │ │ 20G LACP VLAN40 │ │ │ ★ VLAN50 access に変更 制限なし │ │ │ (トランク廃止) │ │ │ Po20 ──────────────┘ │ └── Po2 (Te2/0/9+Te2/0/10) R640 DATA │ SM STORAGE VLAN30 VLAN20 10G×2 │ │ Po30 ──────────────────┘ R640 STG VLAN30 ┌─────────────────┐ │ WS-C3850-48T │ ACCESS │ ★ VLAN10 ここで完結(外に出さない) │ ★ VLAN50 ACL フィルタ担当 │ ★ Po1 = VLAN50 access │ VLAN10ポート: Gi1/0/1,3,5,7,9,11,13,15,17,37,39,41 │ VLAN50ポート: Gi1/0/25, Gi1/0/27 └─────────────────┘ VLAN10 = 48T内L2完結 ★ 外部到達不可 ★ IPv6なし ★ RTXに届かない
3-2. 新VLAN設計一覧
VLAN名称CIDRGW外部IPv6収容スイッチ変更点
10MGMT192.168.10.0/2448T SVI .10.1
(または GWなし)
不可不可48Tのみ★ 12XSから完全切離し。Po1から除外。閉域化。
20DATA/WG192.168.20.0/2412XS .20.1WGのみ許可12XS変更なし。WGクライアントのみ外部到達。
30STORAGE192.168.30.0/2412XS .30.1不可不可12XS変更なし。完全閉域。
40WAN_PC192.168.40.0/2412XS .40.1制限なし許可12XS変更なし。唯一のフルアクセスVLAN。
50UPDATE192.168.50.0/2412XS .50.1ACL制限不可48T → Po1 → 12XS★ Squid廃止→48T ACLでフィルタ。Po1がVLAN50専用に。
60WAN-LINK192.168.60.0/24RTX .60.1★ RTX専用RA受信12XS Te2/0/1のみ★ 新設。RTX↔12XS間P2P。NATはここだけ。
999NATIVEトランク用変更なし。
3-3. 新IPアドレス台帳(変更分のみ)
機器変更前変更後備考
RTX1300 LAN3192.168.10.254 (VLAN10)192.168.60.1 (VLAN60)NAT内側IFをVLAN60に変更
12XS SVI VLAN60(なし)192.168.60.2新設。VLAN60側ルーティングエンドポイント
12XS SVI VLAN10192.168.10.1削除48Tに移管 or 廃止
12XS default route192.168.10.254192.168.60.1next-hopをVLAN60 RTXに変更
12XS Te2/0/1trunk (VLAN10)access VLAN60RTX接続ポートのモード変更
Po1 (12XS↔48T)trunk (VLAN10,50)access VLAN50★ 10G×2 LACPをVLAN50専用に変更
3-4. IPv6ポリシー
VLANIPv6制御方法
VLAN60RA受信(RTXから)RTX LAN3からRAが流入。ここでのみIPv6アドレスを受信。
VLAN40許可12XSがVLAN60のIPv6をVLAN40にルーティング
VLAN20 (WG)許可12XSがVLAN60のIPv6をVLAN20にルーティング(WGクライアント向け)
VLAN10不可48T内完結。12XSに到達しないためIPv6ルーティング対象外。
VLAN30不可12XSでIPv6ルーティングしない。RA到達不可。
VLAN50不可12XSでIPv6ルーティングしない。RA到達不可。
4. 全体ルール集(新設計の絶対法則)
🚨 このセクションは「設計の憲法」です。どんな変更・拡張時もこのルールに違反しないことを確認してください。
4-1. ネットワーク階層ルール
#ルール名内容違反した場合
L1三層分離の遵守CORE(12XS)= L3ルーティング/VLAN間分離のみ。ACCESS(48T)= ポート収容/フィルタ/VLAN10完結。EDGE(RTX)= WAN境界/NAT/フィルタ。各層の役割を超えた設定をしない。複雑性増大→事故の温床
L2外部フィルタの所在外部アクセスのフィルタリングは RTX1300(WAN境界)と 48T(アクセス層ACL)のみ。12XSに外部向けACLは置かない。12XSのACL肥大→管理不能
L3R640に特殊設定を集中させないR640はサーバー専任(WG/Nextcloud/Portal/Docker)。Squidのようなネットワーク制御機能をR640に持たせない。R640障害→全通信停止
L4スイッチの信頼性スイッチは自発的な行動がないため設定が崩れない。フィルタリングはスイッチ/ルーターの本来の役割。可能な限りネットワーク機器側で制御する。
4-2. Default Gateway ルール(最重要)
❌ 絶対禁止: VLAN10にDefault GW / VLAN50にDNS / FabricにDNS / WG interfaceにGW / 複数Default Route
✅ 唯一の出口: R640のDefault GW = VLAN20(192.168.20.1)のみ。DarkHeroのDefault GW = VLAN40(192.168.40.1)のみ。
機器Default GWDNS理由
R640192.168.20.1(VLAN20のみ)1.1.1.1(VLAN20のみ)二重出口防止。VPN安定性。非対称ルーティング防止。
DarkHero192.168.40.1(VLAN40のみ)1.1.1.1(VLAN40のみ)同上。
Supermicroなしなしストレージノードは外部到達不要。UPDATEはVLAN50経由。
VLAN10機器なし(48T内完結)なし管理ネットワークは閉域。DNSがあるIFをOSが出口と誤認するため禁止。
Fabric全IFなしなし純同期ネットワーク。Routing禁止/Internet禁止/DNS不要。
4-3. VLAN間通信マトリクス(新設計)
From \ ToVLAN10VLAN20VLAN30VLAN40VLAN50VLAN60Internet
VLAN10 (MGMT)✅ L2
VLAN20 (DATA)✅ R640→SM✅ via 12XS✅ WGのみ
VLAN30 (STG)✅ NFS
VLAN40 (DH)✅ via 12XS✅ 制限なし
VLAN50 (UPD)✅ via 12XS✅ ACL許可先のみ
VLAN60 (WAN)✅ ルーティング✅ ルーティング✅ ルーティング
VLAN10は12XSに到達しないため、他VLANとのL3通信は物理的に不可能。これが「完全閉域」の意味。
4-4. 外部アクセス制御ルール
VLAN外部到達制御場所制御方法
VLAN10❌ 到達不可物理的に遮断(48T内完結)12XSにVLAN10 SVIなし。Po1にVLAN10なし。RTXに届かない。
VLAN20WGクライアントのみRTX1300フィルタRTXがVLAN20からのWG戻りパケットのみ許可。R640自身はVLAN20 GW経由で外部到達可能。
VLAN30❌ 到達不可12XS ACL(VLAN間分離)VLAN30 GWなし設計は維持。12XSでVLAN30→VLAN60ルーティングしない。
VLAN40✅ 制限なしRTX1300(pass all)DarkHero唯一のフルアクセスVLAN。RTXで全通過。
VLAN50ACL許可先のみ48T ACL + RTX130048TのACLでIP/ポートベース制御。RTXでも二重防御。
4-5. DNS設計ルール
機器/IFDNS理由
DarkHero VLAN401.1.1.1唯一の外部通信IF
R640 VLAN20 (bond0)1.1.1.1唯一の外部通信IF
WGクライアントdnsmasq (10.200.0.1)R640上のdnsmasqで cloud.k2-o.net 等を内部解決
それ以外のすべてのIF❌ なしDNSがあるIF = OSが出口と誤認する。事故防止の核心。
4-6. DNS多層解決ルール(変更なし・運用注意)
アクセス元DNS解決方法設定場所
WGクライアント(iPhone等)dnsmasq(10.200.0.1)R640: /etc/dnsmasq.conf
ローカルPC(LAN直接)hostsファイル各PC: /etc/hosts or C:\Windows\…\hosts
R640自身/etc/hostsR640: /etc/hosts
Nextcloudコンテナextra_hosts(compose.yml)R640: /root/nextcloud-stack/compose.yml
Collaboraコンテナ--add-host(docker run)ひらめPC: docker runコマンド
ひらめPC自身/etc/hostsひらめPC: /etc/hosts
新しいドメインを追加するときは上記の全箇所に追記が必要。1箇所でも漏れると繋がらなくなる。
4-7. Fabric設計ルール
Fabric経路帯域ルール
FABRIC-ADarkHero ↔ Supermicro 直結10G RJ45GWなし / DNSなし / Routing禁止 / ファイル転送専用
FABRIC-BR640 ↔ Supermicro QSFP直結40G×2GWなし / DNSなし / balance-xor LACP / Ceph対応 / 将来クラスタ同期
FABRIC-B (DH)R640 ↔ DarkHero QSFP直結40G×2同上
4-8. 装置別 役割分担(新設計)
装置役割やることやらないこと
RTX1300WAN境界
NAT
WAN側フィルタ
NATをVLAN60経由で実施。VLAN40/50のWAN通過許可。VLAN10/30遮断。IPv6 RAをVLAN60にのみ配信。WireGuard UDP 54024 のポートフォワード。VLAN間ルーティング。内部フィルタリング。
12XSL3ルーティング
VLAN間分離
VLAN間ルーティング(default route → .60.1)。VLAN30(STORAGE)への到達制御ACL。IPv6: VLAN40/20のみルーティング。STP Root全VLAN。外部向けACL。VLAN10の管理。フィルタリング。
48Tアクセス層
VLAN50 ACL
VLAN10完結
VLAN10ポート収容(閉域)。VLAN50ポート収容+ACLフィルタ。Po1でVLAN50を12XSに搬送。L3ルーティング。外部通信。
R640サーバー専任WireGuard終端(wg0/wg-admin/wg2)。Nextcloud/Portal/Docker。dnsmasq。nginx。Squid(廃止)。ネットワークフィルタリング。プロキシ。
4-9. WireGuard設計ルール(変更なし)
IFサブネット用途EndPoint
wg010.200.0.0/16顧客VPNvpn.k2-o.net:54024
wg-admin内部管理VPN
wg210.250.0.0/24VPS↔R640 backhaul
wg setコマンドで追加したPeerは再起動で消える。必ず /etc/wireguard/wg0.conf にも追記すること。
5. Before / After 完全比較
項目Before(現状)After(新設計)
RTX↔12XS接続Te2/0/1 trunk VLAN10
RTX LAN3: 192.168.10.254
Te2/0/1 access VLAN60
RTX LAN3: 192.168.60.1
12XS default route192.168.10.254192.168.60.1
NATVLAN10経由VLAN60経由
VLAN1012XS SVI .10.1 あり
RTXに到達可能
12XS SVI 削除
48T内L2完結・完全閉域
IPv6 RAVLAN10に流入(全機器にIPv6付与)VLAN60のみ。40/20にルーティング。
Po1 (48T↔12XS)trunk (VLAN10, 50, 999 native)
VLAN10も搬送
★ access VLAN50
VLAN50専用 10G×2 LACP
VLAN50フィルタR640上Squid (port 3128)48T ACL (IP/ポートベース)
12XS ACLVLAN20_INGRESS, VLAN40_EGRESS,
VLAN50_EGRESS 等 多数
VLAN間分離のみ(外部向け全削除)
R640 Squid有効 (port 3128)
allowed-domains.txt 管理
★ 廃止・disable
R640 Chrome .desktop--proxy-server追記済み★ バックアップから復元(プロキシ不要)
R640 APT proxy/etc/apt/apt.conf.d/01proxy 設定済み★ 削除(48T ACLで制御)
6. 物理配線変更マップ
6-1. 変更対象ポート一覧
スイッチポート現状変更後物理作業
12XSTe2/0/1trunk (RTX LAN3) VLAN10access VLAN60ケーブルそのまま。設定変更のみ。
12XSTe2/1/3Po1メンバー trunk (VLAN10,50)Po1メンバー access VLAN50ケーブルそのまま。設定変更のみ。
12XSTe2/1/4Po1メンバー trunk (VLAN10,50)Po1メンバー access VLAN50ケーブルそのまま。設定変更のみ。
48TTe1/1/3Po1メンバー trunkPo1メンバー access VLAN50ケーブルそのまま。設定変更のみ。
48TTe1/1/4Po1メンバー trunkPo1メンバー access VLAN50ケーブルそのまま。設定変更のみ。
物理ケーブル変更: なし。 全て論理設定変更のみで完結。
7. 実施手順(Phase A〜H)
⚠️ 全手順の所要時間目安: 3〜5時間。メンテウィンドウを設け、ロールバック手順を事前に準備してから実施。
⚠️ 最初のステップ: RTX1300 / 12XS / 48T の show config 全文を取得し、具体的コマンドを確定する。
Phase A: 事前準備
#作業コマンド
A1全装置config保存RTX: save /flash/backup-pre-vlan60.config
12XS: copy running-config flash:backup-pre-vlan60.cfg
48T: copy running-config flash:backup-pre-vlan60.cfg
R640: sudo cp -r /etc/netplan/ /root/backup-netplan-pre-vlan60/
sudo cp -r /etc/squid/ /root/backup-squid-pre-vlan60/
A2show config全文取得RTX: show config → Claudeに貼付(NATフィルタ確認)
12XS: show running-config → 同上
48T: show running-config → 同上
A3VLAN50 ACL許可先IP調査Squidのallowed-domains.txtの各ドメインをdig/nslookupでIP化。CDN系はCIDRで確認。
A4ロールバック手順書確認Section 8 のロールバック手順を印刷 or 別端末に表示。
Phase B: VLAN60新設
#作業コマンドリスク
B112XSにVLAN60作成+SVI
conf t
vlan 60
 name WAN-LINK
exit
interface vlan 60
 ip address 192.168.60.2 255.255.255.0
 no shutdown
exit
B2Te2/0/1をVLAN60 accessに変更
interface Te2/0/1
 switchport mode access
 switchport access vlan 60
 no shutdown
exit
※ この瞬間RTXとの通信が一時断
※ RTX側も同時にVLAN60設定する
B3RTX LAN3をVLAN60に変更
ip lan3 address 192.168.60.1/24
※ RTX config確認後に確定
B4疎通確認12XS: ping 192.168.60.1
RTX: ping 192.168.60.2
なし
⚠️ Phase B2-B3はRTX↔12XS間が一時断になる。DarkHeroとR640の外部接続が切れる。B2とB3を素早く連続で実施すること。
Phase C: RTX NAT/フィルター移行
#作業詳細リスク
C1NATをVLAN60経由に変更nat descriptorの内側アドレスレンジ変更。12XS経由の全サブネット(20/40/50)をNAT対象に。※ show configの結果から具体化
C2static routeをVLAN60に変更
# 旧ルート削除
no ip route 192.168.20.0/24 gateway 192.168.10.1
no ip route 192.168.30.0/24 gateway 192.168.10.1
...
# 新ルート追加
ip route 192.168.20.0/24 gateway 192.168.60.2
ip route 192.168.40.0/24 gateway 192.168.60.2
ip route 192.168.50.0/24 gateway 192.168.60.2
※ VLAN10/30のルートは追加しない(到達不可が正しい)
C3WireGuard NATポートフォワード確認UDP:54024 / TCP:443 / TCP:80 のstatic NATが正しく192.168.20.21宛になっていることを確認
C4IPv6 RA制御LAN3(VLAN60)以外でRA無効化。VLAN10へのRA流入を遮断。
C5疎通確認DarkHero: ping 8.8.8.8 + ブラウザ
R640: traceroute 8.8.8.8 → VLAN60経由確認
なし
Phase D: 12XS ルーティング変更・ACL整理
#作業コマンドリスク
D1default route変更
no ip route 0.0.0.0 0.0.0.0 192.168.10.254
ip route 0.0.0.0 0.0.0.0 192.168.60.1
D2外部向けACL削除VLAN20_INGRESS, VLAN40_EGRESS, VLAN50_EGRESS等の外部向けACLを削除。VLAN間分離用ACL(STORAGE保護等)のみ残す。※ show config確認後に確定
D3VLAN40 STP priority修正
spanning-tree vlan 40 priority 4096
(検査レポートで未設定と判明)
D4IPv6ルーティングVLAN40/20にのみIPv6ルーティング許可。10/30/50はルーティングしない。
Phase E: VLAN10のXSからの切り離し
#作業コマンドリスク
E112XS VLAN10 SVI削除
no interface vlan 10
E248T内にVLAN10 SVI設定(任意)
interface vlan 10
 ip address 192.168.10.1 255.255.255.0
 no ip route-cache
exit
※ VLAN10内L2通信のみならSVI不要。管理上必要な場合のみ。
E3確認VLAN10機器間ping: ✅
VLAN10→8.8.8.8: ❌ timeout(正常)
なし
Phase F: Po1をVLAN50専用に変更
#作業コマンドリスク
F112XS側 Po1変更
interface Port-channel1
 switchport mode access
 switchport access vlan 50
exit
interface range Te2/1/3 - 4
 switchport mode access
 switchport access vlan 50
exit
F248T側 Po1変更
interface Port-channel1
 switchport mode access
 switchport access vlan 50
exit
interface range Te1/1/3 - 4
 switchport mode access
 switchport access vlan 50
exit
F3確認R640(VLAN50 .50.10) → ping 192.168.50.1 (12XS SVI)
SM(VLAN50 .50.30) → ping 192.168.50.1
なし
Po1がVLAN50 accessになることで、48TのVLAN50ポート(Gi1/0/25, Gi1/0/27)から12XSのVLAN50 SVIまで直通になる。トランクのオーバーヘッドがなくなり20Gbps全帯域をVLAN50が利用可能。
Phase G: 48T VLAN50 ACL設定
#作業詳細リスク
G1VLAN50 ACL作成Squid allowed-domains.txtをIP/CIDRに変換。主要許可先: Ubuntu APT, Docker Hub, PyPI, GitHub, wanchance.com, Google, Cloudflare。※ Phase A3の調査結果を使用
G2ACL適用48TのVLAN50ポート(Gi1/0/25, Gi1/0/27)にACLを適用。またはVLAN50 SVIにACL適用。
G3確認R640: sudo apt update → ✅
R640: curl https://twitter.com → ❌ 拒否
なし
Phase H: Squid廃止・R640整理・最終確認
#作業コマンド
H1Squid停止・無効化sudo systemctl stop squid && sudo systemctl disable squid
H2Chrome .desktop復元sudo cp /usr/share/applications/google-chrome.desktop.bak /usr/share/applications/google-chrome.desktop
H3APT proxy削除sudo rm /etc/apt/apt.conf.d/01proxy
H4全体テスト(Section 9参照)全VLANからの到達性テスト。WireGuard/Nextcloud/NFS確認。
H5wanchance.comの更新インフラ構成ページ/IP台帳/Next Missionを新設計に更新。
8. ロールバック手順
ロールバック判断基準: Phase B/C実施後にDarkHero(VLAN40)がインターネットに到達できない場合 → 即時ロールバック。
Phaseロールバック
B12XS Te2/0/1をtrunk VLAN10に戻す。RTX LAN3を192.168.10.254に戻す。VLAN60 SVI削除。
CRTX configをバックアップから復元: load /flash/backup-pre-vlan60.config
D12XS default routeを戻す: ip route 0.0.0.0 0.0.0.0 192.168.10.254。ACLバックアップ復元。
E12XSにVLAN10 SVI再作成 interface vlan 10 / ip address 192.168.10.1 255.255.255.0
FPo1をtrunkに戻す: switchport mode trunk / switchport trunk allowed vlan 10,50
G/HSquid再有効化: sudo systemctl enable --now squid。APT proxy復元。.desktop復元。
9. 最終確認テスト一覧
テスト項目期待結果コマンド
VLAN40(DarkHero)→ Internet到達ping 8.8.8.8 / ブラウザ
VLAN40 IPv6到達ping6 google.com
VLAN50 → apt update成功sudo apt update(R640/SM両方)
VLAN50 → 許可外拒否curl https://twitter.com
VLAN20(WG Client)→ Internet到達WG端末からブラウザ
VLAN20 IPv6到達WG端末からping6
VLAN10 → Internet不可ping 8.8.8.8 → timeout
VLAN10内通信正常VLAN10機器間ping
VLAN30 → Internet不可ping 8.8.8.8 → timeout
VLAN30 NFS正常showmount -e / mount確認
WireGuard外部→R640正常外部端末からWG接続
Nextcloud(WG経由)正常https://cloud.k2-o.net
Collabora正常Nextcloudからドキュメント開く
R640 IPv6グローバルなしip -6 addr → グローバルアドレスなし
Po1 VLAN50疎通正常R640(.50.10) → ping 192.168.50.1
traceroute経路VLAN60経由traceroute 8.8.8.8 → 192.168.60.1が見える
10. 次チャット引き継ぎサマリ
次のClaudeへ: このドキュメントを冒頭で渡してください。wanchance.com の /infra/ と /ip-daichou/ と /next-mission/ も参照してください。

状況: Mikyun Cloud ネットワーク大規模再設計。計画書完成・実施未着手。

変更の核心(6点):
① VLAN60(192.168.60.0/24)新設 — RTX↔12XS間のP2Pリンク
② RTX1300のNAT/ルーティングをVLAN10→VLAN60に移行
③ VLAN10を48T内L2完結で完全閉域化(12XSからSVI削除)
④ Po1(48T↔12XS 10G×2 LACP)をtrunk→VLAN50 accessに変更
⑤ Squid廃止 → 48T ACLでVLAN50フィルタリング
⑥ 12XSの外部向けACL全削除

次にやること:
① RTX1300 / 12XS / 48T の show config 全文を取得
② Phase B〜H の具体的コマンドを確定
③ メンテウィンドウを決めて実施

設計原則:
・R640に特殊設定を集中させない(Squid廃止の理由)
・スイッチは自発的行動がない→設定が崩れない
・フィルタはスイッチ/ルーターの本来の役割
・Default GWはVLAN20のみ(R640)/ VLAN40のみ(DH)
・DNSがあるIF = OSが出口と誤認する → VLAN20/40以外にDNS禁止
・VLAN10は完全閉域(IPv6含む)
・IPv6はVLAN40とWGのみ許可

🔧 みーきゅんクラウド VLAN60ネットワーク大規模再設計 — Claude Code 自動実行指示書

この指示書をそのままClaude Codeに貼り付けてください。 事前に https://wanchance.com/next-mission/ と https://wanchance.com/ip-daichou/ と https://wanchance.com/infra/ を読み込ませてから実行してください。


📋 作業概要

みーきゅんクラウドのネットワーク大規模再設計を自動実行してください。 作業対象は以下の4台です:

機器管理IP接続方法ユーザー
RTX1300192.168.10.254SSH (telnet)admin
WS-C3850-12XS192.168.10.1SSHadmin
WS-C3850-48T192.168.10.2SSHadmin
R640 (Ubuntu)192.168.10.21SSHroot/katuo

🔐 権限と自動承認ルール

以下のルールを厳守してください:

  1. 自動承認(確認不要で実行してよい):

    • R640/SM/12XS/48T/RTX1300 へのSSH接続・コマンド実行
    • スイッチ/ルーターの設定変更(VLAN作成、ACL変更、ポート変更、ルーティング変更)
    • R640上のサービス停止/起動/無効化(Squid含む)
    • R640上のファイル編集・削除・バックアップ
    • netplan変更・適用
    • write memory / save(設定保存)
    • すべてのping/traceroute/show系コマンド
    • ファイルの作成・出力
  2. 禁止事項(絶対にやらないこと):

    • wanchance.com 以外の外部サーバーへのSSH接続
    • 機器の再起動(reboot/reload)— 明示的に指示があった場合のみ可
    • 既存のWireGuard設定の変更(wg0.conf, wg-admin等)
    • Nextcloudのデータ/設定の変更
    • Docker コンテナの停止・削除
  3. 物理作業が必要な場合:

    • ケーブル差し替え等の物理作業が必要な箇所は スキップ してください
    • スキップした作業は最終報告書の「物理作業待ちリスト」にまとめてください
    • 論理設定変更で対応可能な部分はすべて自動実行してください
  4. 途中確認は不要:

    • 「実行してよいですか?」等の確認は一切不要です
    • 各Phaseを順番に自動実行し、各Phase完了後に結果をログに記録してください
    • エラーが発生した場合のみ停止し、エラー内容を報告してください

🎯 実行する変更内容(6項目)

変更1: VLAN60新設(RTX↔12XS間 P2Pリンク)

  • 12XSにVLAN60(WAN-LINK)を作成、SVI: 192.168.60.2/24
  • Te2/0/1(RTX接続ポート)を現在のtrunk → access VLAN60 に変更
  • RTX1300 LAN3のIPを 192.168.10.254 → 192.168.60.1/24 に変更

変更2: RTX1300 NAT/ルーティング移行

  • NATの内側インターフェースをVLAN10→VLAN60に変更
  • static routeのnext-hopを 192.168.10.1 → 192.168.60.2 に変更
  • VLAN10/30向けルートは削除(到達不可が正しい設計)
  • WireGuard NATポートフォワード(UDP:54024, TCP:443, TCP:80)は維持

変更3: VLAN10完全閉域化

  • 12XSから interface vlan 10 を削除(SVI削除)
  • VLAN10は48T内でL2完結させる
  • 48Tに必要ならVLAN10 SVI (192.168.10.1/24) を設定

変更4: Po1をVLAN50専用に変更

  • 12XS側: Po1 (Te2/1/3 + Te2/1/4) を trunk → access VLAN50 に変更
  • 48T側: Po1 (Te1/1/3 + Te1/1/4) を trunk → access VLAN50 に変更
  • VLAN10はPo1から除外される(48T内完結のため不要)

変更5: Squid廃止 → 48T ACLでVLAN50フィルタ

  • R640上のSquidを停止・無効化
  • Chrome .desktopのproxy設定を復元
  • APT proxy設定(/etc/apt/apt.conf.d/01proxy)を削除
  • 48TにVLAN50用ACLを作成(許可先IPリストは後述)

変更6: 12XS外部向けACL削除

  • VLAN20_INGRESS, VLAN40_EGRESS, VLAN50_EGRESS 等の外部向けACLを削除
  • VLAN間分離用ACL(STORAGE保護等)は残す
  • default routeを 192.168.10.254 → 192.168.60.1 に変更
  • VLAN40 STP priority を 4096 に設定(検査レポートで未設定と判明)

📝 実行手順(この順番で実行すること)

Phase 0: 情報収集と事前準備

# 0-1. 全機器の現行config取得・保存
# RTX1300
ssh admin@192.168.10.254 "show config" > /tmp/rtx1300-config-backup.txt

# 12XS
ssh admin@192.168.10.1 "show running-config" > /tmp/12xs-config-backup.txt

# 48T
ssh admin@192.168.10.2 "show running-config" > /tmp/48t-config-backup.txt

# R640
cp /etc/netplan/*.yaml /root/backup-netplan-pre-vlan60/
cp -r /etc/squid/ /root/backup-squid-pre-vlan60/

# 0-2. 現在の状態を記録
# 各機器の show vlan brief / show ip route / show interface status / show etherchannel summary を取得
# RTXの show nat descriptor address / show status tunnel 1 を取得

重要: Phase 0で取得したconfigを分析し、以降のPhaseのコマンドを具体化してから進むこと。 特に以下を確認:

  • RTX1300の nat descriptor 番号と設定内容
  • RTX1300の ip filter 番号体系
  • RTX1300の ip route 設定一覧
  • 12XSの現行ACL名と内容(外部向けACLの特定)
  • 12XSの Te2/0/1 の現行設定
  • Po1 の現行trunk設定(allowed vlan)
  • 48Tの現行ACL

Phase B: VLAN60新設

# B-1. 12XSにVLAN60作成
ssh admin@192.168.10.1
conf t
vlan 60
 name WAN-LINK
exit
interface vlan 60
 ip address 192.168.60.2 255.255.255.0
 no shutdown
exit
end
write memory

# B-2. Te2/0/1をVLAN60 accessに変更
# ⚠️ この瞬間RTXとの通信が一時的に切れる
# B-3のRTX設定と素早く連続で実施すること
conf t
interface Te2/0/1
 switchport mode access
 switchport access vlan 60
 no shutdown
exit
end
write memory

# B-3. RTX1300 LAN3をVLAN60に変更
# ※ RTXのconfigを確認して正確なコマンドを確定すること
# 基本形:
ssh admin@192.168.10.254   # ← この時点でVLAN10経由で到達できない可能性あり
                            # コンソール接続 or 48T経由OOBで対応が必要な場合あり
ip lan3 address 192.168.60.1/24

# B-4. 疎通確認
# 12XSから: ping 192.168.60.1
# RTXから: ping 192.168.60.2

⚠️ Phase Bの重要な注意点: Te2/0/1をVLAN60に変えた瞬間、RTXのLAN3(192.168.10.254)と12XSのVLAN10 SVI(192.168.10.1)が別VLANになるため通信断が発生する。

対処法(以下のいずれかで対応):

  1. RTX1300にOOB経由(48T Gi1/0/1 → VLAN10)でアクセスできる場合はそちらから設定変更
  2. RTX1300のコンソール接続が必要な場合は「物理作業待ち」としてスキップ
  3. 12XS側でVLAN10 SVIを残したまま先にRTXを変更し、確認後にVLAN10 SVIを削除する順序に変更

推奨: 手順3の安全な順序で実施:

  • まず12XSにVLAN60 SVIを追加(既存VLAN10はそのまま)
  • Te2/0/1をtrunkのままVLAN60を追加(switchport trunk allowed vlan add 60)
  • RTX LAN3にVLAN60 tag付きで接続するか、別ポートでVLAN60接続
  • VLAN60経由の疎通確認後に、Te2/0/1からVLAN10を除外

Phase C: RTX1300 NAT/フィルター移行

Phase 0で取得したRTX configを分析し、以下を実行:

# C-1. static route変更
# 旧ルート削除(existing routeを正確に確認してから)
# 例:
no ip route 192.168.20.0/24 gateway 192.168.10.1
no ip route 192.168.30.0/24 gateway 192.168.10.1
no ip route 192.168.40.0/24 gateway 192.168.10.1
no ip route 192.168.50.0/24 gateway 192.168.10.1

# 新ルート追加(VLAN60経由)
ip route 192.168.20.0/24 gateway 192.168.60.2
ip route 192.168.40.0/24 gateway 192.168.60.2
ip route 192.168.50.0/24 gateway 192.168.60.2
# ※ VLAN10/30のルートは追加しない(到達不可が正しい)

# C-2. NAT descriptor変更
# ※ Phase 0で確認したnat descriptor番号に合わせて変更
# 内側アドレスレンジを確認し、VLAN60経由のサブネットをNAT対象に

# C-3. WireGuard NATポートフォワード確認
# UDP:54024 → 192.168.20.21 が維持されていることを確認
# TCP:443 → 192.168.20.21
# TCP:80 → 192.168.20.21

# C-4. フィルター設定
# RTXのWAN inbound/outbound フィルターを確認
# VLAN60サブネット(192.168.60.0/24)からの通信を許可するフィルタを追加
# 不要になったVLAN10向けフィルタを整理

# C-5. IPv6 RA制御
# LAN3以外のインターフェースでRA無効化を確認

# C-6. 設定保存
save

Phase D: 12XS ルーティング変更・ACL整理

# D-1. default route変更
conf t
no ip route 0.0.0.0 0.0.0.0 192.168.10.254
ip route 0.0.0.0 0.0.0.0 192.168.60.1

# D-2. 外部向けACL削除
# Phase 0で特定した外部向けACLを削除
# 例: VLAN50_EGRESS, VLAN20_INGRESS, VLAN40_EGRESS 等
# ※ VLAN間分離ACL(STORAGE保護等)は残すこと

# D-3. VLAN40 STP priority修正
spanning-tree vlan 40 priority 4096

# D-4. NTP設定(検査レポートで未設定と判明)
ntp server 192.168.10.254

# D-5. logging level修正
no logging buffered debugging
logging buffered 65536 informational

end
write memory

# D-6. 疎通確認
# DarkHero(VLAN40) → ping 8.8.8.8
# R640(VLAN20) → ping 8.8.8.8
# traceroute 8.8.8.8 で 192.168.60.1 が経路に見えることを確認

Phase E: VLAN10のXSからの切り離し

# E-1. 12XS VLAN10 SVI削除
conf t
no interface vlan 10
end
write memory

# E-2. 48TにVLAN10 SVI設定(管理用)
ssh admin@192.168.10.2
conf t
interface vlan 10
 ip address 192.168.10.1 255.255.255.0
 no ip route-cache
exit
end
write memory

# E-3. 確認
# VLAN10機器間ping → 成功
# VLAN10 → ping 8.8.8.8 → timeout(正しい)

Phase F: Po1をVLAN50専用に変更

# F-1. 12XS側
ssh admin@192.168.10.1
conf t
interface Port-channel1
 switchport mode access
 switchport access vlan 50
exit
interface range TenGigabitEthernet2/1/3 - 4
 switchport mode access
 switchport access vlan 50
exit
end
write memory

# F-2. 48T側(⚠️ この時点で48TへのSSH経路を確認)
# Po1がVLAN50になると、48TへのSSHはVLAN10経由のみ
# 48TのVLAN10 SVIにIPがあることを確認してからPo1を変更
ssh admin@192.168.10.2
conf t
interface Port-channel1
 switchport mode access
 switchport access vlan 50
exit
interface range TenGigabitEthernet1/1/3 - 4
 switchport mode access
 switchport access vlan 50
exit
end
write memory

# F-3. 確認
# show etherchannel summary → Po1がVLAN50 accessであること
# R640(192.168.50.10) → ping 192.168.50.1 (12XS VLAN50 SVI)

Phase G: 48T VLAN50 ACL設定

# G-1. VLAN50 ACL作成
# 以下のドメインのIPレンジを許可するACLを作成
# まずdigでIP確認:
dig +short archive.ubuntu.com
dig +short security.ubuntu.com
dig +short registry-1.docker.io
dig +short pypi.org
dig +short github.com
dig +short dl.google.com

# 48TにACL設定(IPベース)
ssh admin@192.168.10.2
conf t

ip access-list extended VLAN50_UPDATE_FILTER
 ! DNS (必須)
 permit udp 192.168.50.0 0.0.0.255 any eq 53
 permit tcp 192.168.50.0 0.0.0.255 any eq 53
 ! HTTP/HTTPS (許可先のみ — CDN利用のため広めに許可)
 permit tcp 192.168.50.0 0.0.0.255 any eq 443
 permit tcp 192.168.50.0 0.0.0.255 any eq 80
 ! NTP
 permit udp 192.168.50.0 0.0.0.255 any eq 123
 ! ICMP (ping許可)
 permit icmp 192.168.50.0 0.0.0.255 any
 ! 上記以外は拒否
 deny ip any any log

! ACL適用(VLAN50 SVI に適用)
interface vlan 50
 ip access-group VLAN50_UPDATE_FILTER in
exit
end
write memory

# ※ 注意: 上記ACLはHTTP/HTTPS全許可の暫定版です
# ドメインベースのフィルタはL3 ACLでは困難なため、
# ポートベース(443/80許可、それ以外拒否)で暫定運用し、
# 将来的にはRTX1300側でより細かいフィルタを追加する方針

Phase H: Squid廃止・R640整理

# H-1. Squid停止・無効化
sudo systemctl stop squid
sudo systemctl disable squid

# H-2. Chrome .desktop復元
sudo cp /usr/share/applications/google-chrome.desktop.bak \
       /usr/share/applications/google-chrome.desktop

# H-3. APT proxy削除
sudo rm -f /etc/apt/apt.conf.d/01proxy

# H-4. R640 netplan確認
# デフォルトルートがVLAN20 GW(192.168.20.1)経由であることを確認
cat /etc/netplan/*.yaml | grep -A5 routes
ip route show default

🔍 Phase Z: 最終検査(全項目実施すること)

全Phaseの作業完了後、以下のテストをすべて実施し結果を記録してください。

# === 外部接続テスト ===
# Z-1. VLAN40(DarkHero) → Internet
# DarkHeroにSSHできない場合はスキップし報告

# Z-2. VLAN20(R640) → Internet
ping -c 3 8.8.8.8
traceroute -m 5 8.8.8.8    # 192.168.60.1が経路に見えること

# Z-3. VLAN50(R640 UPDATE) → apt update
sudo apt update              # 成功すること

# Z-4. VLAN50 → 許可外アクセス
curl -s --connect-timeout 5 https://twitter.com  # 拒否されること

# Z-5. VLAN20 IPv6(WGクライアント確認が必要な場合はスキップ)
ping6 -c 3 google.com

# === 閉域テスト ===
# Z-6. VLAN10 → Internet(48T経由で確認)
# VLAN10機器から ping 8.8.8.8 → timeout であること

# Z-7. VLAN10 内部通信
# VLAN10機器間 ping → 成功すること

# Z-8. VLAN30 → Internet
# VLAN30にIPがあるR640(192.168.30.20)から
# ping -I 192.168.30.20 8.8.8.8 → timeout

# === サービス確認 ===
# Z-9. NFS
showmount -e 192.168.30.30
mount | grep nfs

# Z-10. WireGuard
sudo wg show wg0
# handshake時刻が最近であること

# Z-11. dnsmasq
sudo systemctl status dnsmasq

# Z-12. nginx
sudo nginx -t
sudo systemctl status nginx

# Z-13. Nextcloud
curl -sk https://cloud.k2-o.net/status.php | grep installed
# "installed":true であること

# Z-14. Collabora
sudo docker exec -u www-data nextcloud-stack-app-1 php occ richdocuments:activate-config

# Z-15. R640 IPv6 グローバルアドレス確認
ip -6 addr show | grep "scope global"
# グローバルIPv6が付いていないこと(VLAN10閉域化の効果確認)

# === スイッチ状態確認 ===
# Z-16. 12XS
ssh admin@192.168.10.1
show vlan brief
show ip route
show etherchannel summary
show spanning-tree summary
show access-lists

# Z-17. 48T
ssh admin@192.168.10.2
show vlan brief
show etherchannel summary
show access-lists

# Z-18. RTX1300
ssh admin@192.168.10.254   # VLAN60経由で到達確認
show config
show ip route
show nat descriptor address
show status tunnel 1

# Z-19. Po1確認
# 12XS: show interface Port-channel1 → VLAN50 access であること
# 48T: show interface Port-channel1 → VLAN50 access であること

# Z-20. Squid無効化確認
systemctl is-enabled squid    # disabled であること
systemctl is-active squid     # inactive であること

📄 最終出力物(すべて作成すること)

出力1: 作業報告書

作業の全ログ、各Phaseの実行結果、テスト結果をまとめた報告書を作成してください。

出力2: 物理作業待ちリスト

スキップした作業がある場合、その一覧と必要な物理作業の内容をまとめてください。

出力3: 完成後の全体構成ドキュメント(HTML)

これが最も重要な出力物です。

以下の内容を含む、WordPressカスタムHTMLブロックにそのまま貼れる完成HTML形式で出力してください:

  • <section class="mikyun-doc"> から開始
  • <style> を内包(背景透明、14px基準、ダーク/ライト対応)
  • h1/h2不使用、.title .section .sub を使用

含める内容:

  1. 新ネットワーク全体構成図(ASCII) — VLAN60を含む完成後のトポロジー
  2. 完成後の全VLAN設計一覧 — VLAN10〜60、999
  3. 完成後のIPアドレス台帳(全機器・全IF) — R640/SM/DH/RTX/12XS/48Tの全NIC
  4. 12XSポートマップ(完成版) — 全ポートの接続先・VLAN・モード
  5. 48Tポートマップ(完成版) — 全ポートの接続先・VLAN・モード
  6. RTX1300構成(完成版) — LAN/NAT/フィルター/ルーティング
  7. VLAN間通信マトリクス — どこからどこに通信できるか
  8. IPv6ポリシー表
  9. DNS設計表
  10. 装置別役割分担表
  11. 全体ルール集(設計の憲法) — DGWルール、DNS禁止ルール、Fabric原則等
  12. ACL一覧(12XS/48T/RTX) — 残存ACLの内容と適用箇所
  13. Squid廃止の記録 — 廃止日時、旧allowed-domains.txt、旧設定内容

出力ファイル名: mikyun-cloud-network-final-config.html


⚠️ エラー時の対応ルール

  1. SSH接続失敗: 3回リトライ。それでも失敗なら「物理作業待ち」としてスキップ
  2. コマンドエラー: エラー内容を記録し、代替コマンドを試行。解決不能なら報告して次のPhaseへ
  3. 通信断: Phase B/Cで通信断が発生した場合、2分待ってリトライ。復旧しなければロールバック実行:
    • 12XS: ip route 0.0.0.0 0.0.0.0 192.168.10.254 + Te2/0/1をtrunk VLAN10に戻す
    • RTX: load /flash/backup-pre-vlan60.config
  4. テスト失敗: 失敗したテスト項目を報告書に記録。致命的な場合(DarkHeroがInternet到達不可等)はロールバック

🏁 完了条件

以下がすべて満たされたら作業完了:

  • [ ] VLAN60新設・疎通確認済み
  • [ ] RTX NATがVLAN60経由で動作
  • [ ] VLAN10が48T内で完全閉域化(Internet到達不可確認済み)
  • [ ] Po1がVLAN50 accessに変更済み
  • [ ] Squid停止・無効化済み
  • [ ] 48T VLAN50 ACL適用済み
  • [ ] 12XS外部向けACL削除済み
  • [ ] 全テスト項目(Z-1〜Z-20)実施・結果記録済み
  • [ ] 最終構成ドキュメント(HTML)出力済み
  • [ ] 作業報告書出力済み

すべて完了したら「作業完了」と報告してください。お疲れ様です!