边界与远程：墙、洞与加密通道

专栏： 《计算机网络基础》

对应总览： 第六篇　网络安全

本篇角色： 讲清防火墙/安全组、网络分段、NAT 的安全语义、远程接入与 DDoS 直觉

读完你能： 写出最小入站策略草案；解释「VPN 连上仍要分段」；区分超时、拒绝与策略误伤

导读：墙要守的是「谁能摸到谁」

上一章管的是「谁有资格进入局域网」。进了局域网，或站在公网外侧，下一个问题更冷：

从 A 网段，究竟能不能连到 B 的那个端口？

这和「路上有没有 TLS」不是一回事。数据库听着 3306，证书配得再好看，安全组对 0.0.0.0/0 放行，公网扫描器一样排队来握手。

工程师嘴里的「墙」，今天可能是：

机房出口的硬件防火墙；
云上的安全组 / 网络 ACL；
主机 iptables/nftables/Windows 防火墙；
以及远程办公时那条加密隧道两端的策略。

本篇把它们收成同一意图：收敛暴露面、切开信任区、给远程一个受控入口。DDoS 只谈到「可用性也是边界问题」为止，不展开攻防细节。

一、概念

1.1 防火墙、ACL、安全组：同一句话的不同旋钮

意图都是：

复制代码

允许 / 拒绝：某源 → 某目的:某端口/协议 （有时还带时间、用户、应用识别）

差别在部署位置与状态能力：

形态	常见位置	直觉
网络 ACL	子网边界，常无状态或半状态	粗粒度、两向都要想到
安全组	弹性网卡/实例，多有状态	云上默认工具；规则能绑到「另一组实例」
主机防火墙	OS 内	最后一道，防「同主机旁路」或东西方流量
下一代墙 / UTM	出口或 DC	可能看应用层，成本与误报也上来

排障时先问「策略挂在哪一层」，再问「命中了哪条」。很多人只改安全组，忘了还有 NACL 或主机墙，会打自己。

1.2 默认拒绝，还是默认允许

安全设计偏好：入站默认拒绝，例外显式打开 。

现实里家用路由、部分老园区，出站很宽、入站靠 NAT「偶然安全」。云上一旦给了公网 IP，没有「偶然」，只有规则。

临时放行是事故温床。规则要有：

事由；
申请人；
到期时间；
验证方式（谁测过「收得回来」）。

没有到期日的「临时」，就是永驻后门。

1.3 分段与 DMZ：别把所有服务器丢进同一信任桶

分段不是画一堆 VLAN 炫技，是限制爆炸半径。

复制代码

公网用户 → [边缘/DMZ 类：反代、WAF、堡垒]
                ↓ 仅必要端口
            [应用层]
                ↓ 仅必要端口
            [数据层]

应用被打穿后，如果它能直接扫到全部数据库与域控，分段等于没做。

云上等价物：不同安全组、不同子网、私有链路访问托管库，而不是「一个大 SG 通吃」。

1.4 NAT 的安全语义（承接第四篇）

NAT 常常被误解成「防火墙」。它更准确的说法是：

没有会话、没有端口映射时，外网主动连进来很难------这是副作用，不是完整策略。

一旦你做了端口转发、UPnP 开洞、云上绑了公网 IP 且安全组放行，副作用消失。

排障「外网连不进家里服务」时，先分清：是想依赖 NAT 隐身，还是已经主动打洞却打错。

1.5 远程接入：隧道解决到达，不解决权限过大

第四篇写过封装与 MTU。安全视角补两刀：

认证： 隧道对端是不是你的网关（证书/账号/设备姿态）。
授权： 拨入后能看见整张 10.0.0.0/8，还是只能进跳板与指定应用？

全隧道把上网流量也送回公司，利于审计，伤家宽体验；分流省事，要防「去往办公网段的路由」被污染或泄漏。

无论哪种：加密通道建立成功 ≠ 可以松掉内网分段。

1.6 DDoS 与可用性：边界的另一张考卷

机密性再好，管道被灌满也是事故。分层直觉即可：

靠近用户的清洗/高防、CDN 扛一部分；
源站隐藏，避免攻击者绕过边缘直打原点；
应用侧限流与扩容------单靠机房防火墙硬抗流量型攻击，往往不经济。

细节留给专项；本篇要求你在架构图上标出「被灌时第一道卸力点在哪」。

1.7 出站控制：常被忘掉的半边墙

入站收得很紧、出站完全放开，在云上很常见。结果是：失陷主机可以随意连外部 C2、把数据送去对象存储、或扫内网其它段。

完全精细的出站白名单成本高，可先做几档：

