云 运行 静态出站 IP 地址不通过 Google App Engine 防火墙
Cloud Run static outbound IP address does not go through Google App Engine firewall
我在 Google App Engine (flex) 上有一个 python (flask) 应用程序 运行；该应用程序受 GAE 防火墙保护，其中：
- 默认规则是'Deny'所有入口
- 存在允许流量的 IP 地址白名单。
我在云 运行 上部署了一些微服务（完全托管），其中：
- 接收来自 GAE 应用的请求（例如繁重的任务）
- 将他们处理的任何结果作为 http 请求发送回 GAE 应用程序中的 handlers/endpoints
因此，GAE 应用程序是与客户端交互的主要点和繁重任务的调度器，而这些任务的处理则由微服务执行。我已经设置了一个 static outbound IP address 的云 运行 托管服务，它确实有效，并且流量按照文档中的要求通过 NAT 网关路由。相应的 NAT IP 地址在防火墙白名单中。
问题是防火墙仍然不允许进入云 运行 >>> GAE 应用程序请求以 403 状态反弹（当然，如果我将默认防火墙规则更改为 'Allow'，流量通过）。如果我在 GCE VM 上的 docker 容器中托管相同的微服务，并使用像 this 这样的静态 IP 地址，一切都可以完美运行。这让我假设尽管 Cloud 运行 出站流量确实是通过静态 IP 地址路由的，但当流量流向 GCP 外部的收件人时，当我尝试 ping 一个内部（项目方面）资产时，它仍然会通过一些动态选择的IP（即静态 IP 解决方案根本不起作用）。不幸的是，日志没有显示 403-ed 尝试，所以我看不到这些请求似乎来自哪个 IP 地址（从 GAE 的角度来看）。
我将非常感谢关于如何解决这个问题的想法，因为它大大降低了为云 运行.
提供静态出站 IP 地址的美妙想法的价值。
你说得对，当数据包在内部路由到 GCP 时，静态 IP 不受尊重。
我认为this是你想要的。您必须在防火墙中允许那里提到的 IP 之一（现在不确定是哪一个）。
正如您和@Ema 提到的，考虑到来自 Cloud 运行 App Engine 的流量是内部流量，这是一种预期的行为。
当您使用 Cloud Nat send all traffic 时，确实会发生这种情况。如果您创建一个容器并执行 ping，假设为 www.github.com。你会发现流量通过你设置的IP。另一方面，如果您 ping www.google.com，假设流量是内部流量，并且要访问的站点位于同一基础架构中，则请求甚至不会通过 public 互联网。
此外，请记住 Static outbound IP address 仍处于 Beta 阶段，不建议在生产环境中使用 Beta features/products。
正如您提到的和 Allowing requests from your services 中所述：
Creating a rule for IP 0.0.0.0 will apply to all Compute Engine instances with Private Google Access enabled, not only the ones you own. Similarly, allowing requests from 0.1.0.40 or 10.0.0.1 will allow any App Engine app to make URL Fetch requests to your app.
您可能对以下问题感兴趣：
首先感谢两位的帮助和建议，很有帮助。我在 Google:
的帮助下找到了解决方案
- 当 Cloud 运行 微服务和 GAE 应用程序托管在同一个项目中时，流量仍然通过内部通道路由，并且似乎来自可以列入白名单的 IP 地址 0.0.0.0（因此它可以工作) 只要认为这个地址包含 GCP 资产，这些资产也是其他项目的一部分（据我所知）
- 一个更强大的解决方案似乎是设置一个面向外部的负载平衡器，如文档here and putting it in front of the GAE app; in such a case, Cloud Run will indeed consistently use its static outbound IP address中所述
我在 Google App Engine (flex) 上有一个 python (flask) 应用程序 运行；该应用程序受 GAE 防火墙保护，其中：
- 默认规则是'Deny'所有入口
- 存在允许流量的 IP 地址白名单。
我在云 运行 上部署了一些微服务（完全托管），其中：
- 接收来自 GAE 应用的请求（例如繁重的任务）
- 将他们处理的任何结果作为 http 请求发送回 GAE 应用程序中的 handlers/endpoints
因此，GAE 应用程序是与客户端交互的主要点和繁重任务的调度器，而这些任务的处理则由微服务执行。我已经设置了一个 static outbound IP address 的云 运行 托管服务，它确实有效，并且流量按照文档中的要求通过 NAT 网关路由。相应的 NAT IP 地址在防火墙白名单中。
问题是防火墙仍然不允许进入云 运行 >>> GAE 应用程序请求以 403 状态反弹（当然，如果我将默认防火墙规则更改为 'Allow'，流量通过）。如果我在 GCE VM 上的 docker 容器中托管相同的微服务，并使用像 this 这样的静态 IP 地址，一切都可以完美运行。这让我假设尽管 Cloud 运行 出站流量确实是通过静态 IP 地址路由的，但当流量流向 GCP 外部的收件人时，当我尝试 ping 一个内部（项目方面）资产时，它仍然会通过一些动态选择的IP（即静态 IP 解决方案根本不起作用）。不幸的是，日志没有显示 403-ed 尝试，所以我看不到这些请求似乎来自哪个 IP 地址（从 GAE 的角度来看）。
我将非常感谢关于如何解决这个问题的想法，因为它大大降低了为云 运行.
提供静态出站 IP 地址的美妙想法的价值。你说得对，当数据包在内部路由到 GCP 时，静态 IP 不受尊重。
我认为this是你想要的。您必须在防火墙中允许那里提到的 IP 之一（现在不确定是哪一个）。
正如您和@Ema 提到的，考虑到来自 Cloud 运行 App Engine 的流量是内部流量，这是一种预期的行为。
当您使用 Cloud Nat send all traffic 时，确实会发生这种情况。如果您创建一个容器并执行 ping，假设为 www.github.com。你会发现流量通过你设置的IP。另一方面，如果您 ping www.google.com，假设流量是内部流量，并且要访问的站点位于同一基础架构中，则请求甚至不会通过 public 互联网。
此外，请记住 Static outbound IP address 仍处于 Beta 阶段，不建议在生产环境中使用 Beta features/products。
正如您提到的和 Allowing requests from your services 中所述：
Creating a rule for IP 0.0.0.0 will apply to all Compute Engine instances with Private Google Access enabled, not only the ones you own. Similarly, allowing requests from 0.1.0.40 or 10.0.0.1 will allow any App Engine app to make URL Fetch requests to your app.
您可能对以下问题感兴趣：
首先感谢两位的帮助和建议，很有帮助。我在 Google:
的帮助下找到了解决方案- 当 Cloud 运行 微服务和 GAE 应用程序托管在同一个项目中时，流量仍然通过内部通道路由，并且似乎来自可以列入白名单的 IP 地址 0.0.0.0（因此它可以工作) 只要认为这个地址包含 GCP 资产，这些资产也是其他项目的一部分（据我所知）
- 一个更强大的解决方案似乎是设置一个面向外部的负载平衡器，如文档here and putting it in front of the GAE app; in such a case, Cloud Run will indeed consistently use its static outbound IP address中所述