10Gを殺さずFortiGateを使うルーティング/NAT設計 #4｜UCG-Fiber・PBR・VIP・二段NAT

lucky_una

2026年3月5日 14:57

10G回線を活かしつつFortiGate 60Fを残した理由
UCG-FiberとFortiGateの役割をどう分けたか
Transit / Static Route / PBRを使う理由
内部通信をInternet向けPBRへ吸わせない考え方
FortiGate側SNATとUCG-Fiber側NATが重なる経路
外部公開をUCG-Fiber→FortiGate→HAProxyへ渡す理由

（※前回の【Home・Work・DMZ・IoTを分けた自宅VLAN設計】をまだ読んでいない方は、ぜひそちらから！）
⏪ Home・Work・DMZ・IoTを分けた自宅VLAN設計 #3｜k3s・NAS・DMZ三層

#3では、家族の生活環境と自分の実験場を分けるために、Home / Work / IoT / Management / Storage / DMZへ境界を作った。

でも、境界を作っただけではNetworkは使えない。

次に必要なのは、必要な通信だけ、その境界をどう越えさせるかだった。

しかも我が家には一つ厄介な条件があった。

10G回線を活かしたい。でもFortiGate 60Fも使いたい。

この二つは、そのままでは相性が良くない。

1GのFortiGateをInternetの先頭には置けなかった

Internet回線側は、NTTの小型ONUをUCG-Fiberの10G SFP WANへ直接入れる構成にした。

理由は単純で、10G回線を1Gの装置で最初から絞りたくなかったから。

もし、

```
Internet
   ↓
FortiGate 60F
   ↓
UCG-Fiber
   ↓
LAN
```

の順にすれば、FortiGateの1G Interfaceが最初のボトルネックになる。

それでは、せっかく10G対応のONUとUCG-Fiberを入れる意味が薄い。

だからInternet EdgeはUCG-Fiberへ任せる。

一方で、内部の信頼境界ではFortiGateのFirewall / UTM / Policyを使いたい。

ここで役割を分けた。

```
Internet Edge / WAN
↓
UCG-Fiber

Internal Security Boundary
↓
FortiGate 60F
```

速度を受ける装置と、信用境界を判断する装置を分けた。

これがRouting設計の出発点だった。

East-Westを全部FortiGateへ通さない

もう一つ避けたかったのが、Server間の大量通信まで全部1G Firewallへ流すことだった。

ESXi、k3s、NAS、DB。

この辺りは、内部でかなり通信する。

同一L2内で完結できるものまでFortiGateへ上げると、10G Fabricを作った意味がなくなる。

だから、

```
同一VLAN内のEast-West
↓
10G L2 Fabricで完結

信頼境界を跨ぐ通信
↓
FortiGateで判断
```

とした。

これは「Firewallを避ける」のではない。

Firewallで見る必要がある境界だけを、意図してFirewallへ通すという考え方だ。

UCG-FiberとFortiGateの間にTransitを置く

UCG-FiberとFortiGateは別の役割を持つ。

その二つをつなぐために、Transit Networkを置く。

概念的にはこうなる。

```
Internal VLAN
     ↓
FortiGate
     ↓
Transit
     ↓
UCG-Fiber
     ↓
Internet
```

FortiGate側のDefault RouteはUCG-Fiber側を向く。

そしてFortiGateをGatewayとして使うVLANからInternetへ出す通信は、PBRでUCG-Fiber側へ送る。

PBRは「どこへ送るか」より「何を送らないか」が難しい

Policy Based Routingは便利だ。

例えば、

```
このVLANから来た通信
↓
UCG-Fiberへ送る
```

と書けば、Internetへの出口を固定できる。

でも、ここで雑に0.0.0.0/0へ投げると、内部通信まで上流へ吸われる。

実際に監視やSyslogを組んだ時、この罠が効いた。

本来は内部のZabbix / Log Serverへ行くべき通信まで、PBRに乗せればUCG-Fiber側へ向いてしまう。

だから現行の考え方は、

```
内部宛通信
↓
PBRから除外
↓
通常Routing

Internet宛通信
↓
PBR
↓
UCG-Fiber
```

になる。

FortiGateのPolicy Routeでは、内部宛を除外するRuleを先に置く。

監視Server宛には、実際に`Stop PBR`というコメントを付けたRuleもある。

ここで初めて、#3で作った境界を壊さずにInternetへ出せる。

NATは一段ではない

FortiGateを通ってInternetへ出る経路では、FortiGate側のFirewall PolicyでSource NATするものがある。

その先でUCG-FiberがWAN側NATを行う。

つまり経路によっては、

```
Client / Server
   ↓
FortiGate SNAT
   ↓
UCG-Fiber NAT
   ↓
Internet
```

という二段NATになる。

二段NATは美しい構成ではない。

でも、10G WANをUCG-Fiberで受けながら、内部ではFortiGateをSecurity Boundaryとして残すという要件から生まれた。

そしてこのNATは、後でSquidのSource IPが同じに見える問題にもつながる。

Networkの都合は、Application Layerの見え方まで変える。

その話は#10で扱う。

外から入る通信は逆方向に段階的に渡す

Inboundはさらに慎重にした。

外部公開の80/443を、いきなりk3sやApplication VMへ投げない。

入口は、

```
Internet
   ↓
UCG-Fiber
   ↓
FortiGate
   ↓
HAProxy
   ↓
Proxy / Inspection
   ↓
k3s / Application
```

と段階的にする。

UCG-FiberはInternet Edgeとして必要なPortだけ次へ渡す。

FortiGateはVIPとFirewall PolicyでHAProxyへ渡す。

HAProxy以降は、Host / SNI / BackendといったApplication寄りの判断へ進む。

ここでも考え方は#3と同じ。

境界を一気に飛び越えさせない。

一層ずつ役割を持たせる。

そうすると障害時にも、

UCG-Fiberまで来たか
FortiGateまで来たか
VIPを通ったか
HAProxyへ届いたか
その先のProxy / Ingressへ行ったか

と切り分けられる。

二台のL3機器がいると、往路と復路が重要になる

UCG-FiberとFortiGateの両方がL3に関わる構成では、非対称Routingが一番怖い。

FortiGateはStateful Firewallなので、行きと帰りを一つのSessionとして追えない経路はトラブルの元になる。

だから、

ClientのDefault Gateway
FortiGateのStatic Route
PBR
PBR除外
Source NAT
UCG-Fiber側のRoute / NAT
戻り経路

をセットで考える。

「pingが通った」だけで終わらせず、

そのPacketがどの経路で行き、どこから戻るのかを説明できるか。

ここまで見て初めて、二段構成が安定する。

この構成で守りたかったもの

RoutingやPBRの話だけを見ると、かなり面倒な構成に見える。

でもやりたかったことはシンプルだった。

10Gの速度を殺したくない。

家族のNetworkとLabは分けたい。

内部の重要境界はFortiGateで見たい。

外部公開は一段ずつ中へ入れたい。

この4つを同時に成立させようとした結果が、UCG-Fiber + FortiGate + Transit + PBR + NAT + VIPだった。

次回は、その経路を支えるL2側へ戻る。

10G×2 LAG、1G×4 LACP、RSTP。

そして「Link Upしているのに安定しない」という10G特有の面倒さへつながっていく。

【連載インデックス】
⏪ Home・Work・DMZ・IoTを分けた自宅VLAN設計 #3｜k3s・NAS・DMZ三層

⏩ 次の記事：ごく普通の一般家庭（物理10G・k8s 8台）のネットワークを大更改した話 #5 【LACP/STP設計編】