技术实操 谷歌云 香港 原生ip BGP路由和AS号溯源的检查流程

1. 概述：为何对谷歌云香港原生IP做BGP与AS溯源很重要

1) 目的：确认公网IP的归属、路由路径与可能的路由劫持风险；
2) 适用场景：VPS/服务器上云后需要备案、DDoS溯源或接入CDN与防火墙策略制作；
3) 风险点：跨区域路由、任何中间ASN的转发都可能导致性能或安全问题；
4) 输出目标：得到IP->前缀->Origin AS->上游AS路径等可验证信息；
5) 工具链：whois、bgp looking glass、traceroute/mtr、bgp.he.net/RIPEstat、路由镜像；
6) 说明：本文以谷歌云香港（示例）原生公网IP为例，给出完整检查流程与样例数据。

2. 预备工作：获取目标IP与基本信息

1) 获取目标IP：从GCP控制台或VM实例中查看外网IP，例如示例IP 34.80.123.45；
2) 确认区域：在GCP控制台确认该IP绑定的实例位于 asia-east2（香港）区域；
3) 登记信息：记录实例ID、VPC、子网、外网IP、内网IP、机器规格（如n1-standard-1）；
4) 基本连通性：本地执行 ping -c 4 34.80.123.45 与 traceroute -n 34.80.123.45；
5) 端口检测：nc -vz 34.80.123.45 22 / 80 / 443 检查服务是否对外响应；
6) 备注：所有命令建议在有公网出口的跳板主机或运维电脑上执行以避免误判。

3. whois 与路由前缀查询（示例操作与输出）

1) 命令示例：whois 34.80.123.45；
2) 预期信息：网络段（NetRange/route）、组织（OrgName）、注册对象（Google LLC）、相关联系人与RDNS；
3) 示例whois（简化示例输出，仅供参考）：

NetRange:       34.64.0.0 - 34.127.255.255
CIDR:           34.64.0.0/11
OrgName:        GOOGLE LLC
NetHandle:      NET-34-64-0-0-1
Country:        US

4) 进一步查询：在 bgp.he.net 搜索该IP，确认 Origin AS 和公告前缀；
5) 注意：whois结果会显示归属组织与注册范围，但Origin AS需用BGP视图确认实际公告者；
6) 建议：把whois结果与IRR（路由注册库）记录做对比，判断是否存在不一致的公告。

4. BGP路由溯源：AS路径与Origin AS核验流程

1) 使用公共Looking Glass：访问如 bgp.he.net、ris.ripe.net 或各大运营商LG查看该前缀路由；
2) 命令示例（本地或远端路由器）：bgp route show prefix 34.80.123.45/32（或使用vtysh）；
3) 关注点：Origin AS（通常为15169——GOOGLE）与AS_PATH链路；
4) 示例表格（示例数据，表格居中，边框1，文字居中）：

IP	前缀	Origin AS	AS_PATH示例
34.80.123.45	34.64.0.0/11	15169	15169

5) 说明：若AS_PATH中有非Google ASN（如AS9808等本地ISP）并在前面，则需关注是否存在策略NAT或转发；
6) 若发现Origin AS与whois登记不一致，应立即进一步用多点LG和RIPE/ARIN工具比对，确认是否为劫持或临时转发。

5. 路径追踪与延迟/丢包排查（traceroute/mtr实操）

1) traceroute -n 34.80.123.45：查看每跳IP与延迟，识别进入Google骨干的节点；
2) mtr -r -c 100 34.80.123.45：进行连续测量获得丢包和延迟分布；
3) 典型输出要点：跳数进入Google骨干时常见为AS15169路由器，延迟从香港至目标在10-50ms范围内（示例值）；
4) 示例traceroute（简化）：

1  10.0.0.1  1.0 ms
5  203.208.XXX.XXX  15.2 ms  AS9808
8  108.170.252.33  22.3 ms  AS15169
10 34.80.123.45  24.1 ms

5) 分析要点：若本地到Google入口前丢包或高延迟，应联系上游ISP；若Google骨干内部异常则可提交GCP支持工单并附上mtr数据；
6) 建议保留带时间戳的mtr/traceroute输出，作为与ISP或云厂商沟通的证据。

6. DDoS、CDN与路由安全防护策略建议

1) DDoS防护：在GCP上建议启用Cloud Armor与外部负载均衡（HTTPS LB）以做L7防护；
2) CDN接入：若使用CDN（如Cloud CDN或第三方），需要确认CDN边缘节点不会引入不期望的AS_PATH；
3) Anycast与原生IP：原生IP在谷歌骨干内通常由15169公告，Anycast场景下多个POP可同时公告同一前缀；
4) 路由过滤：在企业边界实施最大前缀长度、RPKI/ROA验证可以防止被错误公告；
5) 事件响应：若怀疑BGP劫持，记录时间、AS_PATH、影响前缀并向NOC/ISP与GCP提交SR；
6) 运营示例：某客户在香港部署Web服务器（n1-standard-2 + 50GB SSD），遭遇短时流量突增，通过Cloud Armor规则与自动缩放减少后端压力并提交BGP证据由ISP过滤异常流量。

7. 真实案例与配置示例（演示数据与处理流程）

1) 案例简介：公司A在GCP香港部署电子商务站点，外网IP示例34.80.123.45，遭遇流量突增与路由异常；
2) 初步检测：通过whois、bgp.he.net确认前缀由AS15169公告；但部分区域用户显示达不到Google骨干，traceroute在中间AS存在长时间抖动；
3) 配置示例（服务器）：VM类型：n1-standard-2，系统盘50GB SSD，防火墙：仅开放 22/80/443，Cloud Armor策略：rate-based rule 1000 rps；
4) 处理流程：收集mtr/traceroute、AS_PATH截图 -> 联系上游ISP并提供RRC/Whois -> 提交GCP支持单附日志 -> 配置Cloud Armor并临时启用CDN清洗；
5) 结果与数据：通过Cloud Armor拦截了约85%可疑请求，mtr显示进入Google骨干前抖动恢复正常，站点RTT从120ms降回25ms；
6) 复盘建议：长期启用RPKI监控、定期备份路由观测数据并在SLB层做速率限制与黑名单策略。

来源：技术实操 谷歌云 香港 原生ip BGP路由和AS号溯源的检查流程