sidetech

(元)インフラエンジニアの寄り道メモ。

Fortigate200D v5.4.4 NATで混乱(主に私が)

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

 2017/05/31/222928
少しずつですが、Fortigate製品と打ち解けあってきたような?気がしています。
更に今回経験していたおかげな事も起きました。やっぱし色々やっておくのは大事だな。
 
Fortigatepolicytest
今回はNATの挙動を色々とテストしてみたっちゃよ・・・という内容です。
目隠しが多いけど、雰囲気で悟ってね。赤はWANで、緑がLANで、橙がAWSとのVPNって感じになっています。
AWSはBGP接続で2本のトンネルを張るのでポリシーに2つ乗っけています。デフォルトでは複数のインターフェースが指定出来ないので、指定できるように変更しておきました。
 
このポリシーをSSGやSRX,Paloalto的に眺めるとちょっと違和感があるんですが、心のどこかでこーいう仕様なのだと言い聞かせる必要があります。多分?ルーティングベース時のポリシーだから?という事なんですかね。
その割に、LANからWANへ通信させる場合はポリシーでNATを定義するという感じなんで混乱します[E:coldsweats01]。項番2がそれにあたるのですが、DENYを設定するとNATの項目も消されてしまうので、更にイミフな感覚になります。
項番1についてはWANからLANへのアクセスを禁止しています。これは普通ですね。
項番3と7についてはAWSとのVPNでの通信をDENYにしています。ただ、VPNを禁止しているのではなくて、VPNが成立した後のトンネル内のトラフィックをDENYしているという意味になるみたいですね。なのでVPNトンネルは接続したままです。

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

項番4で設定したマップ先のEC2サーバーのIPから項番6の処理をすると、VIPで割り当てたアドレスでNATマスカレードされて通信するので、この動きは楽ですね。SRXだと面倒な設定を入れなくちゃなんですが…。しかし言葉にすると大変だなこりゃ・・・。
 
とりあえず、StaticNATするときのお約束を覚えなくちゃならないのが今回ハマったところでした。
やはりNATをどのようにしたいのかと考えたときに、明示的にやらなければならない部分と勝手にやる部分とかあるので、Fortigateのお作法というか挙動を理解しておかないと、このポリシーは書きにくいなと思いました。
ただ、SSGもルーティングベースは同様な考え方だったような気がしたので、SSGに似ていると言われるのかもしれないですね。SSG時代はポリシーベースをメインで設計してたので、ルーティングベースのSSGの構築は結構嫌いwでした。
ただ、SSGのルーティングベースでVPN構築をするよりはFortigateのほうがとっつきやすかったかな?
 
ただ、今回Site to Site VPNでBGPを使う構成でしたが、一部CLIで挑まなければならず、更にGUIにその設定範囲が確認できないのがちょっとな~と思いました。
SRXGUIから確認できない領域がないわけではないのですが、確認する方法はあるにはあるので・・・。
何が言いたいかというと、結局隠れた設定が出てきちゃうという事は、CLIを基本としてConfigを見ておかないと痛い目見るぜって事なんだよね・・・。
ただ、救いはConfig構造が思ったよりもシンプルなんでSRXの難しいコマンドを覚えるよりは楽なのかもな~と思いました。
 
てことで、あと少し頑張って初心者卒業するぜっw