Debian、第 6 条隧道和连接问题

Question

长话短说，我在使用第 6 条隧道的 IPv6 与我的 ISP、Charter Business 之间遇到了问题。他们提供了我认为已正确设置的第 6 条隧道，但服务器不会回复每个 IPv6 请求。当服务器的网络接口空闲且无流量约 10 分钟时，IPv6 将停止接受入站连接。要重新允许它，我必须进入服务器，并使其进行出站 IPv6 连接（通常为 a ping）以启动它。奇怪的是，如果我iptraf在它不工作时运行，它仍然显示一个入站 IPv6 数据包......服务器只是没有回复，我不知道为什么。此外，如果我尝试从大约 1 英里外的同一个 ISP 上的房子通过 IPv6 访问我的服务器，它永远无法连接。它总是超时，但再次iptraf显示 IPv6 入站数据包。同样，它只是不回复。为了测试我的服务器是否可以通过 IPv6 访问，我总是必须使用我的 vzw 4g 电话（他们使用 IPv6）或 ipv6proxy dot net。

这是我的 ISP 在隧道服务器上提供的所有配置信息：

6rd Prefix = 2602:100::/32
Border Relay Address = 68.114.165.1
6rd prefix length = 32
IPv4 mask length = 0

这是我/etc/network/interfaces的 IPv6（使用 x 来阻止真实地址）

auto charterv6 
iface charterv6 inet6 v4tunnel
        address 2602:100:189f:xxxx::1
        netmask 32
        ttl 64
        gateway ::68.114.165.1
        endpoint 68.114.165.1
        local 24.159.218.xxx
        up ip link set mtu 1280 dev charterv6

这是我的iptables配置

filter
:INPUT DROP [0:0]
:fail2ban-ssh – [0:0]
:OUTPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:hold – [0:0]
-A INPUT -p tcp -m tcp —dport 22 -j fail2ban-ssh
-A INPUT -m state —state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m multiport -j ACCEPT —dports 80,443,25,465,110,995,143,993,587,465,22
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp —dport 10000 -j ACCEPT
-A INPUT -p tcp -m tcp —dport 5900:5910 -j ACCEPT
-A fail2ban-ssh -j RETURN
-A INPUT -p icmp -j ACCEPT
COMMIT

最后是我的ip6tables防火墙配置

filter
:INPUT DROP [1653:339023]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [60141:13757903]
:hold – [0:0]
-A INPUT -m state —state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m multiport —dports 80,443,25,465,110,995,143,993,587,465,22 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp —dport 10000 -j ACCEPT
-A INPUT -p tcp -m tcp —dport 5900:5910 -j ACCEPT
-A INPUT -p ipv6-icmp -j ACCEPT
COMMIT

所以总结：

1. iptraf 总是显示 IPv6 流量，所以它总是进入服务器

2. 服务器在没有流量一段时间（10 分钟）后停止回复 IPv6，直到建立出站连接，然后重复该过程。

3. 服务器永远无法通过同一 ISP 访问（但iptraf仍显示 IPv6 请求）

注意：当我尝试从城镇的同一 ISP 访问它时，即使有iptables并ip6tables允许所有入站流量，这就是iptraf显示的内容。

IPv6 (92 bytes) from 97.92.18.xxx to 24.159.218.xxx on eth0
ICMP dest unrch (port) (120 bytes) from 24.159.218.xxx to 97.92.18.xxx on eth0

奇怪的是，即使在主机文件中将 IPv6 地址设置为服务器域名，它也会这样做。使用iptables上述配置正常设置后，它只会说：

IPv6 (100 bytes) from 97.92.18.xxx to 24.159.218.xxx on eth0

另外，我注意到的另一件事。当我能够访问我的服务器时，所有 IPv6 请求都显示了这一点

IPv6 (100 bytes) from 68.114.165.1 to 24.159.218.xxx on eth0

这意味着他们正在通过第 6 次中继，但是当同一个 ISP 请求显示来自诚实的源 IP 时，这让我认为路由可能与此有关。

我真的坚持这一点，任何帮助将不胜感激。

编辑：不知道这是否有帮助，但这是我的路线。

root@XXXXXXX:~# route -A inet6
Kernel IPv6 routing table
Destination                    Next Hop                   Flag Met Ref Use If
::68.114.165.1/128             ::                         U    1024 0     1 charterv6
2602:100::/32                  ::                         Un   256 0     0 charterv6
fe80::/64                      ::                         Un   256 0     0 charterv6
fe80::/64                      ::                         U    256 0     0 eth1
fe80::/64                      ::                         U    256 0     0 eth2
::/0                           ::68.114.165.1             UG   1024 0    30 charterv6
::/0                           ::                         !n   -1  1    32 lo
::1/128                        ::                         Un   0   3    47 lo
2602:100:189f:xxxx::1/128      ::                         Un   0   1    50 lo
fe80::189f:xxxx/128            ::                         Un   0   1     0 lo
fe80::21b:21ff:fe98:456a/128   ::                         Un   0   1     0 lo
fe80::21b:21ff:feab:bd3c/128   ::                         Un   0   1     0 lo
ff00::/8                       ::                         U    256 0     0 charterv6
ff00::/8                       ::                         U    256 0     0 eth1
ff00::/8                       ::                         U    256 0     0 eth2
::/0                           ::                         !n   -1  1    32 lo

Answer 1

您对 ipv4 使用状态过滤，但我没有看到任何规则允许入站封装的第 6 路流量，也许这就是问题所在？

如果我没记错的话，6rd 也使用协议号 41？

iptables -I INPUT 3 --protocol 41 -s 68.114.165.1 -j ACCEPT

编辑：如果您想接收来自其他第六个客户的流量，您还需要接受来自 ISP 的流量。