【ITニュース解説】Verifying Google Cloud egress IP ranges with cloud.json and jq

Google Cloud上で動作するシステム、例えばGCE（Google Compute Engine）のアプリケーションやCloud NAT（ネットワークアドレス変換）ゲートウェイが、外部のインターネットサービスに接続しようとすると、まれに通信がうまくいかないという問題が発生することがある。これは、ある地域からの接続は問題なく通るのに、別の地域からだと最初の通信開始信号（TCP SYN）がタイムアウトしてしまう、といった非対称な通信障害として現れる。

このような問題が起こる主な原因は、通信相手の外部サービスが利用しているファイアウォール（通信を許可・拒否するシステム）の設定にある場合が多い。具体的には、ファイアウォールが特定のIPアドレスだけを許可する「IP許可リスト」を使用しているが、そのリストが更新されておらず、Google Cloudが新たに利用し始めたIPアドレス範囲が含まれていない、という状況が考えられる。また、IPアドレスから地理的な位置情報を特定するGeoIPデータベースが古いことも原因の一つだ。Googleが使用するIPアドレスの中には、地理情報が古いデータベースではアメリカ合衆国と表示され、本来の地域として認識されないケースがあるため、通信がブロックされることがある。

こうした通信障害に直面した際、自身のGoogle Cloudから外部へ出ていくIPアドレス（Egress IP）が、外部からどのように認識されているかを確認する必要がある。Googleは、顧客が利用できる外部IPv4およびIPv6アドレス範囲を地域ごとにまとめたcloud.jsonというファイルを公開している。このファイルは機械が読み取りやすい形式で、どのIPアドレスがどの地域で利用されているかを示している。新しいCloud NATゲートウェイを設定したり、パートナー企業のネットワークチームと共同で通信障害を調査したりする際に、このcloud.jsonを利用すると、自身の外部IPアドレスがどの公開CIDRブロック（IPアドレスの範囲）に属し、その情報がいつ更新されたかを確認できる。

しかし、cloud.jsonには千を超えるIPアドレスプレフィックスが記載されているため、手動で検索するのは効率的ではない。そこで、gcloudコマンドとjqツールを組み合わせることで、この確認作業を自動化するスクリプトが非常に役立つ。

このスクリプトは、主に三つのステップで構成されている。第一に、自身のGoogle Cloudプロジェクトで予約している外部IPアドレスの情報を取得する。第二に、Googleが公開しているcloud.jsonファイルをダウンロードする。そして最後に、jqというJSONデータを処理するコマンドラインツールを使って、取得したIPアドレスとcloud.jsonの内容を照合し、それぞれのIPアドレスがどのCIDRブロックに属しているか、そしてその地域スコープ（利用地域）はどこかを表示する。

スクリプトの詳細を説明する。まず、gcloud compute addresses listコマンドを実行する。このコマンドはGoogle Cloud SDKの一部で、指定したプロジェクトとリージョンに予約されている外部IPアドレスの一覧をJSON形式で取得する。--filter="addressType=EXTERNAL"オプションを付けることで、内部ネットワーク用のIPアドレスを除外し、外部向けのIPアドレスのみを対象とすることができる。もし予約済みのIPアドレスではなく、仮想マシンに一時的に割り当てられている外部IPアドレスを確認したい場合は、gcloud compute instances listコマンドからIPアドレス情報を取得することも可能だ。

次に、curlコマンドを使って、Googleが公開しているcloud.jsonファイルをインターネットからダウンロードする。このcloud.jsonもJSON形式のデータである。

これらの二つのJSONデータを、jqコマンドの入力として渡す。jqは、受け取ったJSONデータに対して、フィルタリングや変換といった複雑な処理を行うことができる。このスクリプトの中でjqが実行する主な処理を説明する。

まず、jqの内部で、IPアドレス文字列（例: "34.174.136.135"）を32ビットの整数値に変換する関数を定義する。これは、IPアドレスがどのCIDRブロックに含まれるかを効率的に判定するために必要だ。CIDRブロックは「192.168.1.0/24」のように表記され、IPアドレスを整数に変換することで、指定されたネットワークアドレスとマスク長を使って、あるIPアドレスがそのブロックの範囲内にあるかを数学的に比較できるようになる。

