筆致についてはタイトル毎に統一されていません。あらかじめご了承ください。
本件はフィクションであり、実際に発生した事象に脚色を加えております。
シリーズ記事一覧：
【現場SE奮闘記 vol.1】社内ネットワークで「嵐」が起きたその日
目次
『夏の暑さに気がふれて、筆者は天狗になっているのだ。ゆるし給え。 - 太宰治 天狗』
私は会社の自席に踏ん反り返りながら思案に耽っていた。
BIG-IPとFortiGateを用いたネットワークの検証環境について。
こんなEasyな環境構築、自分にとっては障害にもなり得るはずはない。
自分以外に手が空いている人がいれば、その人の後学のために対応を依頼するのに。
ただのFortiGateでNATするだけの環境構築だ。
FortiGateをクラスタリング構成で構築するわけでも、vdomでネットワーク分割するわけでもなんでもない。
強いて言えば、BIG-IPのRouteDomain(ネットワークトラフィックを分割する機能）とvlan設定について気を付けないといけないくらいだ。
わずかばかりの達成感をため息として吐き出しながら、出来上がった簡易的な構成図を眺めた。
（※実際にはもっと複雑な構成ですが、かなり簡略化しています。）
（※ログ収集用サーバは現時点では構築対象外でした。）
これであれば、業務用のクライアントPCから④のBIG-IPの管理画面へのアクセスもできるし、⑦のVirtualServerにアクセスして、実サーバへのEtoEの通信も可能だ。
コーヒが喉奥に流れた後、舌に残る苦みの余韻に浸りながら、ディスプレイから目を離し、熱の残る手で鼻を触る。
渋々と椅子から立ち上がり、物理構成を構築するためにサーバラックへ向かう。
そういえば心なしか最近、鼻の先端が顔から遠のいている気がする。
未知との遭遇
検証環境の構築が完了し、想定していた通りの動作を確認した。驚きも達成感も感じない。設計通りだ。
検証環境を破棄しようと思った時、私の上司からチャットが届いた。
「BIG-IPからログ収集用サーバにログが届くか確認したい。ログ収集用サーバで受信対象のIP制限をかけているので、許可対象とするIPアドレスを教えてほしい。」
できるエンジニアはレスポンスが早い、と最近本で読んだ。
「BIG-IPの通信が外に出るときは、FortiGateの送信元インターフェースのIPに送信元NATされるので、192.168.100.203を許可していただけますか。」
「許可したのでログを飛ばしてみて」
FortiGateに外部抜けポリシーをつくり、BIG-IPにてイベントを発生させログを生成したのち、ログ収集用サーバにログインした。ログが保管されるディレクトリ内の、ファイル一覧の表示を試みる。
考えずとも手が勝手にコマンドを入力しているなか、今日の夕飯について思いを巡らせていた。
結果は見えている。
だがサーバからは期待した通りの結果は返ってこなかった。
ファイルが一つもない。ログが受信されたら、ファイルが生成されるはずだ。
自然と足を組むのをやめ、前傾姿勢になった。
実に面白い。
原因切り分け
まず想定通りのインターフェースからトラフィックが出て行っているのか確認する。
BIG-IPの仕様として、ログ送信時のみに使用するルーティングを定義することなどはできない。
念のため、スイッチポートからログ送信が行われていないか、確認する必要がある。
BIG-IPの管理インターフェースから、ポート番号514（ログ転送用のポート番号）かつログ収集用サーバのIPとの通信に該当するトラフィックに絞って、パケットキャプチャを行った。
tcpdump -eni eth0 host 192.168.100.202 and port 514 -X -vvv
出力されるIPアドレスとメッセージのいずれにも問題は無い。
次にFortiGateのトラフィック処理のログを確認した。トラフィックログを見ていたところ、違和感があった。port514のトラフィックはあったものの、想定していないIPアドレスが送信元となっていた。
BIG-IPからFortiGateを通過する外抜けの通信は②192.168.100.203（FortiGateの外部インターフェースのIPアドレス）にNATされると思っていたが、192.168.100.204（BIG-IPの管理ポートアクセス用の外部IPアドレス）にNATされていた。
念のため、ログ収集用サーバでもパケットキャプチャをしたところ、192.168.100.204から通信が来ていることを確認した。
私しかいないサーバルームで、自分の顔が熱くなっていることを実感した。これはサーバ群が発する排熱によるものではなく、あまりの不甲斐無さに羞恥していたためだった。
天狗となったエンジニアは鼻が折れるときに最も成長するのだ
この仕様については勿論知っていた。
FortiGateの送信元NAT/宛先NAT設定について
ポートフォワーディングを有効にしていない状態でVirtualIPを有効されていると、マップされるIPが送信元のとき外部IPへNATがかかる。
ログ収集用サーバへの通信が必要になった時に、これを考慮していなかった。
「別にログ収集用サーバの許可IP設定を上司に変えてもらえばいい」と、いつもなら思ったかもしれない。
しかし、お願いする相手が悪い。
会議や資料の準備に忙しいなか、こんな自分の凡々ミスのしりぬぐいをしてもらうのは大変に恐縮である。
また、「こんな仕様についても知らなかった」と思われるのがあまりにも恥ずかしく、正直誰にも言いたくなかった。
社内でもしばしば話に出てくる仕様であるし、私以外の同僚がこれに該当する事象に社内で遭遇した時にはこの仕様についての知識をひけらかしたこともある。
「この仕様はFortiGateを触るうえでも押さえておかなきゃね」や「この仕様は大事だから覚えておこうね」、「この話、マエニモアッタジャン」「ソレココノユーアールエルニカイテアルヨ」「ナ…
高速でこの仕様に関する記憶がよみがえってくる。
まずい、私がこの仕様について知らないと思われるのは非常にまずい。
上司の業務負荷を増やさず、また社内における私への評価を維持するべく192.168.100.203を送信元IPにして、ログ収集用サーバへリクエストを送るようにFortiGateの設定変更を行った。
IPプールに「192.168.100.203」を作成し、外抜け用のFortiGateのポリシーの送信元NAT設定に紐づける。
ログ収集用サーバにてログが取得されていることを確認した。
FortiGateのログでも、想定通り送信元NATされていた。よし、これで何事もなかったことにできる。
一晩寝て、会社の席についたとき鼻を触ったら、鼻が短くなっていることに気づいた。どうやら人間に戻れたらしい。
まとめ
今回は、FortiGateを使うエンジニアならば誰しもが覚えておかねばならない、必須仕様の話でした。
この記事を読んでくださった皆さんは、きっと覚え続けてくださると思います。
構築案件もこなし、天狗となっていた自分の鼻っ柱を折るよい機会だったと思います。
今回自分のGoodポイントとしては、以下があります。
・想定外の事象に対するアプローチが正確であったこと
・事象を見た時に仕様を思い出せたこと
検証環境で起きる想定外の事象が発生した時は、自身の原因切り分け能力が試される格好の機会であり、新たな知識（経験）を得られるすばらしいイベントです。想定していた動作とその実態が異なっていることが分かった時、それを良い機会だと受け止めてほしいなと思います。
今回の記事はエンジニアによくある、「完全に理解した」つもりだったが実はそうではなかったというお話になります。
鼻は何度も折れるので、次第に天狗にならなくなると思いがちです。しかし、折れるたびに強靭な鼻として伸びていくようで、この事象には一生付き合っていかねばならないのだと思う次第です。
記載されている会社名、システム名、製品名は一般に各社の登録商標または商標です。
当社製品以外のサードパーティ製品の設定内容につきましては、弊社サポート対象外となります。
