Mi contenedor Docker no tiene internet

Lo tenía funcionando bien, pero ahora se detuvo. Intenté los siguientes comandos sin resultado:

docker run -dns 8.8.8.8 base ping google.com

docker run base ping google.com

sysctl -w net.ipv4.ip_forward=1 - tanto en el host como en el contenedor

Todo lo que tengo es unknown host google.com. Docker versión 0.7.0

¿Algunas ideas?

PS ufwdeshabilitado también

Lo primero que debe verificar es ejecutar cat /etc/resolv.confen el contenedor acoplable . Si tiene un servidor DNS no válido, como nameserver 127.0.x.x, entonces el contenedor no podrá resolver los nombres de dominio en direcciones IP, por ping google.comlo que fallará.

La segunda cosa a verificar se ejecuta cat /etc/resolv.confen la máquina host . Docker básicamente copia los hosts /etc/resolv.confal contenedor cada vez que se inicia un contenedor. Entonces, si el host /etc/resolv.confestá equivocado, también lo hará el contenedor docker.

Si descubrió que el host /etc/resolv.confestá equivocado, entonces tiene 2 opciones:

1. Codifique el servidor DNS en daemon.json. Esto es fácil, pero no es ideal si espera que cambie el servidor DNS.

2. Arreglar los anfitriones /etc/resolv.conf. Esto es un poco más complicado, pero se genera dinámicamente y no está codificando el servidor DNS.

1. Hardcode servidor DNS en docker daemon.json

• Editar /etc/docker/daemon.json

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

• Reinicie el Docker Daemon para que esos cambios surtan efecto:
  sudo systemctl restart docker

• Ahora, cuando ejecuta / inicia un contenedor, Docker se completará /etc/resolv.confcon los valores de daemon.json.

2. Arreglar los hosts /etc/resolv.conf

A. Ubuntu 16.04 y anterior

• Para Ubuntu 16.04 y versiones anteriores, /etc/resolv.conffue generado dinámicamente por NetworkManager.

