保持INPUT策略为drop时，使SSH隧道工作的最小nft规则是什么？

我来帮你梳理下问题，以及给出最精简的解决方案：

你当前的规则只放行了eth0接口的所有入站IP流量，但SSH隧道的流量不一定都走eth0——比如本地端口转发时，你连接localhost的转发端口，流量是通过回环接口（lo）传输的，而你的规则里完全没考虑lo，这就导致这部分流量被默认的drop策略拦截了。另外，虽然你开放了eth0的所有入站，但没有匹配连接状态的规则，后续的SSH交互流量（比如隧道内的数据传输）也可能遇到问题（不过这条在你当前的全放行规则下影响不大，但精简规则时必须加上）。

下面是保持INPUT策略为drop的前提下，让SSH隧道正常工作的最小规则集，分场景给出：

通用最小规则（覆盖绝大多数SSH隧道场景） #

table ip filter {
    chain INPUT {
        type filter hook input priority 0; policy drop;
        # 允许回环接口的所有流量——本地端口转发/反向隧道必备
        iifname "lo" accept
        # 允许已建立/相关的入站流量——SSH连接的后续交互全靠这条
        ct state established,related accept
        # 如果你需要对外提供SSH服务（允许远端连你的机器），放开对应端口
        iifname "eth0" tcp dport 22 accept
    }
    chain FORWARD {
        type filter hook forward priority 0; policy accept;
    }
    chain OUTPUT {
        type filter hook output priority 0; policy accept;
    }
}

规则逐条解释 #

• iifname "lo" accept：这条是核心！不管是本地端口转发（比如访问127.0.0.1:8080）还是反向隧道的本地端流量，都是通过回环接口传输的，默认drop策略会直接拦截这部分，必须加上。
• ct state established,related accept：SSH连接建立后，所有后续的交互、隧道内的数据传输都属于已建立/相关的连接状态，这条规则能让这些流量自动通过，不用再单独放行一堆端口。
• iifname "eth0" tcp dport 22 accept：如果你的机器需要作为SSH服务端，允许远端从eth0连接过来，就加上这条（如果改了SSH端口，把22换成你的自定义端口即可）；如果只是你主动发起SSH连接到远端做隧道，这条可以去掉，仅保留前两条就足够。

为什么你原来的规则不行？ #

你原来的规则只开放了eth0的所有入站，但漏掉了回环接口的流量——而SSH隧道的本地交互恰恰依赖lo接口。另外，虽然全开放eth0能让初始SSH连接进来，但没有状态匹配的规则，在更复杂的隧道场景下（比如多层转发）可能会出现流量被拦截的情况，而用established,related规则是更安全且精简的做法。

内容的提问来源于stack exchange，提问作者user3336503