我有一个IPv6本地容器在端口8000上运行一个小的webapp。
在Docker主机上，我可以使用全局IP访问webservice，但是从另一个主机连接时却得到“连接被拒绝”。 但是，容器可以从其他主机ping通。
容器中的服务工作
# curl "http://[2a01:4f8:10a:2cc5:0:242:ac11:2]:8000" I'm b6032b33bc12 但是，从另一台主机运行：
{2.1.5p273} curl "http://[2a01:4f8:10a:2cc5:0:242:ac11:2]:8000" curl: (7) Failed to connect to 2a01:4f8:10a:2cc5:0:242:ac11:2 port 8000: Connection refused
但是，ipv6地址是可以ping通的：
{2.1.5p273} ping6 2a01:4f8:10a:2cc5:0:242:ac11:2 PING 2a01:4f8:10a:2cc5:0:242:ac11:2(2a01:4f8:10a:2cc5:0:242:ac11:2) 56 data bytes 64 bytes from 2a01:4f8:10a:2cc5:0:242:ac11:2: icmp_seq=1 ttl=60 time=0.385 ms 64 bytes from 2a01:4f8:10a:2cc5:0:242:ac11:2: icmp_seq=2 ttl=60 time=0.452 ms
我错过了什么？
关于我的环境的更多细节：
# docker - Docker version 17.03.1-ce, build c6d412e
守护进程使用以下参数来启用ipv6：
--experimental=true --ipv6 --fixed-cidr-v6=2a01:4f8:10a:2cc5::2/64
主机有一个路由的ipv6 /64子网，它有一个ip分配给eth0 ，其余的子网在docker0 。
# ifconfig docker0 Link encap:Ethernet HWaddr 02:42:c8:f8:5c:7b inet addr:172.17.0.1 Bcast:0.0.0.0 Mask:255.255.0.0 inet6 addr: fe80::1/64 Scope:Link inet6 addr: fe80::42:c8ff:fef8:5c7b/64 Scope:Link inet6 addr: 2a01:4f8:10a:2cc5::1/64 Scope:Global UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:129 errors:0 dropped:0 overruns:0 frame:0 TX packets:121 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:9536 (9.3 KiB) TX bytes:11130 (10.8 KiB) eth0 Link encap:Ethernet HWaddr 90:1b:0e:c4:3d:a1 inet addr:88.99.148.135 Bcast:88.99.148.191 Mask:255.255.255.192 inet6 addr: fe80::921b:eff:fec4:3da1/64 Scope:Link inet6 addr: 2a01:4f8:10a:2cc5::2/128 Scope:Global UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:107917 errors:0 dropped:0 overruns:0 frame:0 TX packets:25223 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:143498170 (136.8 MiB) TX bytes:2953043 (2.8 MiB) Interrupt:16 Memory:f7000000-f7020000
容器有一个全局ipv6
docker exec b6032b33bc12 ifconfig eth0 eth0 Link encap:Ethernet HWaddr 02:42:ac:11:00:02 inet addr:172.17.0.2 Bcast:0.0.0.0 Mask:255.255.0.0 inet6 addr: fe80::42:acff:fe11:2/64 Scope:Link inet6 addr: 2a01:4f8:10a:2cc5:0:242:ac11:2/64 Scope:Global
ipv6的路由已经到位，并且似乎正常工作：
# ip -6 route 2a01:4f8:10a:2cc5::2 dev eth0 proto kernel metric 256 2a01:4f8:10a:2cc5::/64 dev docker0 proto kernel metric 256 2a01:4f8:10a:2cc5::/64 dev docker0 metric 1024 fe80::/64 dev eth0 proto kernel metric 256 fe80::/64 dev docker0 proto kernel metric 256 fe80::/64 dev veth0fbfa39 proto kernel metric 256 default via fe80::1 dev eth0 metric 1024
主机具有出站连接：
# ping6 google.com PING google.com(fra16s20-in-x0e.1e100.net) 56 data bytes 64 bytes from fra16s20-in-x0e.1e100.net: icmp_seq=1 ttl=56 time=5.08 ms
容器也一样
# docker exec b6032b33bc12 ping6 google.com PING google.com(fra16s20-in-x0e.1e100.net) 56 data bytes 64 bytes from fra16s20-in-x0e.1e100.net: icmp_seq=1 ttl=55 time=5.00 ms 64 bytes from fra16s20-in-x0e.1e100.net: icmp_seq=2 ttl=55 time=5.00 ms
我怀疑有一个iptables的问题：
# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy DROP) target prot opt source destination DOCKER-ISOLATION all -- anywhere anywhere DOCKER all -- anywhere anywhere ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED ACCEPT all -- anywhere anywhere ACCEPT all -- anywhere anywhere Chain OUTPUT (policy ACCEPT) target prot opt source destination Chain DOCKER (1 references) target prot opt source destination ACCEPT tcp -- anywhere 172.17.0.2 tcp dpt:8000 Chain DOCKER-ISOLATION (1 references) target prot opt source destination RETURN all -- anywhere anywhere
和ipv6相当：
# ip6tables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination
看看你的整个configuration，我没有看到任何错误。
我从Hetzner用过的所有东西都只有一个链接前缀，没有路由前缀。 但是我从Hetzner的networking之外的机器上尝试了mtr ，输出看起来像2a01:4f8:10a:2cc5::/64确实是一个路由前缀。
从你的eth0路由前缀中分配一个地址有点不同寻常。 但是，因为您确实将其分配为一个仍然是有效configuration的/128 。 如果你的服务器只有一个路由前缀，没有链接前缀，那么以这种方式分配一个/128是一个明智的configuration。
由于我在configuration中找不到任何问题，我反而试图从我的机器上重现问题，而我却不能。
$ curl "http://[2a01:4f8:10a:2cc5:0:242:ac11:2]:8000" I'm b6032b33bc12
这使我得出的结论是，问题可能出在您运行curl命令的机器上（或者在它所连接的networking上）。
既然你没有告诉我们关于这台机器的任何事情，我不能更具体地说出问题所在。 你可以尝试的是比较这两个命令的输出：
traceroute 2a01:4f8:10a:2cc5:0:242:ac11:2 traceroute -p 8000 2a01:4f8:10a:2cc5:0:242:ac11:2
这里我使用Ubuntu 16.04上的traceroute软件包。 其他的traceroute版本可能需要不同的参数。