游客st6camefjycdm_个人页

我也遇到了，阿里云这个 IPv4 NAT Connection Tracking 带来的问题非常有意思。虽然我不知道真正的解决办法，但是我有一个歪招。且听我慢慢说明。 配置好 HE 隧道以后，从阿里云里面，可以向外访问任何的 IPv6 网站，其他网站所看到的本机 IP 正是你隧道的客户端地址 2001:aaa:bbb:ccc::2，一切看起来仿佛都很正常。但是，从外面另一台机器上试图 ping6 2001:aaa:bbb:ccc::2，莫名其妙的无法到达。。。此时，请你继续开着你不通的 ping6。然后你从阿里云上通过 IPv6 隧道任意发出去一个请求，请求哪里无所谓，什么协议也无所谓。你发出去请求的一瞬间，你会发现，你上面那个正在运行的 ping6 突然通了，外面其他的人也全都可以正常访问你机器了！此时，关掉所有通过隧道的 IPv6 连接，不管是向里的还是向外的。只需短短 60 秒，你就会发现外面又不能主动连接到你了。 实际上其他 NAT 用户也遇到了相同的问题（1，2，3）。不同于 PPTP 这类 VPN 协议，6in4 隧道协议是无状态的，如果没有流量从中通过的时候，不会建立和保持着一个去往 HE 服务器的 IPv4 连接，此时 NAT 无法感知到这个连接仍然存在，超时后就把这个转换条目从 NAT 表里扔掉了，当 HE 的请求主动发过来的时候就不知道该往哪转发了。 那么简单粗暴的解决方法就是，每过 50 秒往外随便扔一点东西。 比方说，你可以 nohup ping6 -i 50 ip.sb& 每 50 秒发一个 ICMP 包出去。或者你一直经由 IPv6 隧道里面开着一个 TCP 长连接也可以，TCP 协议自然会发一些 Keep alive packets 出去。RFC 5572 看起来有针对这个问题进行优化，但是 HE 可能没支持这个协议。最好的解决办法是，让阿里云在 NAT 设备上把 6in4 设为 Do Not Track。