はじめに
近年、セキュリティ要件が高まっており、「通信経路の暗号化」が必須となるケースが増えています。ただ、アプリケーションレイヤでの暗号化が難しい場合には、ネットワークレイヤでの暗号化が必要となってきます。さらに、ハイブリッドネットワークのDirect Connet接続構成においては、MAC暗号化は10G以上の接続が必要なため、Site-to-Site VPN over Direct Connectのプライベート接続が候補になります。
本記事では、Site-to-Site VPN over Direct Connectのプライベート接続の導入・運用でハマった事例を紹介します。対象者としてDirect ConnectやSite-to-Site VPNの基本的な仕組みや導入・運用経験はあるものの、Site-to-Site VPN over Direct Connectのプライベート接続は経験がない、といった方に実際の経験で得られた教訓を共有します。本記事の内容は2026年4月時点の情報に基づいており、最新の仕様や機能については公式情報をご確認下さい。
- はじめに
- ネットワーク概要
- 落とし穴①：ルーティング設計誤りによる意図しないルート選択
- 落とし穴②：アドレス設計誤りによるVPN切断
- 落とし穴③：頻繁なメンテナンスによるSNMP Trap多発
- まとめ
ネットワーク概要
本記事では、オンプレミスとAWSがWANサービスで接続されたハイブリッドネットワークをベースに見ていきます。構成や条件の概要は以下に示し、落とし穴の各項目で関連するパラメータ詳細を示しています。
| 環境 | 説明 |
|---|---|
| オンプレミス |
|
| WAN |
|
| AWS |
|
落とし穴①：ルーティング設計誤りによる意図しないルート選択
事象
運用中のハイブリッドネットワークにおいて、暗号化要件のある業務通信を流すことになりました。Transit Gatewayは既存リソースを流用し、Site-to-Site VPNとCustomer Gatewayは新規リソースを作成したところ、エンドツーエンドの通信は問題なく成功しました。ただ、肝心のルートを確認した結果、主系ルートが故障した場合に副系ルートのみSite-to-Site-VPNでなくDirectConnect経由のままになっており、暗号化要件を満たしていない状態になっていました。
原因
Direct ConnectとSite-to-Site VPN経由のBGP属性/条件の違いにより、意図しないルートを選択したためでした。オンプレミスルータで明示的にルート制御を行っていなかったため、主にはAS_PATHおよびoldest pathによりルートが決定されていました。
AS_PATH
Direct Connet経由ではL2サービス利用時はDXGWのみ、L3サービス利用時はDXGWとWANのAS番号が追加されます。一方、Site-to-Site VPNではL2/L3サービスを問わずに、Transite GatewayのAS番号のみが追加されます。
そのため、L3サービスを利用していた主系ルートはDirect Connect経由のAS_PATHが長くなり、Site-to-Site VPN経由のルートが選択されました。一方、L2サービスを利用していた副系ルートはDirect ConncetとSite-to-Site VPN経由のAS_PATHが等しいため、この時点ではルートがまだ決定されませんでした。
Direct Connet経由でL2サービス利用時は、DXGWだけではなくTransit GatewayのAS番号も追加されるのでは？と思った方もいるのではないでしょうか。こちらは、DXGWがAS PATH OverrideしているかのようにDXGWのAS番号のみ連携する仕様のためです。
aws.amazon.com
そのため、L3サービスを利用していた主系ルートはDirect Connect経由のAS_PATHが長くなり、Site-to-Site VPN経由のルートが選択されました。一方、L2サービスを利用していた副系ルートはDirect ConncetとSite-to-Site VPN経由のAS_PATHが等しいため、この時点ではルートがまだ決定されませんでした。
Direct Connet経由でL2サービス利用時は、DXGWだけではなくTransit GatewayのAS番号も追加されるのでは？と思った方もいるのではないでしょうか。こちらは、DXGWがAS PATH OverrideしているかのようにDXGWのAS番号のみ連携する仕様のためです。
oldest path
L2サービス利用時などのAS_PATH長が等しい場合、安定性を優先するため既存ルートを維持する動作により、結果として先に接続していたルートが選択される場合があります。
そのため、L2サービスを利用していた副系ルートは後から接続したSite-to-Site VPN経由でなく、先に接続していたDirect Connect経由のルートが選択される結果となりました。
ただし、oldest pathはRFC 4271で定義されておらず、ベンダ実装へ依存します。あくまで安定性を優先する仕様と捉え、より手堅いBGP属性/条件でルート制御することが重要です。
datatracker.ietf.org
そのため、L2サービスを利用していた副系ルートは後から接続したSite-to-Site VPN経由でなく、先に接続していたDirect Connect経由のルートが選択される結果となりました。
ただし、oldest pathはRFC 4271で定義されておらず、ベンダ実装へ依存します。あくまで安定性を優先する仕様と捉え、より手堅いBGP属性/条件でルート制御することが重要です。
対処
事象と原因だけ見れば、DirectConnectよりSite-to-Site VPN経由の方が優先されるようにメトリック調整することで解決します。しかし、以下の理由により、DirectConnect経由はVPNトンネルのピアアドレスのみ、Site-to-Site VPN経由は業務通信アドレスのみ許可するルート制限を行いました。
Direct ConnectとSite-to-Site VPNを併用する場合、BGPのデフォルト動作だけでは意図したルートが選択されるとは限りません。BGPメトリック調整のほかルート制限などを用いることで、暗号化要件を確実に満たす設計とすることが重要です。
- ルーティング設計をシンプルにすることで維持の負担を軽減するため
- VPNトンネルが故障した場合、暗号化されていない通信が流れる可能性があるため
- 不要な通信が流れること自体がセキュリティ上よろしくないため
Direct ConnectとSite-to-Site VPNを併用する場合、BGPのデフォルト動作だけでは意図したルートが選択されるとは限りません。BGPメトリック調整のほかルート制限などを用いることで、暗号化要件を確実に満たす設計とすることが重要です。
落とし穴②：アドレス設計誤りによるVPN切断
事象
ハイブリッドネットワークの主系ルート故障試験で、オンプレミスルータのWAN抜線やTunnel閉塞で疑似故障を再現し、副系ルートに問題なくフェイルオーバーすることを確認していました。ところが、主系ルートのDirect ConnectでBGPフェイルオーバーテスト機能を実行してみると、副系ルートにフェイルオーバーするものの、Site-to-Site VPNのIPsecトンネルがダウンしていました。その他の確認できた内容は、以下の通りです。
- 主系ルートが復旧すると、副系ルートも復旧する
- 試験を3回実施し、事象が3回とも発生しているため再現性あり
- Direct ConnectのBGPセッションは、アップしたまま
- キャプチャデータを見る限り、AWSからオンプレミスへのパケットが届いていない
- その他、設定・ログ・ステータスは異常なし
原因
Direct ConnectのBGPピアとSite-to-Site VPNのIPsecピアの両方ともに同一アドレスを利用していたためでした。オンプレミスネットワークでは不要なアドレス割り当てを避けるため常套手段でしたが、AWSネットワークでは不具合が生じる仕様のようでした。
AWSドキュメントでは、Direct ConnectのBGPピアはpoint-to-pointのアドレスを、Site-to-Site VPNのIPsecピアはオンプレミスルータのLoopbackまたはLANインタフェースのアドレスを使用することが推奨されています。
docs.aws.amazon.com
AWSドキュメントでは、Direct ConnectのBGPピアはpoint-to-pointのアドレスを、Site-to-Site VPNのIPsecピアはオンプレミスルータのLoopbackまたはLANインタフェースのアドレスを使用することが推奨されています。
対処
AWSドキュメントに記載の通り、Site-to-Site VPNのIPsecピアをオンプレミスルータのWANからLoopbackインタフェースへ変更し、事象が解消することを確認できました。変更で必要な設定作業は、以下の通りです。
オンプレミスネットワークで通用してもAWSネットワークで通用しないことは多々あります。AWSはサービス進化が速いことから、導入実績があってもプロジェクト導入直前にドキュメントを改めて見直すことは重要かと思います。
- オンプレミスルータにて、Loopbackインタフェースを作成
- オンプレミスルータにて、IPsecトンネルのローカルアドレスをLoopbackアドレスに変更
- オンプレミスルータにて、Direct ConnectにLoopbackアドレスをアドバタイズするように変更
- オンプレミスルータにて、ACLでLoopbackアドレスを許可するように変更
- AWS Customer Gatewayにて、WANからLoopbackのアドレスに変更
オンプレミスネットワークで通用してもAWSネットワークで通用しないことは多々あります。AWSはサービス進化が速いことから、導入実績があってもプロジェクト導入直前にドキュメントを改めて見直すことは重要かと思います。
落とし穴③：頻繁なメンテナンスによるSNMP Trap多発
事象
ハイブリッドネットワークの運用開始直後から、1～2ヶ月あたり1度、また1度あたり数回の頻度でIPsecトンネル/BGPセッションダウンのSNMP Trapメッセージが発生していました。一方、これらのメッセージに関連し、業務通信に影響することはありませんでした。
原因
SNMP Trap多発の原因は、Site-to-Site VPNのメンテナンスでした。時期や環境による差もありますが、Site-to-Site VPNはDirect Connectと比べてメンテナンス頻度が高い傾向があります。
AWS側ではSite-to-Site VPNのライフサイクル制御機能やHealth Dashboardのイベント通知機能などでメンテナンスと判別できますが、オンプレミス側ではルータログなどでメンテナンスと故障が判別できません。そのため、オンプレミスルータからの不要なSNMP trapによる運用業務への影響が課題となりました。
ちなみに、何故SNMP Trapが発生しているにも関わらず、業務通信には影響しないのでしょうか。理由は、Site-to-Site VPNのメンテナンス開始直前にAWSがメトリックを調整し、メンテナンス開始予定のトンネルから冗長化されたもう一方トンネルに業務通信がフェイルオーバーされるためです。詳しい動作については、以下の記事をご覧ください。
yamamototis1105.hatenablog.com
AWS側ではSite-to-Site VPNのライフサイクル制御機能やHealth Dashboardのイベント通知機能などでメンテナンスと判別できますが、オンプレミス側ではルータログなどでメンテナンスと故障が判別できません。そのため、オンプレミスルータからの不要なSNMP trapによる運用業務への影響が課題となりました。
ちなみに、何故SNMP Trapが発生しているにも関わらず、業務通信には影響しないのでしょうか。理由は、Site-to-Site VPNのメンテナンス開始直前にAWSがメトリックを調整し、メンテナンス開始予定のトンネルから冗長化されたもう一方トンネルに業務通信がフェイルオーバーされるためです。詳しい動作については、以下の記事をご覧ください。
対処
オンプレミス側とAWS側のそれぞれで対処方針を検討しました。
まず、オンプレミス側はルータログなどでメンテナンスと故障が判別できないため、IPsecトンネルおよびBGPセッションダウンに関するSNMP Trapを停止することとしました。一方、SNMP Trapを停止するだけでは故障で発報できなくなります。そこで、AWS側はメンテナンス時を除いて故障時のみ発報する仕組みを検討・実装しました。
AWS側での実装方法の一つとして、CloudWatch Synthetic Monitorを用いてオンプレミスルータのLoopbackアドレスへポーリングし、遅延もしくはパケット損失率が閾値を超過した場合に発報する方法が挙げられます。この方法を実装するうえで、重要なポイントは以下の通りです。
CloudWatch Synthetic Monitorは、ハイブリッドネットワークの通信品質を管理するうえでも有効なサービスです。例えば、遅延やパケット損失率が上昇するようなグレー障害に対して大きな力を発揮します。CloudWatch Synthetic Monitorについては、以下の記事をご覧下さい。
yamamototis1105.hatenablog.com
Site-to-Site VPNではメンテナンスが頻繁に実施されるため、オンプレミス側のSNMP Trapだけでは不要なアラームを避けられません。AWS側の監視サービスを活用することにより、メンテナンス時に発報させず、故障時のみ発報させる監視設計を行うことが重要です。
まず、オンプレミス側はルータログなどでメンテナンスと故障が判別できないため、IPsecトンネルおよびBGPセッションダウンに関するSNMP Trapを停止することとしました。一方、SNMP Trapを停止するだけでは故障で発報できなくなります。そこで、AWS側はメンテナンス時を除いて故障時のみ発報する仕組みを検討・実装しました。
AWS側での実装方法の一つとして、CloudWatch Synthetic Monitorを用いてオンプレミスルータのLoopbackアドレスへポーリングし、遅延もしくはパケット損失率が閾値を超過した場合に発報する方法が挙げられます。この方法を実装するうえで、重要なポイントは以下の通りです。
- ポーリングがIPsecトンネルのフェイルオーバーに追従できるよう、Loopbackアドレスはオンプレミスルータから冗長化された両方のIPsecトンネルへアドバタイズすること。
- IPsecトンネルの単一故障では発報しないため、Site-to-Site VPNのTunnelState（トンネル接続状態）メトリクスも別途監視し、一定時間ダウンした場合に発報すること。
Site-to-Site VPNのメンテナンスによるダウンタイムは1～2分のため、一例としては1分間隔・5回連続でダウンした場合などのCloudWatch Alarm条件が考えられます。
CloudWatch Synthetic Monitorは、ハイブリッドネットワークの通信品質を管理するうえでも有効なサービスです。例えば、遅延やパケット損失率が上昇するようなグレー障害に対して大きな力を発揮します。CloudWatch Synthetic Monitorについては、以下の記事をご覧下さい。
Site-to-Site VPNではメンテナンスが頻繁に実施されるため、オンプレミス側のSNMP Trapだけでは不要なアラームを避けられません。AWS側の監視サービスを活用することにより、メンテナンス時に発報させず、故障時のみ発報させる監視設計を行うことが重要です。
まとめ
本記事では、Site-to-Site VPN over Direct Connectのプライベート接続の導入・運用でハマった事例、そこから得られた教訓を紹介しました。
これからSite-to-Site VPN over Direct Connectを導入・運用する方にとって、本記事が参考になりますと幸いです。