生产应用：默认出网，但阻断到明确危险的管理端口横向；
数据层：原则上不出公网，更新走代理；
办公终端：可按合规要求做 URL/DNS 过滤（产品选型另说）。

「我们只管入站」在共享责任模型里说得通一半------另一半是出事后的爆炸半径。

1.8 堡垒与「Just Enough」

跳板机若变成「一台能 SSH 到所有机器的神器」，只是把暴露面收成了一个更高价值的目标。

更稳的形状：短时凭证、按项目授权、会话可审计、禁止从堡垒直连数据库（应用走应用账号）。云上 Systems Manager / 临时证书一类能力，本质都是减少「长期开着的 22」。

二、场景

2.1 机房 / 园区出口

墙内外策略动辄上百条，真正危险的是：

影子规则（谁也不敢删）；
对象组里混进了过宽网段；
变更只改了一侧方向。

实操建议：任何「允许全世界访问某管理端口」的规则，单独标红，进入每周回顾列表。

2.2 云 VPC：最快也最容易打穿的墙

复制代码

实例公网 IP + 安全组入站 0.0.0.0/0:3306

这种组合在自动化扫描下活不了多久。更隐蔽的版本是：只对 0.0.0.0/0 开了 22，靠「密码够强」赌运气------仍然是错误的暴露面经营。

较好的形状：

数据库：无公网，仅应用安全组可访；
管理：经堡垒 / VPN / SSM 类通道，不直裸公网；
Web：只对 LB 或 WAF 回源网段 开放源站端口。

2.3 出差与居家办公

用户投诉「VPN 连上了但打不开某系统」，安全与网络要一起看：

分流是否没把该网段送进隧道；
隧道内 ACL 是否更严；
DNS 是否还在解析到外网错误地址（分裂视野）；
账号是否被降权或 MFA 异常。

「能 ping 通网关但不能打开 OA」常常是应用发布层或策略，不是加密算法不够。

2.4 业务被扫、被灌

先收暴露面，再谈扩容。源站 IP 若在 DNS 历史、邮件头、证书透明度日志里泄露，边缘再厚也可能被绕。这与下一章「藏源站」直接衔接。

2.5 案例：Terraform 把数据库打到公网

变更意图：给预发 RDS 加一台跳板的访问。

实际 diff：cidr_blocks = ["0.0.0.0/0"]，环境变量指错成生产 workspace。

五分钟后监控未必报警（流量还没来），但暴露面已成立。

防法比追责重要：

PR 模板强制填写「是否含 0.0.0.0/0 / ::/0」；
CI 对安全组规则做静态检查，过宽则失败；
生产 apply 需要额外审批；
定时任务扫描现网过宽规则，结果打进安全频道。

2.6 案例：VPN 全开后的横向

离职员工账号未关，或承包商证书仍有效，拨入后路由指向扁平 10.0.0.0/8。

此时边界墙对外很漂亮，对内等于没分段。

修复：账号切断 + 会话踢掉 + 按应用拆 VPN 配置档 + 内网 ACL 复核。

2.7 案例：只硬化了 IPv6 的兄弟------IPv4

反过来也成立：只盯着 A 记录与 v4 安全组，AAAA 仍指向同一主机且 ::/0 放行。

双栈审计要成对出现在清单里，否则「扫端口的人」会选你没守的那一边。

三、现状

硬件墙没死，但云策略已成日常控件；很多团队一周改安全组的次数超过改物理墙的次数。
远程办公常态化，VPN/零信任接入从应急通道变成通勤路径，账号生命周期必须进离职流程。
IPv6 / 双栈 下只硬化了 v4 的案例反复出现------暴露面审计要双栈一起看。
策略即代码 普及后，PR review 里多看一眼 cidr_blocks = ["0.0.0.0/0"]，比事后救火便宜。
东西向微隔离 从大厂实践渗进中小团队：哪怕只是「数据库 SG 只允许应用 SG」，也比扁平 ACL 强一截。
远程接入与零信任产品 互相替代又互相叠加------有的团队用应用级发布替代整网 VPN，有的两者并存；并存时最怕权限模型两套不一致。

四、原理：策略如何被「走」到

4.1 有状态放行的直觉

安全组常见行为：你允许入站 443，回流的响应包自动关联会话放行。

无状态 ACL 则要自己记得「出站/入站成对」------漏一侧就表现为莫名其妙的单向不通。

排障口诀：

复制代码

超时且无 RST → 更像丢弃（SG/NACL/清洗）
立刻拒绝 → 更像主机墙 / 应用未听 / 显式 reject
单向通 → 先怀疑无状态 ACL 漏了回流

4.2 东西方流量

传统墙擅长南北向（出入数据中心）。