次に、gcloudコマンドから取得した自身の予約済みIPアドレスのリストを一つずつ取り出す。それぞれのIPアドレスについて、先ほど定義した関数を使って整数値に変換する。

そして、ダウンロードしたcloud.jsonに含まれるprefixes配列の中身を一つずつチェックする。cloud.jsonの各エントリにはipv4Prefixやscopeなどの情報が含まれている。jqは、このprefixes配列からIPv4アドレスのプレフィックスを持つエントリだけを選び出し、それぞれのプレフィックスからネットワークアドレス（整数値に変換）とマスク長（例えば「/16」から「16」）を抽出する。

最後に、自身のIPアドレスがcloud.jsonのどのCIDRブロックの範囲内にあるかを比較して特定する。具体的には、自身のIPアドレスの整数値が、プレフィックスのネットワークアドレスの整数値以上で、かつネットワークアドレスとCIDRブロックのサイズを足した値未満であるかを判定する。この条件に合致する最初のプレフィックスが、そのIPアドレスが属するCIDRブロックとなる。

もし、いずれのプレフィックスにも合致しない場合は、「UNLISTED」（リストにない）と表示されるように設定されている。最終的に、jqは予約済みのIPアドレスの「名前」「IPアドレス」「ネットワーク階層（PREMIUM/STANDARD）」「一致したCIDRプレフィックス」「地域スコープ」といった情報を整形して出力する。

実際の実行例を見ると、例えば「nat-ip-a0」という名前のIPアドレス「34.174.136.135」が、cloud.jsonでは「34.174.0.0/16」というプレフィックスに属し、「us-south1」という地域スコープを持つことが一目でわかるようになっている。また、「nat-ip-a2」という別のIPアドレス「34.0.132.72」は、「34.0.128.0/19」という異なるプレフィックスに属していることも示される。このように、同じリージョン内でもIPアドレスのネットワーク階層（PREMIUMまたはSTANDARD）によって、異なるCIDRブロックに割り当てられていることが確認できる。

cloud.jsonの内部構造を見ると、syncToken（同期トークン）とcreationTime（作成時間）があり、その後にprefixesという配列が続く。prefixes配列の各要素には、ipv4Prefix、service、scopeなどの情報が格納されている。IPv6アドレスを使用している場合は、ipv6PrefixというフィールドにIPv6のCIDRブロックが記載される。

このスクリプトを利用する上でいくつか注意点がある。静的な外部IPアドレスのリストは、Google Compute EngineのAPIを使って地域ごとまたはグローバルに取得できる。一時的なIPアドレスの場合には、仮想マシンインスタンスのネットワークインターフェース情報から取得する必要がある。

また、Googleはcloud.jsonの他にgoog.jsonというIPアドレス範囲ファイルも公開しているが、これらには違いがある。cloud.jsonは顧客がGoogle Cloudで利用できるIPアドレス範囲を地域スコープ付きでリストしているのに対し、goog.jsonはGoogleが所有する全てのIPアドレスプレフィックスを含んでいるが、地域スコープの情報はない。このスクリプトではcloud.jsonを使用しているため、この違いを理解しておくことは重要だ。jqで処理を行う際は、IPv4とIPv6のエントリが混在しているため、select(has("ipv4Prefix"))のようなフィルタを使って、IPv4アドレスだけを正確に処理するように注意が必要だ。

今後、外部のサービスがGoogle Cloudからの通信をブロックするような問題が発生した際には、このスクリプトを実行して、自身のEgress IPアドレスがcloud.json上でどのipv4Prefixに属しているか、そしてcreationTimeがいつであるかを確認すると良い。もし相手側のファイアウォールがまだ新しいIPアドレス範囲を許可リストに取り込んでいないことが判明した場合は、この特定の地域ブロックの情報や、自身の予約済みIPアドレスを相手のネットワークチームに伝えることで、彼らが許可リストを適切に更新し、通信問題を解決するための具体的な情報を提供できる。この方法は、予期せぬ通信障害を迅速に解決するための強力なツールとなるだろう。