こんにちは、レムシステム株式会社のエンジニア、小村(@system_kom)です。今回は、静岡県内に複数の事務所と工場を持つ製造業様で、YAMAHA RTXシリーズのルーターをFortiGate 90Gへ更改した事例をご紹介します。
この環境では、東京の営業所・大阪の拠点（Main／Backup）・AWSの業務システムと、IPsec VPNが合計5本稼働しています。対向はすべてYAMAHA製ルーターとAWSで、静岡側だけがFortiGateに変わる構成です。同じメーカー同士では問題にならなかった実装の違いが、どこで表面化するのか。事前検証と稼働後対応で得られた知見をまとめました。
導入前の構成と課題
| 課題 | 内容 |
|---|---|
| 出入口の防御 | パケットフィルタのみ。ウイルス・危険サイト対策は端末任せ |
| ログ・証跡 | ルーター内蔵ログのみで、インシデント時の調査が困難 |
| リモートアクセス | 社外から社内・他拠点へ接続する手段がない |
| 移行リスク | 拠点間VPN5本＋AWSとのBGPが稼働中。対向側の作業も伴う |
設計のポイント
| 項目 | 設計内容 |
|---|---|
| 機器 | FortiGate 90G（NATモード、FortiOS 7.6系） |
| UTM | アンチウイルス・Webフィルタ・IPS・アプリケーション制御を適用。SSL検査は証明書検査（ディープ検査なし） |
| 拠点間VPN | 既存の5トンネルを移行。大阪・AWSはMain／Backupの冗長構成を維持 |
| AWS接続 | BGPを移行し、リモートVPN用アドレスプールも追加で広報 |
| リモートアクセス | FortiClientによるダイヤルアップIPsec。スプリットトンネルで各拠点・AWS宛も通す |
| ログ | 90Gは内蔵ストレージがないため、FortiGate Cloudで1年保管 |
| 管理アクセス | HTTPS／SSHのみ。悪意あるサーバー・Torノード発の自機宛通信をlocal-inポリシーで遮断 |
リモートアクセスは、将来のFortiOSでSSL-VPNトンネルモードが廃止される流れを踏まえ、最初からIPsec方式で設計しました。
事前検証で見つかった相互接続のポイント
対向のYAMAHA RTXの代わりに弊社のRTX1210を、AWSは評価用のサイト間VPNを用意し、FortiGateの本番設定のまま接続試験を行いました。見つかったのは次の4点です。
| # | 事象 | 原因 | 対策 |
|---|---|---|---|
| 1 | アグレッシブモードのID認証が通らない | RTXのkey-id型の名前は、文字列をそのまま送らない実装だった | RTX側のID種別をfqdnに変更 |
| 2 | フェーズ2で「missing IDci field」 | FortiGateのフェーズ2はセレクタ指定のため、対向がIDペイロードを送る必要がある | RTX側で ipsec ike local id／remote id を明示 |
| 3 | フェーズ2のカプセル化方式が不一致 | 双方グローバルIP直結なのに、RTXがNATを誤検出 | 対向アドレスの明示などでNAT-T誤検出を回避 |
| 4 | リモートVPN用プールがBGPで広報されない | BGPのnetworkは同じプレフィックスの経路が実在しないと広報されない。クライアント接続時は/32しか生成されない | プールの/24をブラックホールルート（distance 250）で常設 |
FortiGate側の設定だけで回避できないかも試しましたが、1と2は対向側の変更が必須でした。そこで拠点側への依頼事項を数行のコマンドに絞り込み、切替手順書に事前作業として明記しています。
切替当日の進め方
FortiGateの設定は全て事前投入し、当日は物理的な差し替えのみとしました。
- 本社でルーターを撤去し、FortiGateを結線（固定グローバルIPは変更なし）
- AWS・大阪BackupのVPNが自動で確立することを確認
- 東京拠点にRTX側の設定変更を依頼し、トンネル確立を確認
- リモートVPNで本社・各拠点への疎通を確認
- UTM・管理アクセス・ログ送信などの総合確認
東京・大阪の対向ルーターを変更した後に本社を切り戻すと、対向も元に戻す二重作業になります。そのため、切り戻し判断は手順1〜2の段階で行うルールを事前に決めておきました。
稼働後に見つかった事象と恒久対応
検証環境だけでは捉えきれなかった事象が、本番稼働後に3件発生しました。いずれもIKEデバッグとSAカウンタを追い、根本原因から対処しています。
| 事象 | 原因 | 恒久対応 |
|---|---|---|
| 大阪Mainのフェーズ2が対向発の再ネゴシエーション時だけ失敗 | RTX側が具体的なセレクタを提示し、FortiGate側の0.0.0.0/0と不一致 | 具体セレクタのフェーズ2を追加し、0.0.0.0/0と並存させる |
| 東京トンネルが約64秒周期でSA削除・再確立 | RTXのkeepaliveがYAMAHA独自のheartbeat方式で、FortiGateが応答しない | RTX側keepaliveをDPD方式に変更（ipsec ike keepalive use … on dpd） |
| リモートVPNから東京宛の戻り通信が時々送出されない | フェーズ2セレクタが2組あり、RTXが送信に使うSAがリキー順序で入れ替わっていた | セレクタを1組（0.0.0.0/0⇔東京LAN）に統合し、寿命も28800秒に揃える |
3件目は、お客様から「トンネルを1本追加してはどうか」というご提案もいただきました。ただ、同じピア間で2本目のIKE SAを持つと監視やリキーが複雑になります。そこで、大阪で実施した対応と同じ考え方でセレクタを統合しました。一連の対応で、IKE SAの再確立は1日約350回から約6回まで減っています。
メーカーをまたぐ更改では、旧構成では同じメーカー同士で「たまたま噛み合っていた」部分が表面化します。今回の教訓は、keepaliveの方式とフェーズ2セレクタの扱いを、対向機種ごとに事前に確認することです。
導入効果
| 項目 | 導入前 | 導入後 |
|---|---|---|
| 出入口の防御 | パケットフィルタのみ | AV・Webフィルタ・IPSで入口防御 |
| リモートアクセス | なし | 約30名が本社・各拠点・AWSへ接続可能 |
| ログ保管 | 本体内蔵（限定的） | FortiGate Cloudで1年保管 |
| VPNの安定性 | — | IKE SA再確立 約350回/日 → 約6回/日 |
レムシステムのUTM・VPN導入支援
レムシステムでは、FortiGateをはじめとするUTMの導入から、YAMAHA RTXを含む拠点間VPN・AWSとのサイト間VPNの設計、稼働後の運用までを一貫して対応しています。「拠点間VPNがあるのでルーターを替えられない」とお悩みの企業様も、まずは現在の構成をお聞かせください。
静岡県・東海エリアを中心に、オンラインで全国からのご相談も承っています。ネットワーク構成図や利用中の機器一覧があれば、より具体的なご提案が可能です。