我们在 europe-west6(苏黎世)部署了一个 Google Cloud Function,它对 API 进行 HTTP 调用。在我们的服务器日志中,这些 HTTP 调用源自 IP 地址 35.203.247.36,该地址显示美国为原点。我原本以为源 IP 地址来自瑞士。这会导致地理封锁配置出现一些问题。
我找到了这个相关主题https://issuetracker.google.com/issues/72263361#comment91,表明这应该可以按预期工作,但链接的 IP 范围似乎与我们的观察不同:
{
"ipv4Prefix": "34.65.0.0/16",
"service": "Google Cloud",
"scope": "europe-west6"
}, {
"ipv4Prefix": "34.104.110.0/23",
"service": "Google Cloud",
"scope": "europe-west6"
}, {
"ipv4Prefix": "34.124.46.0/23",
"service": "Google Cloud",
"scope": "europe-west6"
}, {
"ipv4Prefix": "35.216.128.0/17",
"service": "Google Cloud",
"scope": "europe-west6"
}, {
"ipv4Prefix": "35.220.44.0/24",
"service": "Google Cloud",
"scope": "europe-west6"
}, {
"ipv4Prefix": "35.235.216.0/21",
"service": "Google Cloud",
"scope": "europe-west6"
}, {
"ipv4Prefix": "35.242.44.0/24",
"service": "Google Cloud",
"scope": "europe-west6"
}, {
"ipv6Prefix": "2600:1900:4160::/44",
"service": "Google Cloud",
"scope": "europe-west6"
}
为什么我们的 API 调用不是源自这些 IP 范围之一?
答案1
扩展一些评论:
当您查看到该 IP 的实际流量路由时,例如使用https://he.net,显示了一条通过瑞士互联网交换的路由,表明该 IP 地址确实位于瑞士。
观察到的 IP 地址
35.203.247.36
是 Google 分配给 Google Cloud 客户使用的 35.192.0.0 - 35.207.255.255 (35.192.0.0/12) 大范围的一部分。Google 自行发布了地理位置信息http://www.gstatic.com/ipranges/cloud_geofeed (JSON 版本),但该供稿并不包括他们创建的每个子网,并且不35.203.247.36
存在包含更具体的区域或位置的子网的条目。由于缺乏更具体的记录,您的地理位置数据库很可能使用了美国加利福尼亚州山景城,因为这是whois 数据。
IP 地址代表网络位置,而不是经度/纬度或街道地址。
尽管通常是一个可用的近似值,但分配给 IP 地址的位置的实际可靠性和准确性在几乎精确到城市街区和完全虚构之间变化。考虑到路由协议允许所有者/运营商几乎立即调整其内部子网并更改互联网上特定 IP 地址(范围/子网)的使用位置。特定 IP 地址(范围)今天使用的位置不一定是明天使用的位置。然后还有任播其中单个 IP 地址由多个位置的服务器共享。
尽管 IP 地理位置提供商声称其准确/完整,但许多此类数据库将使用来自公司 IP 地址范围的街道地址来获取 IP 地址,但这些地址通常 默认为谁是记录。该地址通常是公司总部,而不是数据中心街道地址,也不是例如(国际)分支机构位置,在该位置(内部子网划分后)实际分配和使用部分 IP 地址空间。
甚至提供商也会为您提供准确性指示(例如如何麦克斯敏德
1000 km
显示35.203.247.36的准确半径20 km
为 45.79.90.233,而我家 IP 地址的准确位置只有 5 公里),一旦其 IP 位置数据被平铺到基于位置的阻止和允许列表中,不确定性或(缺乏)准确性的细微差别就会完全消除。
一般来说,如果可以的话,请在允许列表中使用已知和受信任的客户端的 IP 地址,而不是根据 IP 地理位置数据授予访问权限。
有可能关联静态 IP使用您的 Google 云功能来实现这一点:
通过您的 VPC 网络路由您的函数的出口。
设置 Cloud NAT 并指定静态 IP 地址。