Não há conectividade IPv6 com o contêiner Docker fora do host

4

Eu tenho um contêiner nativo IPv6 executando uma pequena aplicação web na porta 8000.

No host do Docker, posso acessar o serviço da Web usando o IP global, mas obtenho 'conexão recusada' ao conectar-me de outro host. No entanto, o contêiner pode receber um ping do outro host.

O serviço no contêiner funciona

# curl "http://[2a01:4f8:10a:2cc5:0:242:ac11:2]:8000"
I'm b6032b33bc12

No entanto, executando a partir de outro host:

{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

No entanto, o endereço ipv6 é passível de 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

O que eu perdi?

Mais alguns detalhes sobre meu ambiente:

# docker -
Docker version 17.03.1-ce, build c6d412e

O daemon usa os seguintes argumentos para ativar o ipv6:

--experimental=true --ipv6 --fixed-cidr-v6=2a01:4f8:10a:2cc5::2/64

O host tem uma sub-rede roteada ipv6 /64 , que tem um ip alocado para eth0 e a restante sub-rede em 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

O contêiner tem um ipv6 global

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

O roteamento para o ipv6 está em vigor e parece funcionar:

# 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

O host tem conectividade de saída:

# 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

Como o contêiner

# 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

Suspeito que exista um problema com o 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

E o equivalente ao 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
    
por qnm 30.04.2017 / 07:57

1 resposta

2

Olhando toda a sua configuração, não vejo nada de errado nela.

Tudo que eu usei do Hetzner veio com apenas um prefixo de link e nenhum prefixo roteado. Mas eu tentei mtr de uma máquina fora da rede do Hetzner, e a saída parece com 2a01:4f8:10a:2cc5::/64 é realmente um prefixo roteado.

Atribuir um único endereço do seu prefixo roteado ao seu eth0 é um pouco incomum. Mas desde que você o designou como /128 , ainda é uma configuração válida. E se o seu servidor veio com apenas um prefixo roteado e nenhum prefixo de link, então atribuir um /128 dessa maneira é uma configuração sensata.

Como não encontrei nenhum problema em sua configuração, tentei reproduzir o problema da minha máquina e não consegui.

$ curl "http://[2a01:4f8:10a:2cc5:0:242:ac11:2]:8000"
I'm b6032b33bc12

Isso me leva à conclusão de que o problema provavelmente está na máquina em que você executou o comando curl (ou na rede à qual ele está conectado).

Como você não nos disse nada sobre essa máquina, não posso dizer mais especificamente qual é o problema. O que você pode tentar é comparar a saída desses dois comandos:

traceroute 2a01:4f8:10a:2cc5:0:242:ac11:2
traceroute -p 8000 2a01:4f8:10a:2cc5:0:242:ac11:2

Aqui estou usando o pacote traceroute no Ubuntu 16.04. Outras versões traceroute podem precisar de argumentos diferentes.

    
por 30.04.2017 / 19:06