问题描述 #

各位大佬好，我最近在给服务器配置iptables安全规则，用白名单思路开放必要端口，但设置完成后发现HTTPS通信出现异常，具体情况如下：

我先清理了filter表的所有规则，设置OUTPUT和FORWARD默认策略为ACCEPT，INPUT默认策略为DROP，接着添加了允许SSH、HTTP、HTTPS以及临时端口的规则，执行的命令如下：

sudo iptables -t filter -F
sudo iptables -P OUTPUT ACCEPT
sudo iptables -P FORWARD ACCEPT

sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 3000: -j ACCEPT

当前INPUT链的规则列表如下：

Chain INPUT (policy DROP)
target     prot opt source               destination         
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:22
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:80
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpts:3000:65535
ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0            tcp dpt:443

测试后发现，SSH和HTTP能正常工作，但HTTPS无法正常建立连接，明明规则里已经开放了443端口，想请教下哪里出了问题？

专家解答 #

嗨，兄弟，我看了你的配置，问题根源很明确——你没允许已建立连接的回包流量！

TCP是双向通信的，客户端发起HTTPS请求时，你的规则允许了入站的SYN包，但服务器发回SYN-ACK包后，客户端的ACK回包目标端口是它自己的随机临时端口，不是你开放的22/80/443，而你的INPUT默认策略是DROP，这个回包就被拦截了，导致三次握手无法完成，连接自然建立失败。

至于SSH和HTTP暂时正常，大概率是你测试时客户端的临时端口刚好落在了你开放的3000-65535范围内，但这个范围开得太大了，完全失去了白名单的安全意义。

给你两个解决方案，首推第一个：

方案一：允许已建立/相关连接流量（最安全灵活）

在所有端口允许规则之前，添加这条规则，让iptables放行所有属于已建立连接的回包，以及和已建立连接相关的流量：

sudo iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

这条规则能覆盖所有正常的双向通信需求，不用再开放大量临时端口，安全性和实用性都拉满。

方案二：调整临时端口规则（不推荐）

如果你非要通过开放端口解决，应该把规则改成匹配出站连接对应的入站回包，而不是直接开放3000到65535的所有端口，但这种方式不如方案一灵活，还会降低安全性，所以更建议用方案一。

另外记得把sudo iptables -A INPUT -p tcp --dport 3000: -j ACCEPT这条规则删掉，开放这么大的端口范围等于白名单形同虚设。

最后配置完后，记得保存iptables规则（不同系统命令不同，比如iptables-save > /etc/iptables/rules.v4或者service iptables save），避免重启后规则丢失。

备注：内容来源于stack exchange，提问作者john_smith