VPC

1 VPC 回答什么问题：逻辑隔离与地址边界

在 C8 文件存储中，应用要通过网络访问共享目录。同样的挂载地址，为什么某台应用能访问，另1个项目的主机却不能访问？回答前，需要先说明地址属于哪个网络、数据包要跨过哪些边界。VPC（Virtual Private Cloud，虚拟私有云）就是租户侧组织这些关系的逻辑网络边界，包含地址范围、子网、路由以及连接外部网络的网关。

可以把 VPC 看成带有独立地址账本和转发规则的网络空间。项目甲和项目乙都使用 10.20.0.0/16，并不意味着它们自动互通；云平台把流量放在不同的逻辑网络上下文中处理。私有地址本身也不是全球唯一身份。运维记录中的 10.20.10.25 必须同时带上项目、VPC 和区域，才能明确指向哪块网络接口。

这种隔离解决了共享基础设施上的网络归属问题，却不等于绝对安全。接入公网、连接办公网或建立 VPC 对等连接，都会引入新的可达路径。网络一旦相连，就要回答谁需要访问谁、访问什么服务、哪些方向必须禁止。路由决定流量能往哪里送，安全组等策略过滤决定是否允许通过；后者的规则设计留到 C10。

设计时先问“哪些流量必须进入或离开这条边界”。订单系统可能需要接收客户请求、调用支付接口、访问云对象存储，并接受办公网的运维访问。这些需求分别对应公网入口、主动出网、服务终端节点和跨网络连接。先把必要关系写清，再选网关，能够避免画出很完整的网络图，却漏掉真正的业务路径。

图上的边界表示流量需要通过明确配置的连接跨越，并不表示每个连接天然可信。检查一张 VPC 图时，应能指出内部地址空间、对外连接点及其用途。只写“业务部署在私有云中”，无法解释用户如何进入、应用如何更新、故障时如何取得证据，也不足以让后续的策略设计落地。

2 地址规划：CIDR、子网与可用区放置

CIDR 用地址加前缀长度描述连续地址块。10.20.0.0/16 的前 16 位固定，剩余 16 位用于块内地址，因此包含 2^16 = 65536 个 IPv4 地址。把其中1块划为 /24，块内有 2^8 = 256 个地址。前缀数字越大，地址块越小；地址总数还要扣除平台保留地址，才能估算可分配数量。

选 VPC CIDR 时，先收集办公网、已有 VPC、容器网络和未来合作网络的地址范围。私有地址可以在隔离环境中重复使用，但重复空间相连时，会出现目的地址究竟属于哪侧的问题。某些平台直接禁止重叠网段建立对等连接；即使借助地址转换绕行，也会增加排障成本。为将来互通保留不冲突的空间，通常比事后改地址容易。

以订单系统为例，选 10.20.0.0/16，在 2 个可用区分别放置公有、应用、数据子网，共 6 个子网起步。可以先按下表分配 /24，并把相邻空块登记为预留。这里的编号服务于阅读和运维，真正决定范围的是 CIDR，不能靠名字判断地址归属。

子网绑定可用区，不能把同1个子网理解为跨区地址池。高可用应用需要在不同可用区分别准备子网和容量。地址预算也不能只数当前主机：负载均衡、托管数据库、接口型终端节点、容器及滚动发布都可能消耗网络接口地址。平台是否允许扩充 VPC 地址范围、子网能否调整大小，应在确定方案前核对。

假设所选平台在每个子网保留 5 个地址，/24 的教学可用量是 256 - 5 = 251。应用子网有 80 个常驻实例，发布时临时增加 80 个，再给其他网络接口预留 30 个，共需 190 个，还剩 61 个。换成 /25 后只有 128 - 5 = 123 个，日常看似够用，发布却会失败。保留数量随平台变化，不能把这个例子的 5 当成通用常数。

“私有子网”是路由与地址配置形成的结果，不是名称带来的能力。把子网命名为 private，却关联了通往 Internet 网关的默认路由，仍需按实际路径审查。地址规划表应同时记录用途、可用区、容量预算和路由表关联，才能从规划走到部署。

3 路由表：本地路由、网关与下一跳选择

路由表描述“目的前缀 → 下一跳”。数据包带着目的地址到达路由判断点后，系统查找匹配条目，再决定交给本地网络、网关、对等连接或其他受支持目标。云路由表是平台转发的一部分；实例里执行 ip route 往往只能看到默认虚拟网关，不能据此断言 VPC 后续没有路由。

