パケット爆発を解析してみた（インターンシップ体験記）

はじめに

こんにちは、インターン生の鈴木健吾です。私は現在修士 2 年生で、学部 4 年生から研究室や WIDE プロジェクトでネットワークの構築・運用に関わったり、Interop や JANOG などのイベントに足を運んだりしています。このたび、2024 年 2 月に NTT コミュニケーションズで 2 週間の現場受け入れ型インターンシップに参加させていただいたので、その体験談を執筆させていただきます。

参加したインターンシップについて

配属されたチームについて

私は 「エンタープライズ向け大規模クラウドサービスを支えるネットワーク開発」 というポストで、NTT コミュニケーションズのサービスの 1 つである Smart Data PlatForm (SDPF) クラウドの NFV チームでインターンに参加させていただきました。

SDPF クラウドとは、エンタープライズ向けのクラウドサービスで、「オンプレミスのネットワークをそのまま持ち込める IaaS」を目標にしています。下の図は SDPF クラウドのアーキテクチャを表しており、ネットワーク仮想化技術である EVPN-VXLAN によってハードウェア VTEP 配下のベアメタルサーバやソフトウェア VTEP (VXLAN Tunnel End Point) 配下の VM などが L2 で連結されることでカスタマーの要望に合わせた柔軟なネットワークの提供を可能にしています。

私の配属された NFV チームは SDPF クラウドのファイアウォールやロードバランサーのサービス開発などを担当しているチームです。

インターンシップの課題

私が今回取り組んだテーマは、このインターンの 3 ヶ月ほど前に実際に発生した 障害対応の追体験 でした。その障害の内容とは 「パケット爆発」 で、NFV チームがファイアウォールの更改作業をしていた際にマネジメントネットワークで DDoS 検知が作動したことで発覚しました。この障害について、簡素化された当時の再現環境が用意され、 「マネジメントネットワークで、ファイアウォール VM にパケットを流しながらその VM を消すと、パケットが爆発する」 という情報からその原因解析に取り組みました。

インターンシップで取り組んだこと

私は 2 週間のインターン期間で、大きく次の 3 ステップで課題を進めました。

障害の再現
障害の解析
障害の解決確認

障害の再現

再現環境では下の図のようなネットワークが用意されていました。図中で FW はユーザに提供されているファイアウォールを表します。FW のマネジメントインターフェースが繋がっているマネジメントネットワーク（mgmt_nw）とバックヤードネットワーク（backyard_nw）の間にはゲートウェイ（GW）があります。作業の中心となる VM からは GW 越しに FW に ping などを送ることができます。この状態からマネジメントネットワークに新たな FW-4(IP アドレス 192.168.1.104)を作成し、VM から ping を打ちながら削除すると、ping 出力画面に突然 「Time to Live Exceeded」 の出力が大量に流れるようになり、パケット爆発を再現できました。

障害の解析

ネットワーク側の解析

最初に、このパケット爆発がどのように収束するのかを調べました。パケットの爆発を確認してから ping を止めたり、再度送信したりすると、次のことがわかりました。

ping を打つのを止めてしばらくすると、再度送信してもパケットは爆発しない
ping を打ち続けているとパケット爆発は終了しない
ping を打つのを止めてすぐに再度送信すると、パケットは爆発する

次に、ファイアウォールに流れるパケットを tcpdump でキャプチャすることで、マネジメントネットワークにどのようなパケットが流れているのかを観察しました。下の図は VM から（削除済みの）FW-4 に ping のパケットを 1 つだけ送信したときの FW-1 でのパケットキャプチャの結果を示しており、全部で約 18 万個のパケットが流れてきたことがわかりました。

このパケットキャプチャの結果を「送信元 MAC アドレス」や「宛先 MAC アドレス」、「TTL」に注目して解析すると、FV-1~FW-3 は FW-4 のインターフェースの MAC アドレス宛のパケットを受信して、その TTL を 1 減らし、FW-4 宛に転送していることがわかりました。

これにより、パケット爆発のメカニズムが次のように説明できます。

VM から FW-4 に ping を打っている状態で FW-4 が削除されると、マネジメントネットワークの L2 スイッチ機能によって全ての FW にパケットがフラッディングされる
各 FW に届いたパケットは各々 FW-4 宛に転送される
転送されたパケットが 1 と同様に他の全ての FW にフラッディングされ、さらに転送される
このプロセスがパケットの TTL が 0 になるまで繰り返される

ここまでの解析でファイアウォールが自分のインターフェース宛でないパケットを転送してしまうことがパケット爆発の原因であることがわかりました。

ファイアウォール側の解析

本来、ネットワーク機器は受信パケットを低いレイヤーから処理し、自分のインターフェース宛でないパケットは L2 の段階で破棄（フィルタリング）するはずです。それでは何故 FW-1~FW-3 は FW-4 のインターフェース宛のパケットをフィルタリングしないのでしょう。

私は最初に、ユーザの設定したファイアウォールの設定に関連するものがないかを調べました。しかし、MAC アドレスによるフィルタリングを無効にするような設定（例えばプロミスキャスモードを on にするなど）は見つかりませんでした。困っていると、次のヒントが与えられました。

この障害は開発環境でのテストでは発生しなかった
開発環境と再現環境の設定の違いは ARP の Passive Learning が有効になっていること

