NETWORK DESIGN / 04

Routing・Securityはどう設計する？
通信経路とFirewall Policyの基本

ネットワーク設計シリーズ第4回。VLANとIPアドレスを決めた後は、通信をどの経路へ流し、どの通信を許可・拒否するかを設計します。本記事では、実際の検証環境で作成した設計書の構成を一般化しながら、Routing、Default Route、Security Zone、Firewall Policy、Traffic Flowをどのように整理するかを解説します。

公開日：2026.09.24 読了目安：9分 ネットワーク設計シリーズ 第4回 Stracto Technical Lab

NETWORK DESIGN SERIES

ネットワーク設計シリーズ

ネットワーク機器の知識を、設計書・構成図・設計項目へ落とし込む方法を整理します。

#01 / PUBLISHED設計書には何を書く？ #02 / PUBLISHED物理・論理構成図 #03 / PUBLISHEDVLAN・IP設計
#04 / CURRENTRouting・Security設計

Routing・Security設計とは

Routing設計は「通信をどこへ送るか」を決め、Security設計は「その通信を許可するか」を決めます。どちらか片方だけでは、ネットワーク全体の通信要件を表現できません。

設計書では、経路、Next Hop、Security Zone、Source / Destination、Service、Action、Logなどを分けて整理し、最後にTraffic Flowで通信全体を確認します。

ROUTING経路を決める

宛先Network、Next Hop、Default Routeなどを整理します。

SECURITY通信を制御する

Zone、Address、Serviceを条件に許可・拒否を設計します。

FLOW一連の通信で確認する

RouteとPolicyをつなげ、通信が成立するかを確認します。

1. 最初にRouting方式を決める

第1回で紹介した設計書では、Routing方式としてStatic Routingを採用し、インターネット向け通信にはDefault Routeを利用する方針を整理していました。

DESIGN POLICY — ROUTING
Routing Method
  Static Routing

Internet Traffic
  Default Route

Internal Networks
  Destination NetworkごとにNext Hopを定義

重要なのは、個別コマンドを書く前に「どの方式で経路を管理するか」を設計として決めておくことです。構成規模や冗長化要件によっては動的Routingを選ぶ場合もありますが、記事ではベース資料に合わせてStatic Routingを中心に扱います。

2. 宛先NetworkとNext Hopを表で整理する

Static Routingでは、どの宛先をどのNext Hopへ送るのかを表にしておくと、機器設定とレビューを行いやすくなります。

DestinationNext Hop用途
192.0.2.0/24198.51.100.1User Network
203.0.113.0/24198.51.100.2Management Network
0.0.0.0/0WAN RouterInternet / Other Destinations

公開記事ではDocumentation用アドレスを使用しています。実環境では、経路の重複、より具体的なRouteの優先、冗長化時の経路切り替えなども確認します。

3. Default Routeの出口を明確にする

インターネットなど個別Routeを持たない宛先へ通信する場合は、Default Routeを利用します。設計書では、どの機器がDefault Routeを持ち、どこをNext Hopにするかを明確にします。

Default Routeは便利ですが、通信の出口をまとめるため、FirewallやNATの配置と合わせて考える必要があります。

4. Security Zoneで通信境界を整理する

ファイアウォールでは、InterfaceやNetworkをSecurity Zoneへ所属させ、Zone間の通信としてPolicyを設計します。

Zone主な対象役割
TrustInternal Network内部ユーザーやサーバー側
UntrustWAN / Internet外部ネットワーク側
DMZ公開Server内部と外部の中間領域
MGMTManagement Network管理用通信を分離する領域

Zone名は製品や組織の設計基準によって異なりますが、「どのNetworkがどの信頼境界に属するか」を明確にすることが重要です。

5. Firewall Policyは条件を表形式で整理する

第1回で紹介した設計書では、Source Zone、Destination Zone、Source Address、Destination Address、Service、NAT、Log、ActionをPolicy表として整理していました。

DESIGN TABLE — FIREWALL POLICY
Src Zone | Dst Zone | Src Addr | Dst Addr | Service | NAT | Log | Action
Trust    | Untrust  | USER-NET | Internet | HTTPS   | -   | ALL | Accept
Trust    | Untrust  | ALL      | ALL      | ALL     | -   | ALL | Deny

Policyは「通信できるか」だけでなく、誰が・どこから・どこへ・何の通信を行うかを設計として表すものです。レビューしやすいよう、許可Policyと拒否Policyの意図が追える形にします。

6. NATはRouting・Policyと分けて整理する

NATを利用する構成では、経路設計やSecurity Policyと同じ表へ情報を詰め込みすぎず、必要に応じてNATの変換条件を別に整理します。

確認項目設計で見る内容
Original SourceどのNetworkからの通信を変換対象にするか
Original Destinationどの宛先向け通信か
Translated Addressどのアドレスへ変換するか
適用位置Router / Firewallなど、どの装置でNATするか
設計上の注意：NATは必ずファイアウォールで行うとは限りません。ネットワーク構成によっては外接ルータ側でNATを行い、ファイアウォールは主に通信制御を担当する構成もあります。

7. Traffic FlowでRouteとPolicyをつなげる

Routing表とFirewall Policy表を別々に作った後は、代表的な通信をTraffic Flowとして追います。これにより、経路上で必要なRouteとPolicyが揃っているかを確認できます。

  • 送信元のGatewayから次のHopへRouteが存在するか
  • Firewallで必要なZone間Policyが許可されているか
  • NATが必要な場合、想定した装置で変換されるか
  • 戻り通信が成立する経路になっているか
  • ログで通信結果を確認できる設計になっているか

8. 設計レビューは「経路」と「許可条件」を分けて確認する

通信できない原因はRoutingにある場合もあれば、Firewall Policyにある場合もあります。設計レビューでもこの2つを分けて確認すると、抜けを見つけやすくなります。

観点確認内容
RoutingDestination、Next Hop、Default Route、戻り経路
SecurityZone、Source / Destination、Service、Action、Log
NAT変換対象、変換先、実施装置
Traffic Flow通信経路上のRoute / Policy / NATの整合性

まとめ

Routing設計では通信の行き先を決め、Security設計ではその通信を許可する条件を決めます。設計書では、Route、Security Zone、Firewall Policy、NAT、Traffic Flowをそれぞれ整理し、最後に一連の通信として確認します。

「VLAN / IP → Gateway → Route → Security Policy → Traffic Flow」の順でつなげると、設計内容と機器設定の対応関係を追いやすくなります。

これで、ネットワーク設計シリーズ #01〜#04として、設計書の全体像から構成図、VLAN・IP、Routing・Securityまで一通りつながる構成になります。

記事について

本記事は、Stractoが保有していたネットワーク検証環境の設計書に含まれるRouting、Security Zone、Firewall Policy、Traffic Flowの項目を基に、公開可能な内容へ一般化して構成しています。

元の設計書に含まれる実際のIPアドレス、機器名、Interface、Policy名などは掲載せず、記事内ではDocumentation用アドレスと一般名称へ置き換えています。