Início / unix / Perguntas / 705600
Accepted
Maestro
Asked: 2022-06-10 11:16:00 +0800 CST

Alcance a porta do host do contêiner quando o proxy userland estiver desabilitado

  • 772

Eu tenho um contêiner em uma rede em ponte. Ele pode alcançar o host sem problemas e conectar-se a todas as portas do host, EXCETO para portas que foram publicadas por outros contêineres.

Eu tenho o proxy userland desabilitado, então acho que pode ter algo a ver com a forma como o docker configura as regras do iptable.

Existe uma maneira simples de permitir que o contêiner alcance as portas publicadas por outros contêineres (executando em diferentes redes em ponte)?

Gostaria de evitar colocar os dois contêineres na mesma rede ou alternar para a rede de host.

docker

1 respostas

  1. Best Answer

    Não consigo reproduzir seu problema.

    Eu tenho duas redes em ponte do Docker definidas:

    eecf335e7600   net1                   bridge    local
5c7ca74637b0   net2                   bridge    local

    Eu inicio o container c1na rede net1, publicando a porta do container para a porta 8080do host 8081:

    $ docker run -d --rm --net net1 -p 8081:8080 --name c1 \
  --add-host host.docker.local:host-gateway  alpinelinux/darkhttpd

    Eu inicio o container c2na rede net2, publicando a porta do container para a porta 8080do host 8082:

    $ docker run -d --rm --net net2 -p 8082:8080 --name c2 \
  --add-host host.docker.local:host-gateway  alpinelinux/darkhttpd

    Agora de dentro do container c1eu posso acessar o web service no container c2acessando host port 8082:

    $ docker exec c1 wget -O- http://host.docker.local:8082
Connecting to host.docker.local:8082 (172.17.0.1:8082)
writing to stdout
-                    100% |********************************|   191  0:00:00 ETA
written to stdout
<html>
<head>
...

    E do container c2eu posso acessar o web service no container c1acessando host port 8081:

    $ docker exec c2 wget -O- http://host.docker.local:8081
Connecting to host.docker.local:8081 (172.17.0.1:8081)
writing to stdout
-                    100% |********************************|   191  0:00:00 ETA
written to stdout
<html>
<head>
...

    Tudo parece funcionar como anunciado. Se você obtiver resultados diferentes repetindo o mesmo conjunto de etapas, a primeira coisa que eu verificaria é ver se você tem regras de firewall em seu host que podem estar interferindo no tráfego.

    Atualizar

    Como esperado, o comportamento é o mesmo se eu apenas escolher um endereço de host em vez de usar a --add-hostopção. Por exemplo, se eu tiver:

    $ ip -o addr |grep -o '.*inet [^ ]*'
1: lo    inet 127.0.0.1/8
2: eth0    inet 192.168.123.106/24
4: docker_gwbridge    inet 172.23.0.1/16
8: br-70f125dc5b7d    inet 192.168.208.1/20
15: br-a87cc1462629    inet 172.29.0.1/16
18: docker0    inet 172.17.0.1/16
35: br-eecf335e7600    inet 172.18.0.1/16
36: br-5c7ca74637b0    inet 172.19.0.1/16

    Então tudo isso funciona:

    $ docker exec c2 wget -O- 192.168.123.106:8081 | head -3
Connecting to 192.168.123.106:8081 (192.168.123.106:8081)
writing to stdout
-                    100% |********************************|   191  0:00:00 ETA
written to stdout
<html>
<head>
 <title>/</title>
$ docker exec c2 wget -O- 172.29.0.1:8081 | head -3
Connecting to 172.29.0.1:8081 (172.29.0.1:8081)
writing to stdout
-                    100% |********************************|   191  0:00:00 ETA
written to stdout
<html>
<head>
 <title>/</title>
$ docker exec c2 wget -O- 172.18.0.1:8081 | head -3
Connecting to 172.18.0.1:8081 (172.18.0.1:8081)
writing to stdout
-                    100% |********************************|   191  0:00:00 ETA
written to stdout
<html>
<head>
 <title>/</title>

    etc.

    Eu não mencionei isso na pergunta, porque eu tinha certeza que já tinha esse problema antes de desativá-lo ...

    Essa é uma mudança de configuração bastante substancial em relação ao padrão :).

    Se eu desabilitar o proxy userland, tudo para de funcionar.

    Este artigo pode ser interessante:

    Na seção anterior, identificamos dois cenários em que o Docker não pode usar as regras de NAT do iptables para mapear uma porta publicada para um serviço de contêiner:

    • Quando um contêiner conectado a outra rede Docker tenta acessar o serviço (o Docker está bloqueando a comunicação direta entre as redes Docker);
    • Quando um processo local tenta acessar o serviço por meio da interface de loopback.

    Em ambos os casos, o Docker usa um proxy TCP ou UDP userland (processo Linux). Você pode identificar facilmente o proxy com o comando netstat depois de iniciar um contêiner com uma porta publicada (mais uma vez usaremos nosso aplicativo Flask padrão):

    • 1

relate perguntas