<h2 id="h8d027c8ed3">はじめに</h2>この記事は <a href="https://qiita.com/advent-calendar/2021/miraito-inc" target="_blank" rel="noopener noreferrer">ミライトデザイン Advent Calendar 2021</a>&nbsp;の 23日目の記事となっています。前回は「<a href="https://qiita.com/tkek321/items/5d7714d7170bbf379c11" target="_blank" rel="noopener noreferrer">docker-laravel の Docker 構成をちゃんと理解する【Dockerfile 編 - PHP】</a>」という記事を書いてくれた <a href="https://qiita.com/tkek321" target="_blank" rel="noopener noreferrer">takuma</a> でした。<a href="https://qiita.com/tkek321/items/9c0c5cec1dc349c67f5f" target="_blank" rel="noopener noreferrer">docker-compose 編</a>もあるので、そっちも見てみてください。さて、今回の記事は、IP制限をGAE（Google App Engine）で実現したいユースケースがあったのですが、GAEは自動的にIPv6に対応するそうで、半固定のIPv6に対しては固定IPで制限ができないという事象がありました。色々方法はあると思いますが、今回はServerless NEGを使用しロードバランサ経由でGAEにアクセスすることで、IP制限の実現ができたのでそちらの紹介をします。<h2 id="h0cc85de624">NEGとは？</h2>そもそもNEGというのは「Network Endpoint Group」の略です。名前の通り複数のネットワークエンドポイントをまとめたものとなっていて、ロードバランサのエンドポイントとして指定が可能となっています。NEGにはいくつか種類があり、今回のケースではServerless NEGというものを使用します。以下の画像はGKE（Google Kubernetes Engine）での画像ですが、イメージしやすいと思ったので持ってきました。<img src="https://images.microcms-assets.io/assets/b8aa8bca0ea345c69dc5acd572cdf9f1/12a584277d6b4d9aa844f7d541e9acae/9477d544-network_endpoint_group_ingress.gif" alt=""><a href="https://cloud.google.com/blog/products/containers-kubernetes/container-native-load-balancing-on-gke-now-generally-available" target="_blank" rel="noopener noreferrer">Container-native load balancing on GKE now generally available | Google Cloud Blog</a> より引用従来のGKEのロードバランサは iptables で再度負荷分散をするという2段階ロードバランシングだったのを、NEGを使用することで直説負荷分散できるといった内容を紹介してくれています。NEGとは何かという方にはイメージしやすいのではないでしょうか。【NEGの種類】<ul><li>Zonal NEG</li><li>Internet NEG</li><li>Serverless NEG</li><li>Hybrid connectivity NEG</li><li>Private Service Connect NEG</li></ul>公式：<a href="https://cloud.google.com/load-balancing/docs/negs" target="_blank" rel="noopener noreferrer">Network endpoint groups overview&nbsp;|&nbsp;Load Balancing&nbsp;|&nbsp;Google Cloud</a><h2 id="h2099926ac9">Serverless NEGとは？</h2>Serverless NEGというのはサーバーレスサービスに対して使用できるNEGです。NEGは今までGCE（Google Compute Engine）やGKEにしか使用できなかったようですが、Serverless NEGの登場により「App Engine」「Cloud Functions」「Cloud Run」のサーバーレスサービスでも使用ができるようになりました。そのため、ロードバランサのエンドポイントにサーバーレスサービスを指定し、ロードバランサでIPv4を指定することでGAEにはIPv4でのアクセスとなり、本来やりたかった固定IPの制限が可能になるということです。<h2 id="h9c9feddf28">環境構築手順</h2>では実際に環境を作ってみましょう。大きく手順としては以下の通りです。<ol><li> GAEをデプロイする</li><li>静的IPアドレスを取得する</li><li>Serverless NEGを作成する</li><li>バックエンドサービスを作成する</li><li>ロードバランサを設定する</li></ol><h3 id="haae876fc0d">GAEをデプロイする</h3>GAEのアプリケーションがデプロイされている上でIP制限をかけたいというユースケースのため、ここではGAEのデプロイ詳細は省略します。Laravelの例ですが、IPの確認をするためにエンドポイントに以下のアクションを追加しておくとGAEへのリクエストIPの確認ができます。<pre><code>public function ip(Request $request): array
{
 return [
 'ip' =&gt; $request-&gt;ip(),
 'ips' =&gt; $request-&gt;ips(),
 'client_ip' =&gt; $request-&gt;getClientIp(),
 'client_ips' =&gt; $request-&gt;getClientIps(),
 'X-Appengine-User-Ip' =&gt; $request-&gt;header('X-Appengine-User-Ip'),
 ];
}</code></pre>GAEでIPを確認する場合は <code>X-Appengine-User-Ip</code> ヘッダーから取得して確認します。公式：<a href="https://cloud.google.com/appengine/docs/standard/php7/reference/request-response-headers" target="_blank" rel="noopener noreferrer">Request Headers and Responses&nbsp;|&nbsp;App Engine standard environment for PHP 7 docs&nbsp;|&nbsp;Google Cloud</a>静的IPアドレスの作成ロードバランサのエンドポイントに使用するため静的IPアドレスを作成しておきます。<pre><code>gcloud compute addresses create [IPアドレス論理名] \
 --ip-version=IPV4 \
 --global</code></pre>以下のコマンドで予約されている IPv4 アドレスを控えときましょう。<pre><code>gcloud compute addresses describe [IPアドレス論理名] \
 --format="get(address)" \
 --global</code></pre>GUI上でも作成されていることが確認できます<img src="https://images.microcms-assets.io/assets/b8aa8bca0ea345c69dc5acd572cdf9f1/99b136d2d9d440ebb24de8b13835deef/2cb33639-7c9db82fb0b5ae39ae1df050f3e5f5ab.png" alt=""><h2 id="h7ef56048ff">Serverless NEGの作成</h2>GAE用のServerless NEGを作成します。なお、リージョンについてはGAEと同じリージョンにする必要があります。<pre><code>gcloud compute network-endpoint-groups create [ServerlessNEG論理名] \
 --region=[リージョン名] \
 --network-endpoint-type=serverless \
 --app-engine-app \
		--app-engine-service=default</code></pre>作成されたことを以下のコマンドで確認します。<pre><code>gcloud beta compute network-endpoint-groups list