VPC 地址范围通常有平台维护的本地路由，例如 10.20.0.0/16 → local。它为同 VPC 的子网通信提供基础路径，具体可覆盖和重定向能力依平台而定。应用从 10.20.10.25 访问 10.20.20.40 时，应先核对应用子网实际关联的路由表，再看返回方向。不能只找到一张名称相似的路由表，就认为所有子网都使用它。

存在多个匹配项时，通常按最长前缀匹配选择更具体的路径。设某张表有 10.20.0.0/16 → local、10.60.0.0/16 → 对等连接 和 0.0.0.0/0 → NAT。目的 10.20.20.40 选择本地，10.60.8.9 选择对等连接，其余未被更具体条目覆盖的 IPv4 地址才落到默认路由。默认路由不是优先级最高，而是范围最宽的兜底。

再增加 10.60.8.0/24 → 某检查设备，访问 10.60.8.9 就改走该设备。即使原来的 /16 路由正常，新加的 /24 指向失效目标，也可能让这1小段地址全部超时。部分云平台将目标已删除或不可用的条目标成黑孔；数据包通常被丢弃，而不会自动退回较宽的可用路由。排障时要检查实际命中的条目及目标状态。

路由描述下一跳，不保证下一跳以后仍然畅通。经 NAT 的流量还要从 NAT 所在子网继续到公网，经对等连接的流量还要在对端找到目标并返回。路由审查因此要沿路径逐段展开，记录每段入口、目的地址、匹配前缀、下一跳和返回路径，而不是只检查有没有 0.0.0.0/0。

改路由等于改拓扑。替换默认下一跳，可能让整批应用改走另1个出口，改变公网源地址、流量费用及外部白名单匹配。提交变更时应保留旧表和关联关系，说明受影响子网，先测代表连接，再逐步切换。回滚也必须明确恢复哪个目标和哪项关联，不能只写“恢复网络配置”。

4 出网与入网：Internet 网关、NAT 与公有/私有路径

Internet 网关（IGW）连接 VPC 与公网。按常见 IPv4 模型，子网有指向 IGW 的路由，资源还需要平台支持的公网地址映射或公网入口，才具备从公网访问的条件。把 IGW 挂到 VPC 上，不会给所有实例自动分配公网地址，也不会代替服务监听和策略过滤。负载均衡的公网入口与实例自身的公网地址，是需要分别确认的资源。

公有子网通常具有指向 IGW 的公网默认路由；私有应用子网常把默认路由指向 NAT，或根本不设公网默认路由。子网是否公有描述的是网络路径，子网内某台资源是否实际公网可达还取决于地址和入口配置。1个有 IGW 路由却只有私有 IPv4 地址的实例，并不会因此自动拥有直接访问公网的能力。

NAT 让私有地址发起的连接借用出口地址与公网通信。应用连接第三方 API 时，流量先到 NAT，再经公网路径出去；响应按已有转换状态返回应用。第三方看到的是出口公网地址。这个过程不会让任意公网客户都能主动连接应用的私有地址，也不应把 NAT 当成面向用户发布服务的入口。

在前面的地址规划中，可让 A 区应用子网默认指向 A 区 NAT，B 区应用子网指向 B 区 NAT；每个 NAT 所在公有子网再以 IGW 为默认下一跳。这样需要承担 2 个 NAT 的固定费用，却能减少依赖单个可用区出口的情况。若共用 1 个 NAT，应明确跨区费用、故障影响和恢复方式，不能仅凭“有出网”就判断设计合格。

算1次发布流量：50 个实例各拉取平均 200 MiB 的镜像数据，首轮下载量为 50 × 200 = 10000 MiB，约 9.77 GiB。若其中 10 个实例各完整重试 1 次，再增加 2000 MiB，总量约 11.72 GiB。这只是下载负载估计，账单仍要结合平台计量单位、NAT 处理方向、公网传输和跨区费用计算。镜像缓存、分批发布与失败重试上限，都会改变出口压力。

数据量还不等于瞬时容量。50 个实例同时拉取与分 5 批拉取，累计下载接近，带宽峰值和连接压力却不同。验收应记录出口公网地址、并发连接表现、失败比例及重试原因，避免把远端限速误判成无路由。需要固定出口白名单的第三方服务，还要核对各可用区 NAT 的出口地址是否都已登记。

IPv4 与 IPv6 的地址、路由和出入站能力需要分别判断。0.0.0.0/0 不覆盖 IPv6，IPv6 默认前缀是 ::/0；不能把 IPv4 NAT 的结论直接套给 IPv6。应用若优先使用 AAAA 记录，实际流量可能走另1条路径。方案应明确启用哪种地址族、各自出口是什么，并分别完成验证。

