我在租用的 VPS 上使用 Debian 9。在我的笔记本电脑上，我使用动态 ssh 端口转发（使用 SOCKS 协议）来隧道传输某些应用程序的流量。一切正常，但是当我在服务器（VPS）上加载 iptables 规则时，我的笔记本电脑上使用本地端口转发的任何应用程序都会停止工作。
这是我用来将笔记本电脑（debian 8）的本地端口 8080 转发到我的 VPS 的命令：
ssh -D 8080 -N [email protected]
上述命令开始返回如下错误：
channel 7: open failed: connect failed: Connection timed out
channel 8: open failed: connect failed: Connection timed out
channel 9: open failed: connect failed: Connection timed out
channel 3: open failed: connect failed: Connection timed out
etc...
这是 VPS 上 iptables -L 的输出。有人能看出为什么这些规则会导致这个问题吗？任何想法都非常感谢。
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- google-public-dns-a.google.com anywhere
ACCEPT all -- resolver3.opendns.com anywhere
ACCEPT all -- resolver1.opendns.com anywhere
SYN_FLOOD_LOG_DROP tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN
UDP_FLOOD_LOG_DROP udp -- anywhere anywhere
ICMP_FLOOD_LOG_DROP icmp -- anywhere anywhere
tcp -- anywhere anywhere tcp dpt:ssh state NEW recent: SET name: DEFAULT side: source mask: 255.255.255.255
SSH_LOG_DROP tcp -- anywhere anywhere tcp dpt:ssh state NEW recent: UPDATE seconds: 60 hit_count: 4 name: DEFAULT side: source mask: 255.255.255.255
tcp -- anywhere anywhere tcp dpt:xmpp-client state NEW recent: SET name: DEFAULT side: source mask: 255.255.255.255
XMPP_LOG_DROP tcp -- anywhere anywhere tcp dpt:xmpp-client state NEW recent: UPDATE seconds: 60 hit_count: 8 name: DEFAULT side: source mask: 255.255.255.255
tcp -- anywhere anywhere tcp dpt:http state NEW recent: SET name: DEFAULT side: source mask: 255.255.255.255
HTTP_LOG_DROP tcp -- anywhere anywhere tcp dpt:http state NEW recent: UPDATE seconds: 60 hit_count: 8 name: DEFAULT side: source mask: 255.255.255.255
ACCEPT tcp -- anywhere anywhere tcp dpt:xmpp-client
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT tcp -- localhost anywhere tcp dpt:5582
Chain FORWARD (policy DROP)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain HTTP_LOG_DROP (1 references)
target prot opt source destination
LOG all -- anywhere anywhere LOG level warning prefix "IPTables DROP:HTTPATTACK "
DROP all -- anywhere anywhere
Chain ICMP_FLOOD_LOG_DROP (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere limit: avg 1/sec burst 3
LOG all -- anywhere anywhere LOG level warning prefix "IPTables DROP:ICMPFLOOD "
DROP all -- anywhere anywhere
Chain SSH_LOG_DROP (1 references)
target prot opt source destination
LOG all -- anywhere anywhere LOG level warning prefix "IPTables DROP:SSHATTACK "
DROP all -- anywhere anywhere
Chain SYN_FLOOD_LOG_DROP (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere limit: avg 1/sec burst 3
LOG all -- anywhere anywhere LOG level warning prefix "IPTables DROP:SYNFLOOD "
DROP all -- anywhere anywhere
Chain UDP_FLOOD_LOG_DROP (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere state NEW recent: UPDATE seconds: 1 hit_count: 20 name: DEFAULT side: source mask: 255.255.255.255
LOG all -- anywhere anywhere LOG level warning prefix "IPTables DROP:UDPFLOOD "
DROP all -- anywhere anywhere
Chain XMPP_LOG_DROP (1 references)
target prot opt source destination
LOG all -- anywhere anywhere LOG level warning prefix "IPTables DROP:XMPPATTACK "
DROP all -- anywhere anywhere
谢谢。
答案1
我采纳了 eckes 的建议，并尝试记录 INPUT 策略删除的内容。因此，我在 INPUT 链的最后一条规则中添加了以下规则：
iptables -A INPUT -j LOG --log-prefix "IPTables DROP: wrong drop " --log-level 4
这表明实际上有很多东西被丢弃了，但这可能不应该发生。例如，日志中的这一行：
12 月 12 日 22:45:13 myservername 内核：[41817.875804] IPTables DROP：错误删除 IN=ens18 OUT=MAC=aa:43:9d:07:06:a7:00:1b:21:ad:d0:5d:08:00 SRC=149.56.134.238 DST=30.123.234.6 LEN=113 TOS=0x00 PREC=0x00 TTL=49 ID=471 DF PROTO=TCP SPT=6667 DPT=47054 WINDOW=227 RES=0x00 ACK PSH URGP=0
测试时，我使用笔记本电脑上的 ssh 动态端口转发连接到 IRC 服务器 149.56.134.238 (cherryh.freenode.net)，如前所述。在服务器 (VPS) 上加载 iptables 规则后，我失去了连接。
因此，我再次听取了 eckes 的建议，并尝试通过将此行添加为链的最后一条规则（但在上述调试 LOG 规则之前）来接受 ESTABLISHED、RELATED 数据包。
iptables -A INPUT -m conntrack --cstate ESTABLISHED,RELATED -j ACCEPT
问题解决了。我猜吸取的教训是，解决 iptables 问题的第一步是检查实际丢弃了什么！