NAME LOCATION ENDPOINT_TYPE SIZE
[ServerlessNEG論理名] [リージョン名] SERVERLESS 0</code></pre>GUI上でも作成されていることが確認できます。<img src="https://images.microcms-assets.io/assets/b8aa8bca0ea345c69dc5acd572cdf9f1/0cd120b05f1f46c480cf956632fd9cf5/ba074361-95ef77e03b14f34a4aff7d10006d7a5d.png" alt=""><h2 id="hf16abf8dd9">バックエンドサービスの作成</h2>バックエンドサービスを作成し、バックエンドとして先ほど作成した Serverless NEG を追加します。<pre><code>gcloud compute backend-services create [バックエンドサービス論理名] \
 --global

NAME BACKENDS PROTOCOL
[バックエンドサービス論理名] HTTP</code></pre><h3 id="he2e96d39f9">バックエンドサービスにServerless NEGを追加</h3><pre><code>gcloud compute backend-services add-backend [バックエンドサービス論理名] \
 --global \
 --network-endpoint-group=[ServerlessNEG論理名] \
 --network-endpoint-group-region=[リージョン名]</code></pre>バックエンドサービスが作成され、Serverless NEGが追加されているかを以下のコマンドで確認しましょう。<pre><code>gcloud beta compute backend-services list
NAME BACKENDS PROTOCOL LOAD_BALANCING_SCHEME HEALTH_CHECKS
[バックエンドサービス論理名] [リージョン名]/networkEndpointGroups/[ServerlessNEG論理名] HTTP EXTERNAL</code></pre>GUI上でも確認ができます。<img src="https://images.microcms-assets.io/assets/b8aa8bca0ea345c69dc5acd572cdf9f1/a5eef1e0235845df80a5759c1750a877/25a2641c-5761141b83609fcbe3717dcd01782349.png" alt=""><h2 id="h2ee46426ec">ロードバランサーの設定</h2>まずは受信リクエストをバックエンドサービスにルーティングするためのURLマップを作成します。<pre><code>gcloud compute url-maps create [ロードバランサ論理名] \
 --default-service [バックエンドサービス論理名]

NAME DEFAULT_SERVICE
[ロードバランサ論理名] backendServices/[バックエンドサービス論理名]</code></pre><h3 id="hc5df7c3780">ターゲットhttpプロキシを作成しロードバランサに追加</h3>URL マップにリクエストをルーティングするターゲット HTTPS プロキシを作成します。HTTP ロードバランサの場合、HTTP ターゲット プロキシを作成します<pre><code>gcloud compute target-http-proxies create [ターゲットhttpプロキシ論理名] \
 --url-map=[ロードバランサ論理名]

NAME URL_MAP
[ターゲットhttpプロキシ論理名] [ロードバランサ論理名]</code></pre><h3 id="h409fa3a176">フロントエンド(forwarding rule)をロードバランサに追加</h3><pre><code>gcloud compute forwarding-rules create [フロントエンド論理名] \
 --address=[控えていたIPアドレスを指定] \
 --target-http-proxy=[ターゲットhttpプロキシ論理名] \
 --global \
 --ports=80</code></pre><h3 id="h70eb6e0625">ロードバランサ・フロントエンドの確認</h3>以下のコマンドで作成したものを確認しましょう。<pre><code>$ gcloud compute forwarding-rules list
