Meu contêiner de docker não tem internet

Eu tinha tudo funcionando bem, mas agora parou. Eu tentei os seguintes comandos sem sucesso:

docker run -dns 8.8.8.8 base ping google.com

docker run base ping google.com

sysctl -w net.ipv4.ip_forward=1 - no host e no contêiner

Tudo que eu recebo é unknown host google.com. Docker versão 0.7.0

Alguma ideia?

PS ufwdesativado também

A primeira coisa a verificar é executar cat /etc/resolv.confno contêiner do docker . Se ele tiver um servidor DNS inválido, como, por exemplo nameserver 127.0.x.x, o contêiner não conseguirá resolver os nomes de domínio em endereços IP, portanto ping google.comfalhará.

A segunda coisa a verificar é executar cat /etc/resolv.confna máquina host . O Docker basicamente copia o host /etc/resolv.confpara o contêiner toda vez que um contêiner é iniciado. Portanto, se o host /etc/resolv.confestiver errado, o contêiner de dock também estará.

Se você descobriu que o host /etc/resolv.confestá errado, você tem 2 opções:

1. Codifique o servidor DNS em daemon.json. Isso é fácil, mas não ideal, se você espera que o servidor DNS seja alterado.

2. Corrija os hosts /etc/resolv.conf. Isso é um pouco mais complicado, mas é gerado dinamicamente e você não está codificando o servidor DNS.

1. Servidor DNS codificado no docker daemon.json

• Editar /etc/docker/daemon.json

  {
      "dns": ["10.1.2.3", "8.8.8.8"]
  }
  

• Reinicie o daemon do docker para que essas alterações entrem em vigor:
  sudo systemctl restart docker

• Agora, quando você executa / inicia um contêiner, o docker será preenchido /etc/resolv.confcom os valores de daemon.json.

2. Corrija os hosts /etc/resolv.conf

A. Ubuntu 16.04 e versões anteriores

• Para o Ubuntu 16.04 e versões anteriores, /etc/resolv.confera gerado dinamicamente pelo NetworkManager.