5 私有连通云服务：终端节点与解析

应用访问对象存储、镜像仓库或其他云服务，不一定要经 NAT 绕到公网。云平台为部分服务提供终端节点，让请求通过受支持的私有路径到达服务。选择前先确认服务、区域、访问方式和终端节点类型是否匹配。终端节点只能连接其支持的目标，不能把任意第三方公网 API 变成私有服务。

常见的网关型终端节点通过路由表把特定服务前缀导向服务入口，通常不表现为用户子网里的1组私有接口地址。接口型终端节点则通常在选定子网中创建网络接口，以私有地址承接连接，并可借助私有 DNS 让原来的服务域名解析到这些接口。具体命名和支持范围随平台变化，应按实际产品核对。

这2种类型的验收方法也不同。对网关型，需要看服务前缀对应的路由是否加入正确的子网路由表，不能仅靠 dig 是否返回私有地址判断成功。对接口型，需要核对终端节点接口地址、私有 DNS 是否启用、VPC 是否使用能够获得这些记录的解析器，以及实际连接是否到达这些接口。

例如应用原先通过 NAT 访问对象存储，创建终端节点后下载仍然成功，并不能证明已切换路径。若关联了错误的路由表，或应用继续使用外部 DNS，成功流量可能仍走旧出口。应保存切换前后的解析结果、目标地址、相关路由与流量记录，结合服务端记录或出口流量变化确认。云环境未必暴露每个中间跳点，不能把 traceroute 没显示 NAT 当作充分证据。

还要把路径和权限分开验收。到达终端节点后，服务可能依据端点策略、身份权限或资源权限拒绝请求。出现明确的权限错误，往往说明已经到达某个服务处理环节，应继续检查拒绝来源；连接超时则仍需定位解析、路由和过滤位置。端点策略的范围也应记录，避免把“部署了端点”误读为“该服务全部资源均可访问”。

这套路径验收顺序可以复用于共享文件服务、数据库和外部 API：先确认名字指向谁，再确认源地址从哪里出发，随后逐段解释下一跳。对终端节点尤其要记录请求使用的域名，因为换1个区域域名或服务入口，可能就不再命中已经配置的私有路径。

6 跨网络连接：对等连接与集中互通的边界

VPC 对等连接适合少量网络间的直接互通。例如订单 VPC 使用 10.20.0.0/16，分析 VPC 使用 10.60.0.0/16，可以建立对等连接，让订单数据按需要流向分析服务。连接建立后，两端仍须配置目的网段的路由，并由相应策略允许所需连接。控制台显示连接“可用”，只证明连接资源处于可用状态。

对等连接通常不具备传递性。若 A 与 B 对等，B 与 C 对等，不能推出 A 可以借 B 到 C。A 中写上指向 B 的路由，也不会自动赋予 B 转发到 C 的能力。同样，不能默认借用对端的 NAT、VPN 或专线出口。每种转接关系都需要平台明确支持，并有完整的路由与返回路径。

少量网络时，逐对连接便于理解；网络数量上升后，管理关系会迅速增加。若 6 个 VPC 全部两两直连，需要 6 × 5 ÷ 2 = 15 条连接，每条还有两端路由、权限与变更记录。增加第 7 个 VPC 又会引入 6 条连接。这个数量估算有助于判断何时应研究中转网关、云企业网等集中互通方案。

集中互通提供共同连接点，但并不要求所有网络互相可见。生产、测试、办公等网络仍可以有不同的路由传播范围和访问边界。设计需要记录谁接入、允许到达哪些前缀、默认路由是否进入中心，以及中心故障会影响谁。共享1个中心还会形成共同依赖，需要说明容量、可用性和成本归属。

跨网络前应再次检查地址重叠。相同私有地址在隔离环境中可以共存，连接后却难以用目的地址区分网络身份。还要核对区域限制、DNS 跨网络解析能力、跨区或跨区域费用，并让对端团队认可返回路由。本课讨论到连接与地址路由边界为止，不展开 BGP 等动态路由协议的配置细节。

7 常见坑：默认 VPC 照搬、子网当隔离、只画出站不画回程

默认 VPC 的目标往往是让初次创建的资源容易联网，因此可能已经带有子网、公网默认路由和较宽松的默认配置。直接照搬到生产环境，容易继承没有审查过的暴露面。建成后应逐项核对子网关联、自动公网地址分配、网关和入口资源，说明哪些保留、哪些调整。模板来自官方也不意味着符合当前业务边界。

