1 公网访问回答什么问题：谁必须从互联网可达
订单系统已经有了路由，也配置了安全组与网络 ACL，接下来仍有一个独立决策：哪些资源应该接受互联网主动发起的连接？C9 给路径，C10 给允许，C11 决定暴露面。公网可达、安全组放行、业务健康是不同结论。规则允许访问，并不能替资源创造公网地址；连接能建立，也不能证明订单接口能正常处理请求。
先列出必须从互联网发起的流量，再选择入口。订单系统至少有 3 类发起方：客户访问 HTTPS 网站，运维人员进入管理通道，支付平台发送订单回调。客户和支付平台通常需要访问公开的业务名字；运维人员可以经过受控管理入口，不必直接连接每台应用服务器。数据库供应用调用，并没有因此产生让互联网直接连接它的需求。
可以用一句完整的话检验需求：“谁从哪里，访问哪个名字的哪个服务，为什么必须由外部主动发起？”“应用要下载补丁”描述的是出站需求，不能用来证明应用需要入站公网地址。“数据库偶尔要维护”描述的是管理需求，不能直接推出要公开数据库端口。其余没有明确理由的资源默认保持私有，再为确实需要的流量设计通道。
这里的公网暴露面包括地址、协议、端口、来源范围，以及持续开放的时间。1 个公网地址可以只开放 HTTPS，也可以同时开放多个管理服务，两者的暴露面差异很大。反过来，没有直接公网地址的应用，仍可能通过公开入口提供业务能力；“私有应用层”指外部不能绕过入口直接建立连接，并不意味着客户无法使用应用。
这份发起方清单是后续验收的依据。客户必须成功访问订单入口，陌生互联网来源必须无法直连数据库，运维必须通过指定通道完成登录。成功与失败都要有预期，否则“全部能通”可能正是设计错误。
2 公网地址：固定与动态、与网卡的绑定
公网 IPv4 地址稀缺，通常也是需要单独管理的资源。动态公网地址可能在停止再启动、释放或替换实例后变化，具体生命周期由产品决定，不能把某次查到的地址当作长期承诺。弹性或固定公网地址的核心价值，是把地址的生命周期与某台计算实例适度分离，让地址能够保留并重新关联到受支持的资源。
例如，原入口的私网地址为 10.20.1.10，对外使用文档示例地址 203.0.113.10。替换实例后，新入口的私网地址变成 10.20.1.11。如果产品支持，可把保留的弹性公网 IP 从旧资源解绑并关联到新资源。外部仍访问原公网地址，内部承接连接的机器已经改变。解绑、重绑期间可能中断，既有连接也未必保留；固定的是地址，不是应用状态或连接状态。
地址究竟绑定到实例、网卡还是网卡上的某个私网地址，各云产品并不相同。以某些 AWS 形态的 IPv4 机制为例，公网地址在平台边界映射到网卡的私网地址，操作系统中未必能直接看到这个公网地址。它是理解映射的例子，不是所有云的实现规定。排查时同时查看平台记录的关联对象和主机实际地址，不能仅凭主机没有显示公网 IP 就判定绑定失败。
这也提供了理解 DNAT、端口转发的直觉：进入边界的报文原本发往公网地址，转换后交给内部地址。若产品提供端口转发，还可能把“公网地址的某端口”映射为“内部地址的另一个端口”。地址或端口的转换只解决交付目标，不自动允许访问，也不会替目标启动服务。普通弹性公网 IP 关联不等于任意端口转发功能，是否支持转换端口应查对应产品能力。
释放旧实例前，要确认地址是否保留、是否随实例回收、由谁承担闲置费用，以及重绑操作依赖什么资源。把公网地址、关联对象和业务名字放在同一份记录里，才能在迁移时发现漏项。若同时启用 IPv6，要另外验收 IPv6 地址、默认路由和过滤策略；IPv4 弹性地址的重绑成功，不能代表 IPv6 路径已经正确。
3 入站路径：Internet 网关、路由与策略叠层
从外部访问云内服务，可以沿“互联网 → Internet 网关 → 子网路由 → 网络 ACL → 安全组 → 监听进程”理解各环节的责任。这里是便于检查的逻辑路径；平台实际转发和过滤的位置可能不同。Internet 网关是 VPC 与互联网连通的边界能力，不是业务进程，也不是替所有实例自动开放端口的开关。
在典型 AWS 形态示例里，公有子网的关联路由表有 0.0.0.0/0 → IGW，Internet 网关已附加到正确的 VPC，目标另有公网地址或地址映射。默认路由也关系到响应能否返回互联网；不要把路由表想成按图示逐框执行的应用流水线。其他云可能采用不同网关和路由表达，但公网地址、往返路径、策略许可、服务监听这几类条件仍然需要分别成立。
“公有子网”通常描述路由属性，不保证其中每台机器都能从公网访问。机器没有公网地址，即使默认路由指向网关，也不因此获得可供互联网访问的身份。有公网地址却缺少正确路由，也可能无法完成往返通信。已经允许来源的安全组，则只回答某类报文是否可以通过，不负责补齐地址或路径。
使用固定的 6 项验收清单，可以防止检查到安全组就停止：
- 地址：入口当前公网地址是否存在，是否关联到了本次要访问的网卡或实例。
- 路由：网关与子网路由是否正确，返回客户端的路径是否成立。
- NACL：沿用 C10 的结论，业务流量和所需返回流量是否允许。
- SG：目标实际附加的安全组是否允许本次协议、端口和来源。
- 监听：服务是否监听正确地址与端口，而非仅监听
127.0.0.1。 - 应用响应：请求是否进入正确服务，并获得预期业务结果。
例如，外部请求 HTTPS 的 TCP 443，而主机上 ss -lnt 只显示 127.0.0.1:443，同机请求可能成功，公网请求却无法由该监听接受。应根据服务设计调整监听地址，并确认主机防火墙等附加条件，而不是反复扩大云侧来源范围。监听 0.0.0.0:443 表示接受所有本机 IPv4 接口上的连接，仍须由其他边界条件决定哪些来源能到达。
出站与入站也不对称。私有应用通过 NAT 出网下载依赖，外部网站看到的是转换后的源地址；这不代表互联网可以用同一地址主动连回应用。主动出站后返回的数据，与外部新建的入站连接是不同事件。设计中若只有下载、更新等需求，应保留出站路径，不要为此追加公网入站入口。
4 管理入口：堡垒机与代理式运维的取舍
业务入口与管理入口服务于不同人群，应分别决策。客户需要访问订单服务，不需要访问 SSH 22 或 RDP 3389。让每台应用都公开管理口，会把管理员身份验证之前的网络暴露扩展到整批机器；即便凭据很强，也增加了扫描、错误配置和服务漏洞被触达的机会。
堡垒机或跳板把管理连接集中到少量入口。运维先从指定网段或经 VPN 到达入口，再沿私网进入目标。应用的管理端口只允许这条管理路径，不直接接受任意互联网来源。集中入口便于记录会话、限定目标和核对操作人，但这些能力需要实际配置与审计存储支持，不能因机器被命名为“堡垒机”就认为已经具备。
代理式运维使用实例内代理、远程命令通道或类似机制，经控制面或专用 endpoint 建立管理能力，实例无需开放公网管理口。它可能依赖实例主动出站、代理在线、控制面连通与操作授权。使用专用 endpoint 时，还要核实其网络可达性和产品支持范围。它减少的是网络管理入口，不是取消对操作身份、命令记录和结果复核的要求；具体权限设计留到 C15。
选择时可以用具体故障反推依赖：如果系统代理没有启动，远程命令是否仍能执行？如果运维 VPN 不可用，堡垒入口能否到达？如果主机网络配置已损坏，常规网络管理通道可能都失效，是否有受控控制台或其他恢复手段？破窗能力应事先安排授权、使用期限和留痕方式，而不是故障发生后才给所有机器永久开放 22。
例如，日常操作全部使用代理通道，紧急恢复保留经审核启用的堡垒路径。演练时既验证正常通道能执行必要命令，也验证紧急路径可启用、可审计、可关闭。运维结束后恢复既定边界。方案的重点是明确日常入口和故障依赖，不需要在本课展开完整的零信任产品比较。
5 名字与证书直觉：DNS 指向与对外身份
用户通常访问名字，例如 orders.example.com，而不是记住公网 IP。公网 DNS 的 A 记录把名字指向 IPv4 地址，AAAA 记录指向 IPv6 地址。解析结果告诉客户端接下来连接哪里；证书则用于让客户端核验所连接服务是否能证明这个名字的身份。DNS、网络可达性和身份核验相互衔接，却不是同一个检查。
证书通常围绕名字签发与验证。浏览器访问 orders.example.com 时，会检查证书是否覆盖这个名字，而不是认为连接到了某个公网地址就足够可信。除非证书明确覆盖所访问的 IP 地址，否则直接把 URL 改为 IP，可能得到证书不匹配。多个名字也可能共用地址，直接访问 IP 未必进入原来的站点。因此“IP 能打开某个页面”不能代替对正式名字的验收。TLS 细节见 S20，本课只保留名字与对外身份的直觉。
假设原 A 记录指向 203.0.113.10，切换后入口改为 203.0.113.20，TTL 为 300 秒。缓存刚更新的解析器可能继续使用旧值约 300 秒；不同客户端缓存到期时间不同，切换不会同时发生。TTL 是缓存有效期的提示，不是“全网必在此刻刷新”的倒计时。若要提前降低 TTL，应在切换前给旧 TTL 留出足够时间，否则旧缓存不会因为权威记录的新 TTL 而提前失效。
弹性公网 IP 若成功迁到新机器，且对外地址不变，通常无需仅为这次关联变化修改 A 记录，但仍须检查新机器的证书与服务配置。若新入口使用不同地址，就要按计划更新 DNS，并在切换窗口保留合理的旧入口处理方式。改了地址但忘记 DNS，客户端仍然奔向旧目的地；DNS 正确但证书名错误，用户仍会看到身份验证失败。
验收时分别记录 dig orders.example.com A 和 dig orders.example.com AAAA 的结果，再从外网用正式名字请求。双栈环境尤其要观察客户端实际选用的地址族：IPv4 正常、AAAA 指向失效入口，也会产生部分用户失败。不能只查看 1 条 A 记录就宣布整个名字切换完成。
6 收束暴露面：最小端口、来源与临时开放
收束暴露面从“服务需要什么”出发。面向所有客户的 HTTPS 入口可能需要接受广泛互联网来源；管理端口和合作方专用接口则通常有更窄的来源范围。最小化并不等于把所有端口都限定为某个固定前缀，而是让开放范围与真实调用者对应。第三方回调若有官方出口范围，应有更新与核实方式，不能把过期地址清单长期当作保证。
以 IPv4 管理口为教学例子，0.0.0.0/0 覆盖约 42.9 亿个源地址，/24 覆盖 256 个，/32 覆盖 1 个。把 22 的来源从 /0 收到某个运维出口 /32，在地址数量上约缩小 42.9 亿倍。这只是规则覆盖的地址空间比值，不等于实际攻击概率按同一倍率下降；公网地址的活跃度、来源伪装限制与入口认证机制都不包含在这个数字里。
填写来源时，应使用云端真正观察到的来源地址。运维笔记本可能有 192.168.1.8，但经过办公室出口 NAT 后，公网入口看到的是公司的公网出口。把笔记本私网地址填入公网来源规则，通常不能满足需求。若出口动态变化，要设计 VPN、固定出口或受控更新方式，不能以地址变化麻烦为由长期退回 /0。
临时开放必须是一条有生命周期的变更。例如，工单记录“仅运维出口访问 22，14:00 至 14:30，由值班人员回收”，并同时设置提醒或自动到期机制。排障提前完成就提前关闭；确需延长则重新确认理由和期限。到期时间无人执行不构成闭环，回收后还要从原来源复测，确认入口确已关闭。
维护暴露面清单时，至少写资源、端口、来源、负责人、复核日，并注明地址族和开放理由。既看预期配置，也看当前有效配置，包含附加安全组、端口转发和 IPv6 路径。清单的作用是让团队能够回答“此刻互联网还能从哪里进入”，而不是只保留最初上线时的架构图。边缘防护产品可以在后续专题进一步讨论，不能替代这份最小入口决策。
7 常见坑：给数据库绑公网、EIP 当永久入口、临时全开不收回
给数据库或缓存绑定公网地址，常常源于一次维护方便，随后变成长期依赖。即使当前规则只允许少量来源，它仍增加了额外公网入口及其维护负担。更稳妥的做法是先确认数据库管理是否能走堡垒或代理路径；业务应用继续用私网连接。若某种服务确实需要公网接入，应单独论证调用方、来源、协议与保护措施，不能把“连接工具好用”当成架构理由。
把 EIP 当作应用永久入口，也容易混淆地址稳定与服务稳定。地址可以保留，但旧机器故障后谁来关联新机器、应用是否就绪、证书是否齐全、客户端连接是否需要重建，都仍要处理。外部系统直接写死 IP 后，地址调整还会变成跨团队协调。正式业务宜使用受管理的 DNS 名字，并把地址迁移与名字切换流程写清；固定地址是工具，不是完整的连续服务方案。
“先开放 0.0.0.0/0 再排查”会让临时状态悄悄变成基线，而且可能掩盖真实问题。若原故障在服务只监听回环地址，扩大来源没有任何修复作用。变更前记录具体假设、最窄范围和回滚时间，测试后核对结果；不要把某次偶然恢复归因于最后改动的所有规则。
只测 ICMP 是另一种误判。允许 ping 的规则与允许 TCP 443 的规则可以完全不同。ping 成功只说明某种 ICMP 请求获得了回应，不能证明 TLS、HTTP 或订单接口正常；ping 失败也可能只是没有允许 ICMP。应以目标协议和业务名字为主，必要时再用 ICMP 辅助观察，避免为追求 ping 成功而增加无关入口。
最后检查 IPv6。关闭 IPv4 管理口后，若 IPv6 仍允许 ::/0，双栈主机可能继续向全网开放同一服务。还应核对所有附加安全组的有效允许范围：某个严格组不会自动抵消另一个组的宽泛允许。沿用 C10 已学的组合语义即可，不必重新绘制策略矩阵；本课要追问的是这些允许最终暴露了哪些资源。
8 案例：订单系统只让入口层对公网
承接 C9、C10 的订单系统，保持既有路由和过滤结论，把资源分为入口、应用、数据库。入口位于公有子网并持有公网地址；应用与数据库位于私有层，没有供互联网直接访问的公网地址或入站端口映射。原需求中的“app/db 无私网入站公网路径”，在这里落实为：公网无法绕过入口直接建立到应用或数据库的连接，内部必要的私网调用仍保留。
客户和支付平台访问 orders.example.com:443。入口接收外部请求，再经私网调用应用；应用经私网访问数据库。这里先保留入口层职责，下一课 C12 再讨论由负载均衡服务承接它。运维采用代理通道，或经受控堡垒进入私网；应用的 22 不对互联网直接开放。入口上线也不意味着数据库要同步获得公网地址。
连接矩阵增加“公网暴露”列后，业务连通和互联网入口就能同时审阅。下表只记录本课的访问意图，具体过滤规则继续沿用 C10 的设计。
| 发起方 → 目标 | 业务用途 | 公网暴露 | 验收结果 |
|---|---|---|---|
| 客户 → 入口 443 | 浏览与下单 | 是，公开业务入口 | 外网正式名字请求成功 |
| 支付平台 → 入口 443 | 支付回调 | 是，指定回调路径 | 授权回调得到预期响应 |
| 入口 → 应用 8080 | 转交业务请求 | 否，私网调用 | 内部请求成功 |
| 应用 → 数据库 5432 | 订单读写 | 否，私网调用 | 内部业务读写成功 |
| 运维 → 管理通道 | 日常维护 | 受控通道 | 指定身份与路径成功 |
| 陌生外网 → 应用或数据库 | 无业务需求 | 否 | 无直接连接路径 |
假设应用有 4 台、数据库有 2 台。初始方案给 6 台机器都分配公网地址，再逐台维护来源规则；收束后业务层只保留 1 个逻辑公网入口，6 台内部机器均不接受直接公网业务连接。这个计数是当前教学架构的暴露清单，不是高可用容量设计；生产入口需要多少承接资源，应结合后续课程确定。若使用公开堡垒，它还要作为单独管理入口计入清单，不能因为不是业务入口就漏算。
变更应分步完成。先让入口到应用、应用到数据库的私网调用正常，再把正式名字指向入口并进行外网业务验收；随后撤销应用与数据库不再需要的公网关联或映射，最后确认管理通道可用且旧管理入口关闭。每步保留明确回退点，避免先切断唯一管理通道，再发现代理尚未上线。
正向验收从真正的外部网络执行 curl -v https://orders.example.com/health，确认名字、证书和预期响应，再执行受控的下单与回调测试。健康检查成功只能证明该接口，仍要有业务级证据。负向验收应结合资源配置和外网探测：核实 app/db 没有公网地址或转发入口，并对历史地址、可能的遗留入口尝试相应端口连接。只从应用旁边的机器测试私网连通，不能证明互联网边界已经收束。
9 排查案例：公网 ping 通业务不通、换机后不可达、管理端口暴露
排查先固定“发起方、目标名字、实际解析地址、协议端口、发生时间”。同一个名字在不同网络可能解析到不同地址，旧 DNS 缓存又可能把请求送往旧机器。记录这些条件后，再用外网与内网对照探测定位。不要同时改地址、来源规则和服务配置，否则恢复后也难以确认原因。
路径 A：ping 通，HTTPS 超时。 外网能 ping 203.0.113.10，但连接 TCP 443 超时。先确认这个公网地址关联的是当前入口，路由与 NACL 符合已验收设计，再查看目标实际附加的全部安全组。发现 ICMP 已允许，而 443 只允许旧测试出口；因此 ping 成功与业务失败并不矛盾。把 443 的来源修正到已批准的业务范围后，重新从相同外网发起请求。
若策略已正确，继续在主机查看 ss -lnt。假设结果只有 127.0.0.1:443，同机 curl 成功，但从同子网另一台机器连接私网地址也失败，证据指向监听地址。修正服务监听并检查主机侧过滤后，依次复测私网和公网。若 TCP 已建立却收到错误状态码，应继续看应用日志、站点配置与依赖响应，不再把所有失败都归为网络不通。
路径 B：换机后，用户仍访问失败。 新入口私网探测成功，说明其服务至少在测试条件下可用。平台地址记录却显示弹性公网 IP 仍关联旧网卡，而旧机器已停止。此时应执行计划内的重绑并确认关联完成，再测试公网；给新机器再加一条宽泛安全组规则不能把旧关联搬过来。迁移记录应同时包含旧关联、新关联和切换时间。
另一种情况是新机器已经使用新公网地址，但 dig orders.example.com A 仍返回旧值。应核对权威记录、实际使用的解析器与缓存窗口，而不是让用户绕过证书检查直接访问新 IP。若权威记录已更新，部分缓存仍旧，则按预定窗口观察并保留必要的过渡服务。双栈名字还应检查 AAAA；A 正确而 AAAA 留在旧入口，可能解释“有人正常、有人失败”。
路径 C：管理口本应受限，却能从陌生外网连接。 先在授权范围内从指定测试网络确认 TCP 22 是否可建立连接，记录来源与时间，不必尝试密码。再把目标附加的全部安全组列出。假设运维组只允许公司前缀，另一个遗留测试组却允许 0.0.0.0/0 访问 22；按安全组有效允许并集，后者已经扩大暴露。关闭宽泛允许后，同时检查 IPv6 是否还有 ::/0 和是否存在其他端口转发。
这 3 条路径的证据分别来自公网地址关联、路由表、有效安全组、主机监听、DNS 查询，以及外网和内网对照。记录“连接超时”“连接被拒绝”“证书失败”“应用错误响应”等具体结果，比笼统写“不通”更有价值，但单个现象通常不能唯一定位。例如超时可能发生在多个过滤或转发环节，应结合配置与日志收窄，而不是凭超时直接认定安全组有错。
修复完成要重复原来的失败请求，并验证原本不该开放的路径依旧关闭。路径 C 尤其需要双向结果：公司指定通道能够管理，陌生外网无法直接连接。最后回收排障期间新增的临时规则，把实际关联、DNS 和负责人更新到清单，避免本次修复制造下一次遗留入口。
放进方案里
公网访问方案先交付必须由互联网发起的流量清单。按客户、运维、合作方分别写清发起位置、目标名字、协议端口与必要性，说明哪些调用使用私网。每项公网需求都应能追溯到业务理由；下载补丁等主动出站需求单独记录，不能自动获得入站开放资格。
写明公网地址的类型、关联对象和生命周期，标出地址释放、实例替换、网卡变更时的处理人。列出正式 DNS 名字、A 与 AAAA 记录、TTL、证书覆盖名字，以及切换时如何观察旧缓存和回退。固定地址也要有重绑流程，避免把“地址保留”误写成“服务自动恢复”。
画出入口与私有层的边界，明确只有哪些资源承接公网连接，应用和数据库怎样通过私网被调用。另写管理入口采用堡垒还是代理通道，日常依赖是什么，故障时如何受控恢复，恢复完成怎样关闭临时路径。公开堡垒也应计入公网入口数量。
附上当前暴露面表，逐项填写资源、地址族、端口、允许来源、负责人、复核日和开放理由。临时变更增加到期时间、回收责任人及回收后的复测记录。对合作方来源范围和运维出口变化，指定核实与更新方式，使清单能随环境变化维护。
验收同时包含正向与负向结果：从真实外网用正式名字访问入口并完成代表性业务；核实应用、数据库和管理口不能被非预期来源直接连接；从指定管理通道完成必要操作。证据保留解析结果、公网关联、有效策略、监听状态与探测时间，双栈分别检查。交付时确认临时开放已经回收，遗留地址与 DNS 已按计划处理，并约定下次复核日期，让入口收束成为可重复检查的运行要求。
10 小结：公网入口收束与负载均衡衔接（C12）
公网访问设计从必须接受外部连接的流量开始，依次落实地址与关联、往返路径、策略、监听和业务响应。DNS 为入口提供可维护的名字，证书帮助核验名字对应的身份；管理通道则单独控制。应用和数据库保持私有，配合正负向外网验收，才能证明入口确已收束。
现在订单系统已经明确“哪些请求进入、从哪里进入、哪些资源不能被直接访问”。下一课 C12 将用负载均衡服务承接入口层，把这里确定的公网边界继续落到可运行的服务设计中。