NAME REGION IP_ADDRESS IP_PROTOCOL TARGET
[フロントエンド論理名] [IPアドレス] TCP [ターゲットhttpプロキシ論理名]</code></pre>GUIでも確認<img src="https://images.microcms-assets.io/assets/b8aa8bca0ea345c69dc5acd572cdf9f1/515fe9714a9541d79d016fee15531042/3c2c69a6-c5293e12fb50f283800dfe1689841eab.png" alt=""><img src="https://images.microcms-assets.io/assets/b8aa8bca0ea345c69dc5acd572cdf9f1/4bfa675cae084d24888b66a55a656b51/4e9f68cd-73a0c19a662a2af93a62f7ff53f9a291.png" alt=""><h2 id="hf8cc2bd493">ロードバランサにリクエストしてみる</h2>作成したロードバランサにリクエストをしてみましょう。取得したIPアドレスをURLに入力してアクセスするとデプロイしたアプリケーションの画面が表示されます。自分の場合はLaravelのアプリケーションをデプロイしたので、Webcomeページが表示されます。<img src="https://images.microcms-assets.io/assets/b8aa8bca0ea345c69dc5acd572cdf9f1/93bef43238694e36be25e2d377fb14e1/80be4671-38cce6f7903788d858c70d01ec7f0a86.png" alt=""><h2 id="hd7c089008c">固定IPでアクセスできるかを確認してみる</h2>もともとデプロイしていたアプリケーションのIPを確認するとIPv6でアクセスされていることが確認できます。<img src="https://images.microcms-assets.io/assets/b8aa8bca0ea345c69dc5acd572cdf9f1/c83acee94ef044b8b19d03a1d0c71bf4/57a082c5-dcfc50d380b605b3d553394ac544bcf8.png" alt="">次に作成したロードバランサにアクセスしてIPv4でアクセスされていることを確認します。GAEへアクセスされているIPを調べるために追加したエンドポイントを叩いて <code>X-Appengine-User-Ip</code> の値を確認すると、固定IPとなっているかと思います。<img src="https://images.microcms-assets.io/assets/b8aa8bca0ea345c69dc5acd572cdf9f1/c83acee94ef044b8b19d03a1d0c71bf4/57a082c5-dcfc50d380b605b3d553394ac544bcf8.png" alt=""><h2 id="h9be0c3393d">おわりに</h2>クライアントがIPv6でアクセスしてきたとしても、GAEにはIPv4でアクセスできていることが確認できたと思います。GAEでは自動でIPv6に対応するため、IPv4の固定IPでIP制限が必要な場合は今回紹介した方法で試してみてください。この後DNSの設定やSSLの設定をすることで実用化できると思いますが、今回は省略します。できれば余裕があるときに追記していけたらと思います。<h2 id="h3de35099b3">参考</h2><ul><li><a href="https://www.publickey1.jp/blog/10/google_app_engineipv6.html" target="_blank" rel="noopener noreferrer">Google App Engineのアプリは自動的にIPv6対応に － Publickey</a></li><li><a href="https://medium.com/google-cloud-jp/neg-%E3%81%A8%E3%81%AF%E4%BD%95%E3%81%8B-cc1e2bbc979e" target="_blank" rel="noopener noreferrer">NEG とは何か. はじめに | by Yuki Furuyama | google-cloud-jp | Medium</a></li><li><a href="https://medium.com/google-cloud-jp/serverless-neg-%E3%81%A7%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E9%96%8B%E7%99%BA%E3%82%92%E3%82%88%E3%82%8A%E6%9F%94%E8%BB%9F%E3%81%AB-4f9cebd2780f" target="_blank" rel="noopener noreferrer">Google Cloud Serverless NEG | google-cloud-jp</a></li><li><a href="https://cloud.google.com/load-balancing/docs/negs/setting-up-serverless-negs" target="_blank" rel="noopener noreferrer">サーバーレス NEG の設定&nbsp;|&nbsp;負荷分散&nbsp;|&nbsp;Google Cloud</a></li><li><a href="https://christina04.hatenablog.com/entry/network-endpoint-group" target="_blank" rel="noopener noreferrer">NEG(Network Endpoint Group)を使った負荷分散 - Carpe Diem</a></li><li><a href="https://www.apps-gcp.com/serverless-neg-and-gae/" target="_blank" rel="noopener noreferrer">Serverless NEG + GAE を試してみる | apps-gcp.com</a></li><li><a href="https://qiita.com/g-yama/items/baf6ae05a8c83a77598f" target="_blank" rel="noopener noreferrer">Serverless NEG(Network Endpoint Group)を設定しGAEと連携してみた - Qiita</a></li></ul>

Serverless NEGを使用して、GAEにIPv4の固定IPアドレスでIP制限をする