Home・Work・DMZ・IoTを分けた自宅VLAN設計 #3｜k3s・NAS・DMZ三層
この記事で分かること
家族用ネットワークと、個人の実験環境をなぜ分けたのか
Home / Work / Guest / IoT / Management / Storageを別の信頼境界にした理由
k3sとNASを同じ「サーバ置き場」として扱わなかった理由
DMZをEdge / App / DBの三層へ分けた理由
このVLAN設計が、後のFirewall・Proxy・境界防御へどうつながるのか
（※前回の【物理配線編】をまだ読んでいない方は、ぜひこちらから！）
ごく普通の一般家庭（物理10G・k8s 8台）のネットワークを大更改した話 #2【物理結線編】
前回は、10G FabricとFortiGateを物理的にどう組み合わせたかを書いた。
今回は、その上に「どこまでを同じ世界として扱うか」という境界線を引く話になる。
このネットワーク更改で一番やりたかったのは、VLANをたくさん作ることではなかった。
家族のネットワークの平和と、俺の実験場を分けること。
これが出発点だった。
家の中には「壊していい場所」と「壊してはいけない場所」がある
自宅には、家族が普通に使うPC、スマホ、TV、ゲーム機がある。
その横で自分は、ESXi、k3s、DB、Proxy、Local LLM、検証用VM、外部公開Serviceを触る。
設定を変える。壊す。戻す。また作る。
自分にとっては実験でも、家族から見ればInternetは生活インフラだ。
TVが見られない。スマホがWi-Fiにつながらない。動画が止まる。
そんな状態を「Labだから仕方ない」で済ませるわけにはいかない。
だから最初に考えたのは、変更の影響範囲を分けることだった。
```
家族が使う場所
└─ 壊してはいけない
自分のLab / Server
└─ 壊しても戻せる
外部公開領域
└─ 侵入される前提で境界を作る
```
この3つを混ぜない。
それがVLAN設計の芯になった。
最初はHome / Lab / DMZくらいで考えていた
最初から細かいVLANを十数個作りたかったわけではない。
大きくはHome / Lab / DMZくらいで考えていた。
しかし実際に機器を置いていくと、この3つでは粗すぎた。
Homeの中にも家族端末と会社PCがある。
Labの中にも管理系、Storage、k3s、DBがある。
DMZにも入口とApplicationとDatabaseがある。
さらにIoTやGuestまで出てくる。
そこで、「どの機器か」ではなく「誰が管理し、何を信用し、何を守りたいか」で分けることにした。
HomeとWorkは「同じPCだから一緒」ではない
Homeには家族のPCや私物端末がいる。
Workには会社から貸与された端末がいる。
物理的には同じ家にあるが、管理主体が違う。
会社PCは企業側のPolicyやEDRで管理され、自宅PCは自分が管理する。
だから、同じ種類の端末でも同じ信頼境界に置く理由はない。
HomeとWorkを分けたのは「会社PCが危険だから」ではない。
むしろ会社PCはEndpoint側のSecurityが強い。
ただし、自宅側とは管理責任が違う。
だったらNetwork上も別にした方が分かりやすい。
GuestとIoTはさらに信用度を下げる
Guestは基本Internetだけでいい。
NASもServerもManagement Networkも必要ない。
```
Guest
↓
Internet
```
IoTは少し違う。
TV、AV機器、家電、各種Deviceは便利だが、PCやServerほど自分で中身を管理できない。
Firmware更新頻度もSupport期間もまちまちだ。
だからIoTは、便利だから使う。ただし内部LANと同じ信用度では扱わない。
ここで重要なのは、VLANを分けること自体ではない。
IoTからどこへ新しい通信を開始させるかを制限できる境界を作ることに意味がある。
同一VLAN内のL2通信まで止めたいなら、AP / Switch側のIsolation機能が必要になる。
VLANは魔法の隔離箱ではなく、Firewallで判断できる境界線を作る道具だ。
Managementは「止まると全部困る場所」
ManagementにはESXi / vCenter、Network機器管理、AD / DNS、Monitoring、Logなど、障害時に真っ先に使いたいものがいる。
ここをHomeやIoTと同じ場所へ置くと、何かあった時に管理基盤まで巻き込まれる。
自宅Labでは新しいものを入れるたびに設定を変える。
だからこそ、管理する側と管理される側を分けたかった。
実験中のVMを壊してもいい。
でも、そのVMを直すためのDNSや監視まで同時に見えなくなるのは困る。
Managementは速い場所ではなく、最後まで残っていてほしい場所として分けた。
NASは「Serverの一員」ではなく、残したいデータの置き場
Storageも同じ理由で分けた。
k3sやVMは作り直せる。Applicationも再Deployできる。
でもNASに置いたデータやBackupは、同じ感覚で壊したくない。
だから、Compute / k3sとStorage / NASの間に境界を作った。
k3s NodeからNFSが必要なら、その通信を通す。
User PCからSMBが必要なら、その通信を通す。
少なくとも設計思想としては、**計算する場所と、残す場所を分ける**という考え方だった。
DMZは一つではなく、三層に分けた
外部公開領域は、さらに強く境界を意識した。
最初から、
```
Internet
↓
Edge / Proxy
↓
App / k3s
↓
DB / Backend
```
という三層に分けた。
理由は単純。
入口を突破された時に、そのままDBまで行かせたくなかったから。
Edge / ProxyにはInternetから最初に触られる役割を置く。
HAProxy、Squid、c-icap / ClamAV。
その後ろにApplication / k3s。
さらにその後ろにDB / Backend。
全部を同じDMZ VLANへ入れてしまえば、Web入口を一つ突破した時点で横移動しやすくなる。
それより、最初から境界を作っておく。
```
Internet
↓
[ Edge ]
↓ 必要な通信だけ
[ App ]
↓ 必要な通信だけ
[ DB ]
```
当初の狙いは、「侵入させない」だけではなく、「一層抜かれても次へ自由に進ませない」ことだった。
この考え方が、この後のHAProxy / Squid / c-icap / ClamAVによる境界防御へつながっていく。
k3sをDMZ App側へ置く理由
k3sはApplicationを実行する場所だ。
Internetに公開するServiceも動く。
でもPodやNodeを直接Internetへ晒したいわけではない。
外部通信はまずEdge側で受け、必要な通信だけApp側へ渡す。
```
Internet
↓
Edge / Proxy
↓
k3s Ingress
↓
Service
↓
Pod
```
これならNetworkの入口とApplication実行基盤を別の境界として扱える。
後で障害が起きても、Internetから来ていないのか、Edgeで止まったのか、Ingress以降で止まったのかを分けて考えやすい。
VLAN設計はSecurityだけではなく、障害範囲を切るためでもある
VLANというとSecurityの話になりやすい。
でも自宅で実際に重要だったのは、障害の影響範囲を切れることだった。
Labで設定を変える。k3sを壊す。Proxyを変える。DBを触る。
それでもHome側はできるだけ巻き込まない。
自分の実験を止めないためにも、家族の生活を止めないためにも、境界が必要だった。
だからこのNetworkでは、Security Boundary = Failure Boundaryでもある。
「信用しないから分ける」だけではない。
「壊した時に一緒に倒れないように分ける」。
ここが自宅Networkではかなり重要だった。
実装は設計思想どおりに100%固定されているわけではない
ここまでが設計の狙い。
長く運用しているとPolicyは変わる。
一時的に広い許可を入れたり、移行時の設定が残ったりする。
だから現行Configを見れば、最初に描いた理想どおりではない場所もある。
でも、この#3の主役はConfigの監査ではない。
大事なのは、なぜ境界を作ったのか。
その思想があれば、後からConfigを見て「ここは意図どおり」「ここは運用で広がった」「ここは戻した方がいい」と判断できる。
設計思想がなければ、Configはただの設定一覧になる。
#3で境界を決め 、#4で越え方を決める
ここまででHome、Work、Guest、IoT、Management、Storage、Edge、App、DBという「部屋」を分けた。
でも部屋を作っただけではNetworkは使えない。
次に必要なのは、どの部屋から、どの部屋へ、どうやって通信を通すかだ。
10Gの性能を殺したくない。
でもSecurity BoundaryはFortiGateで見たい。
Internet EdgeはUCG-Fiberへ任せたい。
内部通信を誤って上流へ送るのも避けたい。
外部公開は直接Applicationへ入れたくない。
その相反する要求をRouting / PBR / NAT / VIPでどう成立させたか。
それが次の話になる
【連載インデックス】
⏪ 前の記事：ごく普通の一般家庭（物理10G・k8s 8台）のネットワークを大更改した話 #2
⏩ 次の記事：ごく普通の一般家庭（物理10G・k8s 8台）のネットワークを大更改した話 #4【ルーティング・NAT設計編】