ARP の Passive Learning とは、受信した GARP(Gratuitous ARP)を ARP テーブルの学習に利用するというもので、GARP はネットワークに接続されたホストが最初に IP アドレスの衝突を回避するために ARP 要求を送信する仕組みです。しかし、この設定の有無で MAC アドレスのフィルタリングに影響を与えるとは考えられません。

ここで解析が行き詰まり、ネタバラシが入りました。実は、この障害の原因はユーザの設定起因やクラウドのバグではなく

「ファイアウォールの OS の不具合」

でした。すなわち、「ファイアウォールの動作がそもそもおかしいこと」だったのです。サービス環境では、受信パケットに対するフィルタリングが機能していないことに加えて、ARP の Passive Learning が有効になっていたファイアウォールではそのパケットを転送する条件も揃っていたため、このパケット爆発という現象に繋がったのです。

ファイアウォールの動作がおかしいことの証明

ここまでの検証から、今回の障害の原因はファイアウォールのアプライアンス OS の不具合にある、ということがわかりました。したがって、この障害を解決するためにはベンダーにファイアウォールのアプライアンス OS の不具合を示して、修正してもらう必要があります。しかし、これまでの検証ではベンダーに対してイメージの実装に不具合があると断言することは難しいです。なぜなら、この検証は複数のホストが存在する複雑な環境で行われており、ファイアウォールにも ARP の Passive Learning などさまざまな設定がされており、それらが今回の障害に関係するかもしれないからです。もっとシンプルで端的な検証により、不具合を証明する必要があります。

そこで、下の図のような環境を用意しました。まず、ファイアウォールは 1 つにし、初期設定のままにします。 ARP テーブルは ARP Passive Learning を用いなくても、コマンドを使って自由に操作できるため、GW と FW-1 の ARP テーブルに 192.168.1.104 というネットワーク上に存在しない架空の IP アドレスと、それに対する架空の MAC アドレスのレコードを挿入しました。この条件で、架空の IP アドレス & MAC アドレス宛のパケットを FW-1 が転送することを確認できれば、予期せぬ動作の原因がイメージ実装の不具合にあると主張できます。

実際に、これまでと同様に VM から 192.168.1.104 へ ping を打つと、全く同じ現象を再現できました。

障害の解決確認

ここまでの検証と問い合わせは、実際に NFV チームがインターン開始前にやっていたことでした。すでに新しいイメージが出されており、この新しいイメージで先ほどと同様の検証することで不具合が修正されていることを確かめられるはずです。しかしながら、検証の結果、新しいイメージでもパケットの転送が確認されてしまいました。結局完全解決を見る前にインターンは終わってしまいました。

まとめ

反省

今回は 2 週間のインターンシップに参加させていただきましたが、祝日が挟まったり、大雪の影響を受けたりした結果、実際には 6 日にも満たない短期間で課題に取り組むことになりました。限られた時間の中でしたが、これまで Linux やネットワーク機器に触ってきたことによる慣れや事前知識、トラブルシューティングの経験のおかげでファイアウォールの解析まで約 1 日半とスムーズに進めることができたと思っています。しかし、これまでネットワークのトラブルは自身の設定ミスだったり仕様の把握が甘かったりが原因であったため、そもそもの OS がおかしいという発想になかなかなれなかったのが悔やまれます。ファイアウォールの動作がそもそもおかしいことの証明までノーヒントで辿り着くことができれば完璧でした。

感想

本インターンシップに参加する前は NTT コミュニケーションズの SDPF クラウドというサービスを知らなかったのですが、パブリッククラウドサービスを提供しているという国内有数のとても魅力的なチームでした。私は本インターンシップで初めてビジネスのネットワークの運用・構築を間近で見ることができ、とても貴重な学びを得られたと感じています。障害当時のチームの対応履歴も拝見させていただき、ビジネスのネットワークではこれまで私の経験してきたただ直すだけのトラブルシューティングとは異なり、カスタマーを第一に考えた対応が求められることがわかりました。技術的には、これまで度々耳にしていた EVPN-VXLAN をちゃんと勉強できたことや初めて ARP にフォーカスしたトラブルシューティングができたことがとても学びになりました。私がこれまであまり経験してこなかった冗長化や自動化の重要さも教えていただき、これから勉強していこうと思いました。

課題以外でも、NFV チームの一員として実際のミーティングに参加させていただいたり、チームに関わるさまざまなお話を聞かせていただいたりと NFV チームのリアルを体験でき、とても有意義なインターンシップでした。また、他のインターン生や社員さんとの交流の場もたくさん用意していただき、とても楽しいインターンシップでした。最後に、メンターの石井さんをはじめ NFV チームの皆さん、並びに関わっていただいた社員さんやインターン生に皆さん、このインターンシップに参加させていただいたことに感謝を申し上げます。

メンターからのコメント

SDPF クラウドで NFV 開発を担当している石井です。鈴木さん、2 週間お疲れ様でした。天候の影響もあり予定より日程が少なかったですが、交流イベントにも全参加しつつ、業務も効率よく進めていただきました。さまざまな要因が考えられる事象の解析にチャレンジいただきましたが、持ち前の知識・経験を生かし、発生している事象から原因の切り分けまで我々の想定を超えて素早く進めることができていました。幅広い技術力と積極性があり、これからもご活躍されることと思います。心より応援しております。