微服务东西方（服务到服务）若只靠大二层畅通，一破全穿。服务网格、微隔离、安全组「仅允许上游 SG」都是在补这门课。

画一张「服务依赖图」再写 SG，比对着端口表拍脑袋少返工。依赖图不存在时，至少保证：数据层不主动连应用层以外的世界。

4.3 VPN 与边界的叠罗汉

复制代码

家宽 NAT → 公网 → VPN 网关 → （内网 ACL）→ 应用

每一跳都可能丢策略。MTU 问题导致「有的网站行有的不行」，第四篇写过；本篇补一句：排障时先确认 策略是否放行 ICMP/分片相关，再和安全同事吵架。

分流场景额外检查：

复制代码

ip route get 10.20.3.8
# 是否经 tun0/wg0/公司虚拟网卡？
# 若走主网卡默认路由，说明分流名单漏了该网段

4.4 安全组「引用另一个组」为什么香

云上允许：应用 SG 入站来源 = LB 的 SG，而不是写死一堆 IP。

实例扩缩容时，规则不用改。

代价是：SG 关系图要文档化，否则三个月后没人敢动。

4.5 连接跟踪打满长什么样

NAT 网关、防火墙、部分云安全组件有会话表上限。表现是：新建连接失败、老连接偶发重置，很像「被攻击」或「应用 bug」。

先看会话数/端口耗尽指标，再决定是扩容还是被扫。盲目在边缘加规则，有时只是把表填得更快。

五、应用：最小入站草案（示例）

以下为示意，不是厂商配置教程。

云上 Web 应用：

对象	入站允许	来源
LB / 边缘	443	互联网或仅 CDN 回源 IP
应用实例	应用端口	仅 LB 所在 SG
数据库	5432/3306	仅应用 SG
堡垒	22 或厂商通道	仅办公出口 IP / VPN 网段

远程办公：

项	建议
认证	MFA；离职当日切断
授权	按应用/网段授权，避免「一拨入看见全部」
设备	能做姿态检查最好；做不到至少禁止未知客户端配置随意导出

把草案写成表格贴进仓库 network-policy.md，比口头「我们很严」有用。

5.1 规则命名与注释约定（建议）

复制代码

allow-443-from-internet-web    # 业务：对外 HTTPS
allow-5432-from-sg-app         # 数据：仅应用
temp-22-from-office-until-2026-08-20  # 临时：事由 JIRA-1234

名字里带到期日与工单号，三个月后的你会感谢现在的你。自动化扫描也可以按 temp- 前缀找逾期项。

5.2 变更检查单（改生产 SG 前）

影响环境：预发 / 生产？
是否含 0.0.0.0/0 或 ::/0？若是，书面理由？
到期时间？谁负责收回？
回滚命令/旧规则快照？
改完后从「应不可达」位置验证？

六、问题定位

现象	可能原因	怎么逼近
连接超时、无 RST	安全组/ACL 丢弃、黑洞路由、上游清洗	从源侧 `tcping`/抓 SYN；看云流量日志是否「被拒绝」计数
立刻 RST / ICMP unreachable	主机墙、应用未听、显式拒绝	本机 `ss`、主机防火墙计数
仅外网不行内网行	公网 IP/NAT/安全组	对比同源不同路径
VPN 后部分网段不行	路由分流、隧道 ACL、DNS	`ip route get`、解析对比
间歇	会话表打满、健康检查抖动、主备策略不一致	看连接跟踪与 LB 事件

云厂商控制台里「网络流量日志 / 策略命中」一旦打开，排障从猜变成读。没日志时，只能用「改规则前后对比」这种笨办法------改之前先快照。

6.1 分层排查顺序（建议固定下来）

复制代码

1. 目的进程是否在听？ss -lntup
2. 主机防火墙是否丢？
3. 云安全组 / NACL 是否丢？（看 reject/deny 计数或 flow log）
4. 路由是否指到正确网卡/隧道？
5. 上游清洗 / 运营商策略？（少见，但大流量时要问）

跳步的代价是：在安全组已经放行的情况下，和安全同事争论三小时，最后发现应用绑死了 127.0.0.1。

6.2 授权自测「应不可达」

从办公网或家庭网（非 VPN）对数据库公网地址（若错误地存在）做连接测试：应失败。

只测自己资产；把结果截图进变更单。成功了就不是「 theoretically 有风险」，而是「已经暴露」。

七、小结

边界回答的是可达性，不是加密强度。
默认拒绝 + 例外到期，是比「买更贵的墙」更便宜的纪律。
分段限制爆炸半径；NAT 不是防火墙替代品。
VPN 提供受控到达，权限与内网分段仍要守。
可用性攻击下，藏源站与边缘卸力属于架构问题。