把应用和数据库放进不同子网，有利于地址管理和路径组织，却不会自动形成微隔离。两者往往已经被 VPC 本地路由覆盖，具备基础转发路径。“数据库在数据子网”不能代替对访问关系的约束，也不能证明其他应用无法连接。子网层面的可达与策略层面的允许，需要在图和验收记录中分别表述。

只画客户端到服务端的箭头，会遗漏返回路径。若应用经过某个网络设备访问外部系统，而返回流量走另1条没有相同连接状态的路径，就可能超时。对于正常互联网连接，不要求每个公网中间跳点完全一致；需要关注的是路由、地址转换和状态设备能否共同支持往返。前向通畅不能单独证明整个连接成立。

“只允许出站 443 就够了”同样不能作为完整判断，返回方向和临时端口的策略语义要在 C10 展开；本课先保证路由层能解释响应如何回到发起接口。尤其是跨 VPC、经过 NAT 或集中检查设备时，应把返回地址写出来，避免把请求发出时的源地址与外部系统观察到的源地址混为一谈。

还有1种常见误判：看到域名能够解析，就认为网络已通。DNS 查询成功只说明某个解析器给出了结果，结果可能是旧地址、公网入口或另1个环境。反过来，公网连通测试成功，也不能证明私有终端节点已经生效。测试要绑定源接口、目标域名、实际目标地址和路径证据，才能回答究竟验证了什么。

最终，“画了1个 VPC”只是开始。图中的每根跨边界连线都应能落到地址、路由、连接资源和验证记录。没有这些信息，后续扩容、接入办公网或更换出口时，就只能靠猜测判断影响。网络方案的完成标准是路径可解释、变更可追踪、异常有证据，而不是图标数量足够多。

8 案例：双可用区3层应用的 VPC 草图

订单系统希望在单个可用区故障时继续提供服务。沿用 10.20.0.0/16 与前述 6 个子网：公网负载均衡在 A、B 区公有子网接入；应用实例位于对应应用子网；数据库部署在数据子网，具体主备与复制行为由数据库产品决定。网络上的跨区放置提供条件，不能替代数据库自身的可用性设计。

客户访问负载均衡的公网域名，负载均衡将请求转发给健康的应用实例。应用通过私有地址或数据库私有域名访问数据库，并主动经本区 NAT 调用第三方支付接口。数据子网没有公网默认路由，数据库备份等需求优先使用受支持的私有服务路径。若数据库确实需要外部访问，应先说明必要性，再增加明确路径。

连接矩阵记录业务依赖，不在这里展开安全组或网络 ACL 规则。每行都要能对应到测试源、目标和成功标准，避免只写“内网互通”。

路由表可按用途拆成公有、应用 A、应用 B、数据等组。公有路由表包含本地路由与 IGW 默认路由；应用 A、B 分别指向各自 NAT；数据路由表保留本地及必要服务路径，不配置通用公网出口。相同路由内容可以复用，但跨区 NAT 目标不同就需要分别表达，不能为减少表数量而掩盖差异。

用1个订单请求验收：客户首先解析负载均衡域名并建立 443 连接；负载均衡另行连接应用 8080；应用访问数据库 5432，并在支付阶段连接第三方 443。这是多段连接，不能假定客户的原始网络连接一直延伸到数据库。每段分别记录发起方、目标地址和返回路径，故障时才能明确问题停在哪个边界。

交付证据包括地址表、路由表截图或基础设施代码，以及从 A、B 区应用分别发起的代表路径测试。再验证数据库不能直接走通用公网出口、对象存储访问命中预期端点，并核对第三方观察到的出口地址。高可用验收还应在受控演练中检查单区不可用时另一侧入口、应用与出口是否都能工作，而不只确认资源分布在 2 个区。

9 排查案例：同 VPC 不通、出网失败、名字通地址不通

排查先建立最小事实：故障发生时间、源网络接口及地址、目标域名及实际地址、协议端口、预期下一跳。不要马上重建网关或放宽所有访问。以下 3 条路径分别从不同证据入手，但每条最终都要回到完整往返连接。超时通常不能单独区分无路由、黑孔或策略丢弃。

路径 A：同 VPC 应用访问数据库超时。 应用为 10.20.10.25，数据库接口为 10.20.20.40。先确认它们确实属于同一 VPC，再查看应用子网关联的云路由表。若存在覆盖目标地址的更具体路由，不能停在“已有 /16 本地路由”的判断上。例如 10.20.20.0/24 被导向已删除设备，就可能命中黑孔；是否允许这类重定向需按平台核实。

