COLUMN

ネットワーク診断ツール「VPC Reachability Analyzer」のご紹介（事例紹介）

サービス用の通信が突然途絶えた時にどのような対応をされていますでしょうか。

障害対応等の運用業務を委託されているならば委託先に障害対応を依頼されているかと思います。お客様自信にて切り分けをされた結果を迅速かつ正確に伝えられると、運用会社の復旧対応が迅速に対応できる可能性が高まります。特に、バーゲンセール等の売り上げが好調な時期に障害に遭遇すると、ビジネスに影響を及ぼすほどクリティカルな状況になることが予想されますので、迅速な障害対応を実行するための仕組み造りは不可欠です。

障害のたびに運用会社とのやり取りする内容を決めていたのでは、障害対応の調査を開始するまでに非常に時間がかかってしまいます。もしも、運用会社との情報のやり取りや切り分けのためにネットワークやサーバの設定変更をせずに簡単に状況を共有できたらどうでしょうか。この場合はすぐに原因調査や復旧作業に取り掛かれるので、復旧時間の短縮が期待できます。

このような状況への活用が見込まれる新しいネットワーク診断ツール「VPC Reachability Analyzer」が先日のAWS Re:Invent2020で発表されましたので、簡単に紹介したいと思います。

このツールは、AWSクラウド内における通信の到達性に関して、疑似的にテストを実施します。

ping等のテストのためにアクセスポリシ(ネットワークACLやセキュリティグループ等)を追加しているケースにおいては、このようなネットワーク設定変更ができないために疎通確認そのものを諦めているケースもあるかと思います。このため、切り分けが長期化して苦い経験をされた方もいるかと思います。
このツールでは実際に通信を行ってテストするのではなく、AWSテナント内の設定情報とネットワーク上の処理（ルーティングやセキュリティグループ等)に基づいて通信の到達性を判定するので、通信到達性の確認のためにネットワーク設定を変更する必要がありません。

具体的には送信元と送信先を指定して「パスの分析」を実行すると、送信元と送信先との到達可能／到達不可能の判定結果を出力します。

• 到達可能の場合：送信元から送信先との間のパス（ノードのつながり）を表示できます。
• 到達不可能な場合：通過できないノードと通過できない理由を表示します。

現時点で送信元・送信先に指定できるタイプは６種類あります。

• インスタンス
• ネットワークインターフェイス(ENI: Elastic Network Interface)
• インターネットゲートウェイ
• VPN ゲートウェイ
• VPC エンドポイント
• VPC ピアリング接続

オプションとして、送受信先のIPアドレス、送信先ポート番号も指定可。
プロトコルは現時点では、TCP/UDPのみです。

また、中間ノードとして表示される現時点の主なコンポーネントには以下のものがあります。

• サブネット
• ルートテーブル
• プレフィックスリスト
• ネットワーク ACL
• セキュリティグループ
• VPN コネクション

実際に「VPC Reachability Analyzer」のパス分析を試してみたので、結果を示します。
今回のテスト環境は、ひとつのVPCにパブリックサブネットを２つ作り、EC2インスタンス（踏み台サーバを想定）を各々のパブリックサブネットに配置して、EC2インスタンス間でTCP/3389(RDP)の到達可能／不可能かの判定を実施しました。
このネットワーク構成図を図１に示します。通信経路は太い矢印で示しています。成功するとサービスアイコンでパスが表示されますので、図１にもサービスアイコンを表示しました。

図１．ネットワーク構成図

具体的には３つのパターンでパス分析を実施しました。

• パターン①
  受信側のインスタンスＢが停止している場合
• パターン②
  受信側のインスタンスＢにアタッチしたセキュリティグループにおいて、送信側のインスタンスＡのIPアドレスを含まない場合（具体的には、受信側ルールから10.0.0.0/24,TCP/3389を削除）
• パターン③
  インスタンスＢを起動状態にし、セキュリティグループにインスタンスAのIPアドレスを登録してアクセス許可状態にしている場合

結果は当然ながら、パターン①とパターン②は到達不可になり、パターン③のみが到達可能となりました。

図２．パターン①のパス分析の結果（到達不可の例）

図３．パターン②のパス分析の結果（到達不可の例）

図４．パターン③のパス分析の結果（到達可能の例）

パターン①の結果では、インスタンスＢが停止状態であることを読み取れました。
パターン②の結果では、Ingress(受信側)のセキュリティグループのルールがないことが読み取れましたが、不足しているルールまでは現時点では指摘できないので、ネットワーク構成に基づいて考える必要はありました
パターン③の結果では、パス（インスタンス A⇒ENI A⇒送信側セキュリティグループ⇒送信側ネットワークACL⇒受信側ネットワークACL⇒受信側セキュリティグループ⇒ENI B⇒インスタンスB）を表示しました。
今回、サブネット間を跨がせたのでルートテーブルを表示すると思ったのですが、残念ながら表示することができませんでした。マニュアル等にパス表示の仕様が書かれていませんでしたので、今後詳細な情報が書かれることを期待したいと思います。

ping等の疎通確認ツールとは違い、特別に設定を変更することなく到達性を判定して、到達が不可能な場合にその理由まで提示してくれました。通信障害の切り分けに活用して頂ければ迅速な障害復旧が期待できるのではないかと思います。まずはお試しいただけると幸いです。
現状では、オンプレミスとの接続やクラウド間の接続やゲストOSの中まではこのツールは解析できないので、当面はping等のツールと併用することになりますが、今後の機能改善に期待したいところです。
このツールは有料です。1回のパス分析につき0.1ドル（＄）かかります。AWS Lambda等で繰り返し実行する場合は料金を注意した方が良いと思います。

簡単な操作説明がAWSからブログが出ていますので、そちらを参照して頂ければと思います。

Amazon Web Services ブログ

新機能 - VPC Reachability Analyzer