📚 课程目录第3章防火墙与安全组

防火墙与安全组：远程控制的第一道防线

远程控制连不上，十次里有七八次是防火墙在「作祟」。我见过太多人花几个小时排查应用配置，最后发现只是 Windows 防火墙弹了个窗没点允许。说白了，防火墙就是你家门口的保安——他要是把门锁了，你钥匙再多也进不去。

这一章，咱们就把 Windows 防火墙、Linux 的 iptables/firewalld，还有云平台安全组，一个一个说清楚。嗯，都是实战里天天要打交道的玩意儿。

Windows 防火墙：别让它悄悄拦住你

Windows 防火墙其实没那么复杂。你打开控制面板，找到「Windows Defender 防火墙」，核心就两个东西：入站规则和出站规则。

远程控制走的是入站——别人连你的机器，数据从外面进来。所以你要确保远程桌面（3389）、SSH（22）或者你用的第三方远控端口，在入站规则里是「允许」状态。

快速检查方法：

打开「高级安全 Windows Defender 防火墙」，在「入站规则」里找「远程桌面」。如果状态是「已禁用」，右键启用就行。我习惯直接在这里搜「3389」，一眼就能看到所有相关规则。

有一次我帮客户排查，他死活连不上服务器。我远程过去一看，好家伙，Windows 防火墙里同时存在两条规则——一条允许 3389，一条阻止 3389。系统默认以「阻止」为准。删掉那条多余的，秒连。

注意：

Windows 防火墙规则有优先级：阻止 > 允许。如果你同时配了两条冲突的规则，阻止的那条会生效。别问我是怎么知道的……

常用排查命令

# 查看当前防火墙状态
netsh advfirewall show allprofiles

# 查看所有入站规则（按端口筛选）
netsh advfirewall firewall show rule name=all dir=in | findstr "3389"

# 临时关闭防火墙（仅用于测试，别在生产环境这么干）
netsh advfirewall set allprofiles state off

Linux iptables 与 firewalld：两条路，一个目的

Linux 下的防火墙，说白了就是两套工具：老牌的 iptables 和新派的 firewalld。底层其实都是 netfilter，但操作方式完全不同。

我个人习惯：CentOS 7 以下用 iptables，7 及以上用 firewalld。Ubuntu 的话，现在默认也是 ufw，但底层还是 iptables。

iptables：规则链的哲学

iptables 的规则是顺序匹配的。数据包进来，从上到下一条一条比对，匹配了就执行动作（ACCEPT/DROP/REJECT），后面的规则就不看了。

你想想看，如果你把「允许 22 端口」写在「拒绝所有」的后面，那允许规则永远没机会执行。我见过有人把规则顺序搞反，折腾了一下午没找到原因。

# 查看当前规则（带行号）
iptables -L -n --line-numbers

# 允许 SSH（22端口）入站
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# 允许远程桌面（3389端口）入站
iptables -A INPUT -p tcp --dport 3389 -j ACCEPT

# 保存规则（CentOS 6）
service iptables save

# 保存规则（CentOS 7 使用 iptables 服务）
iptables-save > /etc/sysconfig/iptables

核心要点：

iptables 有 5 张表（filter/nat/mangle/raw/security），但远程控制排查只用 filter 表。filter 表有 3 条链：INPUT（入站）、OUTPUT（出站）、FORWARD（转发）。我们关心的是 INPUT 链。

firewalld：区域化管理

firewalld 比 iptables 更友好。它引入了「区域（zone）」的概念。每个网络接口可以绑定一个区域，不同区域有不同的信任级别。

区域	信任级别	默认行为	适用场景
trusted	最高	接受所有连接	内网管理网段
public	低	仅接受 SSH 等少数服务	公网接口
internal	中	接受常见内网服务	公司内部网络
drop	最低	丢弃所有入站连接	高危环境

我记得有一次，客户说服务器防火墙关了还是连不上。我上去一看，firewalld 确实没运行，但 iptables 规则还在。因为 firewalld 停止时不会自动清空 iptables 规则。嗯，这个坑踩过的人不少。

# 查看默认区域
firewall-cmd --get-default-zone

# 查看当前区域配置
firewall-cmd --list-all

# 开放远程桌面端口（3389）
firewall-cmd --permanent --add-port=3389/tcp
firewall-cmd --reload

# 开放 SSH 服务（使用服务名更方便）
firewall-cmd --permanent --add-service=ssh
firewall-cmd --reload

# 临时放行（重启后失效）
firewall-cmd --add-port=3389/tcp

我的习惯：

用 firewalld 时，我永远先执行 firewall-cmd --list-all 看一眼当前配置。很多时候问题出在「你以为放行了，其实没有」。另外，--permanent 参数一定要加，不然重启就没了。

云平台安全组：虚拟世界的防火墙

到了云上，事情又不一样了。云平台的安全组，本质上是一个有状态的状态防火墙。你配了入方向允许 3389，出方向它会自动允许回包流量。

但这里有个容易搞混的地方：安全组是作用于弹性网卡的，不是直接作用于云服务器。你给服务器绑了两个安全组，规则是「并集」——只要任何一个安全组允许，流量就能通过。

常见误区：

很多人配了安全组允许 3389，但忘了服务器内部还有 Windows 防火墙。云安全组放行了，Windows 防火墙拦住了，还是连不上。我建议你排查时，先临时关掉系统防火墙测试，确认是哪个环节的问题。

三大云平台安全组对比

特性	阿里云	腾讯云	AWS
默认规则	入方向全拒绝	入方向全拒绝	入方向全拒绝
出方向默认	全允许	全允许	全允许
规则优先级	从上到下，匹配即停	从上到下，匹配即停	所有规则同时评估
支持 CIDR	是	是	是
支持安全组引用	是	是	是

我个人习惯在云平台上把安全组规则写得尽量精确。比如远程控制，我只允许公司出口 IP 访问，而不是 0.0.0.0/0。你想想看，把 3389 暴露在公网上，等于给全世界的黑客留了扇门。

  安全组排查三步法：
  确认服务器绑定了正确的安全组
确认安全组入方向有允许目标端口的规则
确认来源 IP 范围覆盖了你的客户端 IP

综合排查流程：从外到内，层层剥开

远程控制连不上，我一般按这个顺序查：

先查云安全组——在云控制台看一眼入方向规则，最快
再查系统防火墙——Windows 防火墙或 Linux 的 firewalld/iptables
最后查服务本身——远程桌面服务是否启动、SSHD 是否在监听

为什么这个顺序？因为云安全组在最外层，它拦住了你连系统都进不去。系统防火墙在第二层。服务本身在最里面。从外到内排查，效率最高。

我曾经遇到一个案例：客户说所有防火墙都关了，还是连不上。我让他执行 netstat -an | findstr 3389，结果发现远程桌面服务根本没监听。折腾了半天防火墙，结果是服务挂了。嗯，所以别只盯着防火墙看。

终极测试命令：

在客户端执行 telnet 服务器IP 3389 或 nc -vz 服务器IP 3389。如果端口通，说明防火墙层面没问题。如果不通，再一层一层往上查。

防火墙和安全组，说白了就是规则游戏。你理解了规则的本质——谁允许、谁拒绝、顺序如何——剩下的就是熟练度的问题了。多配几次，自然就熟了。