将命中前缀、目标状态和数据库子网返回路由保存为证据。若路由均可解释且目标接口存在，应继续查看流量日志、目标服务状态与策略判定，而不是继续添加重复路由。有路由被策略丢弃与根本没有有效下一跳，是不同故障；C10 将进1步处理前1种情况。流量日志也有记录范围限制，未见记录不能独立证明数据包没有发送。

路径 B：应用无法拉取镜像。 实例位于 10.20.10.0/24，仅有私有 IPv4 地址。检查发现它错误关联了公有路由表，默认目标是 IGW。虽然图上“可以到网关”，但实例缺少直接公网地址映射，预期的 NAT 路径也没有被使用。把它按方案关联到应用路由表后，还要确认 NAT 可用、NAT 公有子网可到 IGW，以及出口公网地址有效。

若 NAT 路径已经完整，仍应检查是所有公网目标都失败，还是只有镜像仓库失败。后者可能涉及 DNS、远端限制或连接容量。比较 A、B 区相同请求，可以缩小到特定子网关联或出口；记录失败时 NAT 指标与远端响应，比反复重启实例更有诊断价值。路径修正后要重新拉取并确认实际出口，不能只看配置已保存。

路径 C：名字能解析，服务却不通。 dig 返回 10.99.20.40，而订单环境数据库接口实际为 10.20.20.40。调查发现源 VPC 关联了测试环境的私有 DNS 区，或使用的自定义解析器把查询转发到错误区域。解析动作成功，但得到的是错误目标。直接测试经核实的目标地址若可达，就应优先修正解析链，而不是为错误网段临时增加路由。

保存查询的完整域名、所用解析器、A 与 AAAA 结果、TTL 和私有区关联。修正后等待缓存失效或按规定清理缓存，再确认应用实际连接的地址。对于 TLS 服务，直接使用 IP 可能触发证书名称或 SNI 差异；可使用支持固定目标地址且保留原主机名的客户端进行对照，避免把应用层名称校验失败误诊为网络不通。

这 3 条路径共同需要云路由表、网络接口地址、DNS 查询与流量证据。实例内的 ip route 用于确认主机发往哪个虚拟网关，云路由表解释后续下一跳；必要时在源端、目标端或可观察的转发设备抓包。托管网关无法直接抓包时，用平台日志和指标补齐证据，不假设能够登录每个中间节点。修复后复测原故障路径，并确认相邻正常路径没有被改坏。

放进方案里

把 VPC 写进方案时，先交付地址与放置表：列出 VPC CIDR、各子网 CIDR、所属可用区、业务用途及容量余量。说明地址范围与办公网、已有 VPC 是否重叠，以及给扩容、滚动发布和托管网络接口预留了多少地址。保留地址数量引用所选平台约束，不把整个地址块都算成可用主机。

随后交付路由与网关清单，标明每个子网实际关联哪张路由表，本地、默认和业务特定前缀分别指向哪里。记录 IGW、各区 NAT、出口公网地址与责任人，并写清应用访问外部服务时请求和响应的路径。对数据子网没有通用公网默认路由这一选择，说明其更新、备份和运维需求如何满足。

单独列出公有暴露面，包括公网负载均衡、直接绑定公网地址的资源与用途，使审阅者能够从公网入口追到内部目标。终端节点清单则注明服务、区域、类型、路由关联、私有 DNS 与端点策略范围，并给出判断流量确实走私有路径的证据。不能仅以控制台显示已创建作为验收结论。

对等或集中互通部分应说明两端地址、允许到达的前缀、返回路由及非传递边界。若通过中心连接更多网络，要标明路由传播范围与故障影响。跨团队接入同时记录对端负责人和变更协调方式，避免本端改完后无人确认返回方向。

最后附上业务连接矩阵及验证方法，每条关系给出发起位置、域名、实际目标地址、协议端口和成功标准。验收保存解析结果、路由截图或代码版本、代表连接测试及必要流量日志，并记录单区故障的预期行为。把路由变更的影响范围和回滚关联写进交付物，让后续 C10 能沿着已经明确的路径配置与验证策略过滤。

10 小结：网络边界收束与策略过滤衔接（C10）

VPC 把地址归属、子网放置、路由选择和外部连接组织在可管理的边界内。判断路径时，从实际源地址和解析结果出发，找到命中的目的前缀，逐段解释下一跳、转换与返回路径，再用证据验证。

现在应能解释：为什么不同 VPC 可以使用相同私有地址，为什么私有实例不能仅凭 IGW 默认路由出网，以及为什么对等连接不会自动传递。路径已经明确后，还需要限制谁能访问谁。下一课 C10 将沿这些连接讨论安全组与网络 ACL，把网络可达与策略允许衔接起来。