ITの窓辺から

三流IT技術者の日常

Fortigateのネットワークインターフェース設計 その1

ネットワーク設計ではないです。ネットワークインターフェース設計です。
Fortigateをネットワーク構成に組み入れるにあたり、Fortigateとしてどのような設計を行うのが適切なのかを検討することを目的としています。バリバリにFortigate固有機能というか仕様の話なので、ルーティングプロトコルのような汎用的なネットワーク構成に関する話はこの記事のスコープ外です。ルーティング周りは性能や細かい制御はともかく割と素直な動きをするような気はしています。個人的にはミッドレンジ以下のFortigateでルーティング的に複雑なことはなるべくしたくはないのですが。

多くのFortigateを一つの設計の中で導入、運用する機会を持てる人は多くないと思います。(私もそうです)なので、数ヶ月、あるいは数年に1回の構成変更の時はいつも操作方法に困惑しています。急にFortigateのことを書き始めたのは仕事でFortigateに習熟する必要が出たためです。なので、ある種の備忘録も兼ねています。ある程度長い話になりそうな気もするので、複数回に分けて記事を書いていきます。尚、この記事に限らないのですが個人レベルでの検証結果を書いているだけなので、実装にあたっては検証、有識者の助言、有償のサポートのよる支援等を活用して十分に注意をすることを推奨します。ソフトウェアバージョンはv6.0.7 build0302のFortigateです。

 現在Fortigateのネットワークインターフェース設計を行う上で考慮する非通用のある主要項目は以下の通りです。

  • 物理ポート
  • VLAN
  • リンクアグリゲーション
  • ゾーン
  • VDOM
  • バーチャルワイヤーペア
  • オペレーションモード
  • SD-WAN

ネットワークインターフェース設計の重要性

運用中のネットワークインターフェース構成変更は一般的にコストが高く、導入段階でのネットワークインターフェース設計は重要です。稼働中の構成変更を利用者に気が付かれないように行うことはネットワーク屋さんの技術の見せ所ではありますが、そもそも十分な検証環境がないと難しいでしょう。

Fortigateは要望に対する実現手段がいくつか用意されており、手段によっては拡張性が乏しい構成になってしまったり、構成変更の手間が非常に大きくなってしまうことがあります。そしてこれからの記事ではこれらの問題に対してFortigateの実装が具体的にどうなのさ、というものを検証していきます。

インターフェースの入れ子関係

装置の本来の役目であるファイアウォールポリシを設定にあたってですが、L3モード(NATモード)のFortigateのファイアウォールポリシを設定する時には送信元インターフェースと送信先インターフェースを指定します。トランスペアレントモードの場合はまた違うのですが、物理ポートに影響してきます。このあたりはまた別途。とにかくこの項目ではL3モードに関して書きます。

指定可能なインターフェースは物理ポート、VLAN、リンクアグリゲーション、ゾーンです。これはこれで普通の話なのですが、ややこしいのはこれらのインターフェースに入れ子関係があることです。(※検証可能なFortigateではリンクアグリゲーションが設定できませんでした。多分物理ポートと同じだと思いますが・・・。この記事では物理ポートと同義として記載を省きます。)入れ子関係とインターフェースの制限は下記の通りです。

  • ゾーンには物理ポートとVLANのどちらかまたは両方を含められる。
  • ゾーンは作らなくても良い。
  • 物理ポートにはVLANを含められる。というよりVLANは物理ポートに所属させなければならない。
  • 物理ポートは絶対に設定が必要。
  • VLANは作らなくても良い。

ファイアウォールポリシを設定する際にインターフェースを選択するわけですが、ゾーンに所属させたインターフェースは候補に挙がりません。これを踏まえていくつかの構成で検証してみました。

検証

検証構成1

VLAN100を物理ポート1に所属させる。

検証構成2
ポリシパターンA : (ポリシ先頭の数字はGUIのポリシの並びを示す)

1 : From:物理ポート1, To:物理ポート2, permit

結果

172.16.10.1 → 172.16.20.254 : OK

172.16.100.1 → 172.16.20.254 : NG

 

ポリシパターンB :

1 : From:VLAN100, To:物理ポート2, permit

結果

172.16.10.1 → 172.16.20.254 : NG

172.16.100.1 → 172.16.20.254 : OK

実はポリシパターンAではどちらもOKになると期待していました。

 

検証構成2

ゾーンAにVLAN100を所属させる。物理ポート1はゾーンAに所属させない。

検証構成2


ポリシパターンA :

1 : From:物理ポート1, To:物理ポート2, permit

結果

172.16.10.1 → 172.16.20.254 : OK

172.16.100.1 → 172.16.20.254 : NG

 

ポリシパターンB :

1 : From:ゾーンA, To:物理ポート2, permit

結果

172.16.10.1 → 172.16.20.254 : NG

172.16.100.1 → 172.16.20.254 : OK

検証構成3

物理ポート1をゾーンAに所属させる。VLAN100はゾーンAに所属させない。

検証構成3


ポリシパターンA :

1 : From:ゾーンA, To:物理ポート2, permit

結果

172.16.10.1 → 172.16.20.254 : OK

172.16.100.1 → 172.16.20.254 : NG

 

ポリシパターンB :

1 : From:VLAN100, To:物理ポート2, permit

結果

172.16.10.1 → 172.16.20.254 : NG

172.16.100.1 → 172.16.20.254 : OK

 

結局なんなのか

素直といえば素直な結果でした。ただ、VLANを物理ポートに所属させたからと言って物理ポートに関するファイアウォールポリシがVLANを包含するわけでもなく、継承するわけでもないというのは意外でした。ゾーンについても同じようなことが言えますが。

そういうわけで、インターフェース設定を入れ子にしても完全に別物として取り扱われ、子供のインターフェースについても個別にファイアウォールポリシの設定する必要がある、というのが今回の結論です。

次の記事ではVDOMやバーチャルワイヤーペアに関する話に続きます。