• Comente la línea dns=dnsmasq(con a #) en /etc/NetworkManager/NetworkManager.conf

• Reinicie el NetworkManager para regenerar /etc/resolv.conf:
  sudo systemctl restart network-manager

• Verificar en el host: cat /etc/resolv.conf

B. Ubuntu 18.04 y posterior

• Ubuntu 18.04 cambió para usar systemd-resolvedpara generar/etc/resolv.conf . Ahora, por defecto, utiliza un caché de DNS local 127.0.0.53. Eso no funcionará dentro de un contenedor, por lo que Docker usará de forma predeterminada el servidor DNS 8.8.8.8 de Google, lo que puede dañar a las personas que se encuentran detrás de un firewall.

• /etc/resolv.confen realidad es un enlace simbólico ( ls -l /etc/resolv.conf) que apunta a /run/systemd/resolve/stub-resolv.conf(127.0.0.53) de forma predeterminada en Ubuntu 18.04.

• Simplemente cambie el enlace simbólico al que apunta /run/systemd/resolve/resolv.conf, que enumera los servidores DNS reales:
  sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

• Verificar en el host: cat /etc/resolv.conf

Ahora debería tener un válido /etc/resolv.confen el host para que Docker lo copie en los contenedores.

Solucionado siguiendo este consejo:

[...] ¿puedes intentar restablecer todo?

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

Obligará a Docker a recrear el puente y reiniciar todas las reglas de red.

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

Parece que la interfaz fue 'colgada' de alguna manera.

Actualización para versiones más recientes de docker:

La respuesta anterior aún puede hacer el trabajo por usted, pero ha pasado bastante tiempo desde que se publicó esta respuesta y la ventana acoplable está más pulida ahora, así que asegúrese de probar esto primero antes de comenzar a destrozar iptablesy todo.

sudo service docker restart o (si está en una distribución de Linux que no usa el sistema de arranque) sudo systemctl restart docker

La forma prevista de reiniciar Docker no es hacerlo manualmente, sino utilizar el servicecomando o init:

service docker restart

Actualización de esta pregunta con una respuesta para OSX (usando Docker Machine)

Si está ejecutando Docker en OSX con Docker Machine, lo siguiente funcionó para mí:

docker-machine restart

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

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

Entonces (al menos en mi experiencia), si hace ping a google.com desde un contenedor, todo estará bien.

No sé lo que estoy haciendo, pero eso funcionó para mí:

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

Estaba usando DOCKER_OPTS="--dns 8.8.8.8"y luego descubrí que mi contenedor no tenía acceso directo a Internet, pero podía acceder a mi intranet corporativa. Cambié DOCKER_OPTSa lo siguiente:

DOCKER_OPTS="--dns <internal_corporate_dns_address"

reemplazando internal_corporate_dns_addresscon la dirección IP o FQDN de nuestro DNS y reiniciando Docker usando

sudo service docker restart

y luego engendré mi contenedor y verifiqué que tenía acceso a internet.

Estaba perplejo cuando esto sucedió al azar para mí para uno de mis contenedores, mientras que los otros contenedores estaban bien. El contenedor estaba conectado a al menos una red no interna , por lo que no había nada de malo en la Composedefinición. Reiniciar el demonio VM / docker no ayudó. Tampoco fue un problema de DNS porque el contenedor ni siquiera podía tener pinguna IP externa. Lo que me resolvió fue recrear las redes de acopladores. En mi caso, docker-compose down && docker-compose upfuncionó.

Componer

Esto obliga a la recreación de todas las redes de todos los contenedores:

docker-compose down && docker-compose up

Modo enjambre

Supongo que simplemente eliminas y vuelves a crear el servicio, que recrea las redes del servicio:

docker service rm some-service

docker service create ...

Si las redes del contenedor son externas

Simplemente elimine y vuelva a crear las redes externas de ese servicio:

docker network rm some-external-network

docker network create some-external-network

Para mí fue el firewall del host. Tenía que permitir DNS en el firewall del host. Y también tuvo que reiniciar Docker después de cambiar la configuración del firewall del host.

Ningún acceso a Internet también puede ser causado por la falta de configuraciones de proxy . En ese caso, --network hostpuede que tampoco funcione. El proxy se puede configurar configurando las variables de entorno http_proxyy https_proxy:

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

No olvide establecer no_proxy también, o todas las solicitudes (incluidas las de localhost) pasarán por el proxy.

Más información: Configuración de proxy en Archlinux Wiki.

Para mí fue una regla de reenvío de iptables. Por alguna razón, la siguiente regla, cuando se combinó con las reglas de iptables de Docker, causó que todo el tráfico saliente de los contenedores golpeara 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

Tuve el problema en Ubuntu 18.04. Sin embargo, el problema fue con el DNS. Estaba en una red corporativa que tiene su propio servidor DNS y bloquea otros servidores DNS. Esto es para bloquear algunos sitios web (pornografía, torrents, etc.)

Para resolver su problema

1. encuentra tu DNS en la máquina host

2. use --dns your_dns como lo sugiere @jobin

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

En Windows (8.1) eliminé la interfaz de virtualbox (a través de taskmgr) y resolvió el problema.

Es posible que haya iniciado su ventana acoplable con las opciones de DNS --dns 172.x.x.x

Tuve el mismo error y eliminé las opciones de /etc/default/docker

Las líneas:

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

Para Ubuntu 19.04 que usa openconnect 8.3 para VPN, tuve que vincular /etc/resolve.conf con el de systemd (opuesto a answerby wisbucky)

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

Pasos para depurar

1. Conéctese a la VPN de la empresa
2. Busque la configuración correcta de VPN en /etc/resolv.conf o /run/systemd/resolve/resolv.conf
3. Cualquiera que tenga la configuración de DNS correcta, la vincularemos al otro archivo (Sugerencia: coloque una con la configuración correcta a la izquierda de la asignación)

Versión Docker: Docker versión 19.03.0-rc2, compilación f97efcc

Si está en OSX, es posible que deba reiniciar su máquina después de instalar Docker. Esto ha sido un problema a veces.

Originalmente, mi contenedor Docker pudo llegar a Internet externo (este es un servicio / contenedor Docker que se ejecuta en un Amazon EC2).

Como mi aplicación es una API, seguí la creación de mi contenedor (logró extraer todos los paquetes que necesitaba) con la actualización de mis Tablas IP para enrutar todo el tráfico desde el puerto 80 al puerto donde estaba mi API (ejecutándose en la ventana acoplable) escuchando

Luego, más tarde cuando intenté reconstruir el contenedor, falló. Después de mucha lucha, descubrí que mi paso anterior (establecer la regla de reenvío de puertos IPTable) estropeó la capacidad de red externa del acoplador.

Solución: Detenga su servicio de IPTable:

sudo service iptables stop

Reinicia el Docker Daemon:

sudo service docker restart

Luego, intente reconstruir su contenedor. Espero que esto ayude.

Seguimiento

Pasé por alto por completo que no necesitaba meterme con las Tablas IP para reenviar el tráfico entrante a 80 al puerto en el que se ejecutaba la API que se ejecutaba en la ventana acoplable. En cambio, simplemente alias el puerto 80 al puerto en el que se ejecutaba la API en Docker:

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

Simplemente agregue esto aquí en caso de que alguien se encuentre con este problema dentro de un contenedor virtualbox que ejecuta Docker. Volví a configurar la red virtualbox en puente en lugar de nat, y el problema desapareció.

para mí, mi problema fue porque iptables-services no estaba instalado, esto funcionó para mí (CentOS):

sudo yum install iptables-services
sudo service docker restart

En centos 8, mi problema fue que no instalé e inicié iptables antes de iniciar el servicio de Docker. Asegúrese de que el servicio de iptables esté en funcionamiento antes de iniciar el servicio de docker.

También encontré un problema al intentar configurar un proyecto usando Docker-Compose en Ubuntu.

El Docker no tenía acceso a Internet en absoluto, cuando intenté hacer ping a cualquier dirección IP o buscar alguna URL, fallaba todo el tiempo.

Probé todas las posibles soluciones con resolución DNS descritas anteriormente en vano.

Pasé todo el día tratando de averiguar qué demonios estaba pasando, y finalmente descubrí que la causa de todos los problemas era el antivirus, en particular su firewall, que por alguna razón impidió que Docker obtuviera la dirección IP y el puerto.

Cuando lo desactivé, todo funcionó bien.

Entonces, si tiene un antivirus instalado y nada ayuda a solucionar el problema, el problema podría ser el firewall del antivirus.

He tenido un problema similar en los últimos días. Para mí, la causa fue una combinación de systemd, docker y mi proveedor de alojamiento. Estoy ejecutando CentOS actualizado (7.7.1908).

Mi proveedor de alojamiento genera automáticamente un archivo de configuración para systemd-networkd. Comenzando con systemd 219, que es la versión actual de CentOS 7, systemd-networkd tomó el control de los parámetros sysctl relacionados con la red. Docker parece ser incompatible con esta versión y restablecerá los indicadores de reenvío de IP cada vez que se inicie un contenedor.

Mi solución fue agregar IPForward=truela [Network]sección del archivo de configuración generado por mi proveedor. Este archivo puede estar en varios lugares, muy probablemente en /etc/systemd/network.

El proceso también se describe en los documentos oficiales de Docker: https://docs.docker.com/v17.09/engine/installation/linux/linux-postinstall/#ip-forwarding-problems

para mí, usando centos 7.4, no se trataba de /etc/resolve.conf, iptables, iptables nat rules ni docker en sí. El problema es que al host le falta el paquete bridge-utils que Docker requiere para construir el puente usando el comando brctl. yum install -y bridge-utils y reinicie docker, resuelva el problema.