ACL 规则方向与序号
网络 ACL 是作用在子网层面的无状态访问控制：入站与出站各维护一份独立的规则列表，规则按序号从小到大匹配、命中即生效，未匹配的流量被拒绝。无状态意味着返回流量不会自动放行，必须在反方向单独加规则。因为 ACL 影响整个子网的所有实例，影响面大于安全组，变更窗口与留档要求也更严格。
规则示例（数据库子网）
| 序号 | 方向 | 规则内容 | 说明 |
|---|---|---|---|
| 10 | 入站 | 允许 TCP 3306 源自 10.10.0.0/16 | 应用层访问数据库 |
| 20 | 入站 | 允许 TCP 1-65535 源自 10.10.0.0/16 | 内网管理端口 |
| 100 | 入站 | 拒绝全部 | 兜底显式拒绝 |
| 10 | 出站 | 允许 TCP 1024-65535 目的 10.10.0.0/16 | 返回流量端口段 |
| 100 | 出站 | 拒绝全部 | 兜底拒绝 |
基本信息
| 作用范围 | 子网级别，子网内所有实例 |
|---|---|
| 有无状态 | 无状态，返回流量需单独放行 |
| 匹配方式 | 按序号从小到大，命中即停 |
| 与安全组关系 | 两层同时判定，都通过才放行 |
典型使用场景
- 给数据库子网加一层子网级防线，作为安全组之外的兜底
- 隔离区管控：限制 DMZ 子网只能向指定网段发起连接
- 合规要求：按等保对关键子网做显式拒绝与审计留痕
- 与安全组分工：ACL 管子网级的粗粒度方向，安全组管实例级的精细端口
验证双向流量
验证双向流量
sudo tcpdump -ni any 'host 10.10.1.10 and tcp port 3306' -c 20
# 双向都有包但业务异常：问题多半不在 ACL
# 若只有单向包：检查反方向规则是否放行返回流量
sudo tcpdump -ni any 'icmp' -c 10 # 复核是否只是 ICMP 被拦ACL 变更影响整个子网的所有实例，影响面大于安全组，变更窗口与留档更严格。
与安全组的分工
两层控制要分清职责才不会互相打架：网络 ACL 管子网级的粗粒度方向，比如只允许本子网向数据网段发起连接；安全组管实例级的精细端口，比如某台实例只开放 443。流量要两层都通过才放行，所以排查顺序建议先看安全组（变更更频繁），再看 ACL（影响面更大）。ACL 是无状态的，返回流量必须在反方向单独放行，这是配置时最容易漏的一步。