• Comente a linha dns=dnsmasq(com a #) em /etc/NetworkManager/NetworkManager.conf

• Reinicie o NetworkManager para gerar novamente /etc/resolv.conf:
  sudo systemctl restart network-manager

• Verifique no host: cat /etc/resolv.conf

B. Ubuntu 18.04 e posterior

• O Ubuntu 18.04 foi alterado para usar systemd-resolvedpara gerar/etc/resolv.conf . Agora, por padrão, ele usa um cache DNS local 127.0.0.53. Isso não funcionará dentro de um contêiner; portanto, o Docker usará como padrão o servidor DNS 8.8.8.8 do Google, que pode ser interrompido por pessoas protegidas por um firewall.

• /etc/resolv.confé na verdade um link simbólico ( ls -l /etc/resolv.conf) que aponta para /run/systemd/resolve/stub-resolv.conf(127.0.0.53) por padrão no Ubuntu 18.04.

• Basta alterar o link simbólico para apontar /run/systemd/resolve/resolv.conf, que lista os servidores DNS reais:
  sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

• Verifique no host: cat /etc/resolv.conf

Agora você deve ter um válido /etc/resolv.confno host para o docker copiar nos contêineres.

Corrigido seguindo este conselho:

[...] você pode tentar redefinir tudo?

pkill docker
iptables -t nat -F
ifconfig docker0 down
brctl delbr docker0
docker -d

Isso forçará o docker a recriar a ponte e reinicializar todas as regras de rede

https://github.com/dotcloud/docker/issues/866#issuecomment-19218300

Parece que a interface foi 'travada' de alguma forma.

Atualização para versões mais recentes do docker:

A resposta acima ainda pode fazer o trabalho para você, mas já faz muito tempo que essa resposta foi postada e o docker está mais polido agora, portanto, tente primeiro primeiro antes de começar a confundir iptables.

sudo service docker restart ou (se você estiver em uma distribuição Linux que não use inicial) sudo systemctl restart docker

A maneira pretendida de reiniciar a janela de encaixe não é fazê-lo manualmente, mas use o servicecomando ou init:

service docker restart

Atualizando esta pergunta com uma resposta para OSX (usando o Docker Machine)

Se você estiver executando o Docker no OSX usando o Docker Machine, o seguinte funcionou para mim:

docker-machine restart

<...wait for it to restart, which takes up to a minute...>

docker-machine env
eval $(docker-machine env)

Então (pelo menos na minha experiência), se você executar ping no google.com em um contêiner, tudo ficará bem.

Não sei o que estou fazendo, mas funcionou para mim:

OTHER_BRIDGE=br-xxxxx # this is the other random docker bridge (`ip addr` to find)    
service docker stop

ip link set dev $OTHER_BRIDGE down
ip link set dev docker0 down
ip link delete $OTHER_BRIDGE type bridge
ip link delete docker0 type bridge
service docker start && service docker stop

iptables -t nat -A POSTROUTING ! -o docker0 -s 172.17.0.0/16 -j MASQUERADE
iptables -t nat -A POSTROUTING ! -o docker0 -s 172.18.0.0/16 -j MASQUERADE

service docker start

Eu estava usando DOCKER_OPTS="--dns 8.8.8.8"e descobri mais tarde e que meu contêiner não tinha acesso direto à Internet, mas poderia acessar minha intranet corporativa. Mudei DOCKER_OPTSpara o seguinte:

DOCKER_OPTS="--dns <internal_corporate_dns_address"

substituindo internal_corporate_dns_addresspelo endereço IP ou FQDN do nosso DNS e reiniciado o docker usando

sudo service docker restart

e depois gerou meu contêiner e verificou se ele tinha acesso à internet.

Fiquei perplexo quando isso aconteceu aleatoriamente para mim em um dos meus contêineres, enquanto os outros estavam bem. O contêiner foi conectado a pelo menos uma rede não interna ; portanto, não havia nada errado com a Composedefinição. Reiniciar o daemon VM / docker não ajudou. Também não era um problema de DNS porque o contêiner não conseguia nem pingum IP externo. O que resolveu para mim foi recriar a (s) rede (s) docker (s). No meu caso, docker-compose down && docker-compose upfuncionou.

Compor

Isso força a recreação de todas as redes de todos os contêineres:

docker-compose down && docker-compose up

Modo enxame

Suponho que você apenas remova e recrie o serviço, que recria as redes do serviço:

docker service rm some-service

docker service create ...

Se as redes do contêiner forem externas

Simplesmente remova e recrie as redes externas desse serviço:

docker network rm some-external-network

docker network create some-external-network

Para mim, era o firewall do host. Eu tive que permitir o DNS no firewall do host. E também teve que reiniciar o docker depois de alterar a configuração do firewall do host.

Nenhum acesso à Internet também pode ser causado pela falta de configurações de proxy . Nesse caso, também --network hostpode não funcionar. O proxy pode ser configurado definindo as variáveis ​​de ambiente http_proxye https_proxy:

docker run -e "http_proxy=YOUR-PROXY" \
           -e "https_proxy=YOUR-PROXY"\
           -e "no_proxy=localhost,127.0.0.1" ... 

Não se esqueça de definir no_proxy também, ou todas as solicitações (incluindo as do localhost) passarão pelo proxy.

Mais informações: Configurações de proxy no Archlinux Wiki.

Para mim, era uma regra de encaminhamento do iptables. Por alguma razão, a regra a seguir, quando associada às regras de iptables do docker, causou a ocorrência de todo o tráfego de saída dos contêineres localhost:8080:

iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080
iptables -t nat -I OUTPUT -p tcp -d 127.0.0.1 --dport 80 -j REDIRECT --to-ports 8080

Eu tive o problema no Ubuntu 18.04. No entanto, o problema estava com o DNS. Eu estava em uma rede corporativa que possui seu próprio servidor DNS e bloqueia outros servidores DNS. Isso serve para bloquear alguns sites (pornografia, torrents, etc.)

Para resolver seu problema

1. encontre seu DNS na máquina host

2. use --dns your_dns como sugerido por @jobin

   docker run --dns your_dns -it --name cowsay --hostname cowsay debian bash

No Windows (8.1), matei a interface do VirtualBox (via taskmgr) e ela resolveu o problema.

Você pode ter iniciado sua janela de encaixe com opções de DNS --dns 172.x.x.x

Eu tive o mesmo erro e removi as opções de /etc/default/docker

As linhas:

# Use DOCKER_OPTS to modify the daemon startup options.
DOCKER_OPTS="--dns 172.x.x.x"

No Ubuntu 19.04, usando o openconnect 8.3 para VPN, tive que ligar novamente o /etc/resolve.conf ao do systemd (ao contrário de answerby wisbucky)

sudo ln -sf /etc/resolv.conf /run/systemd/resolve/resolv.conf

Etapas para depurar

1. Conectar-se à VPN da empresa
2. Procure as configurações de VPN corretas em /etc/resolv.conf ou /run/systemd/resolve/resolv.conf
3. Qualquer que tenha as configurações DNS corretas, vincularemos isso ao outro arquivo (Dica: coloque um com as configurações corretas à esquerda da atribuição)

Versão do Docker: versão 19.03.0-rc2 do Docker, compilação f97efcc

Se você estiver no OSX, pode ser necessário reiniciar a máquina após instalar o Docker. Isso tem sido um problema às vezes.

Originalmente, meu contêiner de docker conseguiu acessar a Internet externa (este é um serviço / contêiner de docker em execução no Amazon EC2).

Como meu aplicativo é uma API, acompanhei a criação do meu contêiner (ele conseguiu puxar todos os pacotes necessários) atualizando minhas tabelas de IP para rotear todo o tráfego da porta 80 para a porta em que minha API (em execução no docker) estava ouvindo.

Depois, quando tentei reconstruir o contêiner, ele falhou. Após muita luta, descobri que minha etapa anterior (definindo a regra de encaminhamento de porta IPTable) atrapalhava o recurso de rede externa do docker.

Solução: Interrompa o serviço IPTable:

sudo service iptables stop

Reinicie o Docker Daemon:

sudo service docker restart

Em seguida, tente reconstruir seu contêiner. Espero que isto ajude.

Acompanhamento

Eu negligenciei completamente que não precisava mexer nas tabelas IP para encaminhar o tráfego de entrada para 80 para a porta na qual a API em execução no docker estava em execução. Em vez disso, apenas aliei a porta 80 à porta em que a API no docker estava sendo executada:

docker run -d -p 80:<api_port> <image>:<tag> <command to start api>

Basta adicionar isso aqui caso alguém encontre esse problema em um contêiner de caixa virtual executando o docker. Reconfigurei a rede de caixa virtual como ponte em vez de nat, e o problema desapareceu.

para mim, meu problema foi devido ao iptables-services não estar instalado, isso funcionou para mim (CentOS):

sudo yum install iptables-services
sudo service docker restart

No centos 8, meu problema era que eu não instalei nem iniciei o iptables antes de iniciar o serviço docker. Verifique se o serviço iptables está em funcionamento antes de iniciar o serviço docker.

Eu também encontrei esse problema ao tentar configurar um projeto usando o Docker-Compose no Ubuntu.

O Docker não tinha acesso à Internet, quando tentei fazer ping em qualquer endereço IP ou procurar alguma URL - ela falhou o tempo todo.

Tentei todas as soluções possíveis com a resolução DNS descrita acima sem sucesso.

Passei o dia inteiro tentando descobrir o que diabos estava acontecendo e finalmente descobri que a causa de todo o problema era o antivírus, em particular o firewall, que por algum motivo impediu o Docker de obter o endereço IP e a porta.

Quando eu desativei - tudo funcionou bem.

Portanto, se você possui um antivírus instalado e nada ajuda a solucionar o problema - o problema pode ser o firewall do antivírus.

Eu tive um problema semelhante nos últimos dias. Para mim, a causa foi uma combinação de systemd, docker e meu provedor de hospedagem. Estou executando o CentOS atualizado (7.7.1908).

Meu provedor de hospedagem gera automaticamente um arquivo de configuração para systemd-networkd. Começando com systemd 219, que é a versão atual do CentOS 7, systemd-networkd assumiu o controle dos parâmetros sysctl relacionados à rede. O Docker parece incompatível com esta versão e redefinirá os sinalizadores de encaminhamento de IP toda vez que um contêiner for iniciado.

Minha solução foi adicionar IPForward=truea [Network]seção-do meu arquivo de configuração gerado pelo provedor. Esse arquivo pode estar em vários lugares, provavelmente em /etc/systemd/network.

O processo também é descrito nos documentos oficiais da janela de encaixe: https://docs.docker.com/v17.09/engine/installation/linux/linux-postinstall/#ip-forwarding-problems

para mim, usando o centos 7.4, não era questão das regras /etc/resolve.conf, iptables, iptables nat nem o próprio docker. O problema é que o host está ausente do pacote bridge-utils, que o docker requer para construir a ponte usando o comando brctl. yum instale -y bridge-utils e reinicie o docker, resolva o problema.