Fortigate200D v5.4.4 NATで混乱（主に私が）

Fortigate初心者なので嘘言っていたらご容赦を・・・ではなくてご指摘を[E:coldsweats01]

 2017/05/31/222928

少しずつですが、Fortigate製品と打ち解けあってきたような？気がしています。

更に今回経験していたおかげな事も起きました。やっぱし色々やっておくのは大事だな。

 

今回はNATの挙動を色々とテストしてみたっちゃよ・・・という内容です。
目隠しが多いけど、雰囲気で悟ってね。赤はWANで、緑がLANで、橙がAWSとのVPNって感じになっています。
AWSはBGP接続で２本のトンネルを張るのでポリシーに２つ乗っけています。デフォルトでは複数のインターフェースが指定出来ないので、指定できるように変更しておきました。

 

このポリシーをSSGやSRX,Paloalto的に眺めるとちょっと違和感があるんですが、心のどこかでこーいう仕様なのだと言い聞かせる必要があります。多分？ルーティングベース時のポリシーだから？という事なんですかね。

その割に、LANからWANへ通信させる場合はポリシーでNATを定義するという感じなんで混乱します[E:coldsweats01]。項番２がそれにあたるのですが、DENYを設定するとNATの項目も消されてしまうので、更にイミフな感覚になります。

項番１についてはWANからLANへのアクセスを禁止しています。これは普通ですね。

項番３と７についてはAWSとのVPNでの通信をDENYにしています。ただ、VPNを禁止しているのではなくて、VPNが成立した後のトンネル内のトラフィックをDENYしているという意味になるみたいですね。なのでVPNトンネルは接続したままです。

項番４，５についてはStaticNATをしています。それもLAN側でバーチャルIPというのを持たせてマップしているアドレスはAWS側のEC2サーバーをターゲットにしています。StaticNATというぐらいなので、ポリシーにNATのフラグをEnableにしたい信条になるのですが、どうやらStaticNATは内部で勝手にNAT処理をするらしく、ポリシー側でNAT設定を入れてしまうと上手く通信しません[E:coldsweats02]。最初このノリが判らなかった。偶々ディーラーのエンジニアからのメールメッセージがヒントになって分かりました。

 

項番６については、AWSのEC2側からNATしてLAN側へ通信するというのをやっています。

項番４で設定したマップ先のEC2サーバーのIPから項番６の処理をすると、VIPで割り当てたアドレスでNATマスカレードされて通信するので、この動きは楽ですね。SRXだと面倒な設定を入れなくちゃなんですが…。しかし言葉にすると大変だなこりゃ・・・。

 

とりあえず、StaticNATするときのお約束を覚えなくちゃならないのが今回ハマったところでした。
やはりNATをどのようにしたいのかと考えたときに、明示的にやらなければならない部分と勝手にやる部分とかあるので、Fortigateのお作法というか挙動を理解しておかないと、このポリシーは書きにくいなと思いました。

ただ、SSGもルーティングベースは同様な考え方だったような気がしたので、SSGに似ていると言われるのかもしれないですね。SSG時代はポリシーベースをメインで設計してたので、ルーティングベースのSSGの構築は結構嫌いｗでした。
ただ、SSGのルーティングベースでVPN構築をするよりはFortigateのほうがとっつきやすかったかな？

 

ただ、今回Site to Site VPNでBGPを使う構成でしたが、一部CLIで挑まなければならず、更にGUIにその設定範囲が確認できないのがちょっとな～と思いました。
SRXもGUIから確認できない領域がないわけではないのですが、確認する方法はあるにはあるので・・・。
何が言いたいかというと、結局隠れた設定が出てきちゃうという事は、CLIを基本としてConfigを見ておかないと痛い目見るぜって事なんだよね・・・。

ただ、救いはConfig構造が思ったよりもシンプルなんでSRXの難しいコマンドを覚えるよりは楽なのかもな～と思いました。

 

てことで、あと少し頑張って初心者卒業するぜっｗ