FaiChou

@tool2dx 什么插件导致内存泄露，还记得吗？

@churchmice
@shyrock

破案了：

$ df -T /var
Filesystem Type 1K-blocks Used Available Use% Mounted on
tmpfs tmpfs 1962076 22996 1939080 1% /tmp

分母！+1

@phenixc #27 你说的这种是打洞的原理。但实际上会复杂很多，如果是 v4 ，大部分网络环境都会限制来源 ip, derp 服务器的 ip 和别的 ip 不一样，防火墙也是给过滤掉的。也就是说，中转的数据包如果是一来一回的建立了连接，这种防火墙是准许的。也就是我在 25 楼讲的 ctstate RELATED,ESTABLISHED 行为。

@zbinlin #26 能 ping 通，有 icmp 和 icmpv6 相关的防火墙配置。这是 OpenWrt 默认的。

@FaiChou #24 数据包是这样走的，数据包来到网口 1 后，经过 forward 链，然后第一条是自建的`forwarding_rule`（我也不知道谁建的这条 rule ），这个 rule 表示，如果是从 `pppoe` 开头的网口，那么数据包会 RETURN ，RETURN 代表向下一条规则过滤，也就是走到 ACCEPT 这一条，这一条后面是 `ctstate RELATED,ESTABLISHED`，代表如果是出站过的流量，那么返回的响应是正常接收的。

然后就是下面这些 OpenWrt 自定义的规则了。能够看到数据包也小，数据量都是在 forwarding_rule 上，估计使用 tailscale 连接是被这条链捕获记录。

@zbinlin 我现在更倾向于我这 OpenWrt 的问题，昨天防火墙的 FORWARD 默认是 DROP ，经过开一个 server 测试，确实是这样的。但是 tailscale 能用 v6 直连。但今天再测，就不能用 v6 直连了，而且我现在把 FORWARD 规则改成默认 ACCEPT 也不行。

由于是办公室的网络环境，不太方便 flush 掉所有规则做测试，具体是这样的:


$ ip6tables -L FORWARD -vn
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
257K 161M forwarding_rule all * * ::/0 ::/0 /* !fw3: Custom forwarding rule chain */
226K 153M ACCEPT all * * ::/0 ::/0 ctstate RELATED,ESTABLISHED /* !fw3 */
16675 2716K zone_lan_forward all br-lan * ::/0 ::/0 /* !fw3 */
14322 5367K zone_wan_forward all pppoe-ppp * ::/0 ::/0 /* !fw3 */
0 0 zone_docker_forward all docker0 * ::/0 ::/0 /* !fw3 */
0 0 zone_ipsecserver_forward all ipsec0 * ::/0 ::/0 /* !fw3 */
0 0 reject all * * ::/0 ::/0 /* !fw3 */

# root @ OpenWrt in ~ [20:32:49]
$ iptables -L forwarding_rule -v -n
Chain forwarding_rule (1 references)
pkts bytes target prot opt in out source destination
1314K 1142M RETURN all -- pppoe+ * 0.0.0.0/0 0.0.0.0/0
886K 333M RETURN all -- * pppoe+ 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- ppp+ * 0.0.0.0/0 0.0.0.0/0 ctstate NEW
0 0 ACCEPT all -- * ppp+ 0.0.0.0/0 0.0.0.0/0 ctstate NEW

@lovelylain 对的，不管是 v4 还是 v6 ，防火墙默认是有 "iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT"这样一条的。从内部发出去的包，如果收到响应，默认是接收的。