Il mio contenitore docker non ha Internet

L'ho fatto funzionare bene ma ora si è fermato. Ho provato i seguenti comandi senza alcun risultato:

docker run -dns 8.8.8.8 base ping google.com

docker run base ping google.com

sysctl -w net.ipv4.ip_forward=1 - sia sull'host che sul contenitore

Tutto quello che ottengo è unknown host google.com. Docker versione 0.7.0

Qualche idea?

Anche PS ufwdisabilitato

La prima cosa da controllare viene eseguita cat /etc/resolv.confnel contenitore della finestra mobile . Se ha un server DNS non valido, ad esempio nameserver 127.0.x.x, il contenitore non sarà in grado di risolvere i nomi di dominio in indirizzi IP, quindi ping google.comfallirà.

La seconda cosa da verificare viene eseguita cat /etc/resolv.confsul computer host . Docker fondamentalmente copia l'host /etc/resolv.confnel contenitore ogni volta che viene avviato un contenitore. Quindi, se l'host /etc/resolv.confè sbagliato, lo sarà anche il contenitore della finestra mobile.

Se hai scoperto che l'host /etc/resolv.confè sbagliato, hai 2 opzioni:

1. Hardcode del server DNS in daemon.json. Questo è semplice, ma non ideale se si prevede che il server DNS cambi.

2. Correggi gli host /etc/resolv.conf. Questo è un po 'più complicato, ma viene generato in modo dinamico e non stai codificando il server DNS.

1. Server DNS hardcode in docker daemon.json

• modificare /etc/docker/daemon.json

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

• Riavvia il daemon docker per rendere effettive le modifiche:
  sudo systemctl restart docker

• Ora quando si esegue / avvia un contenitore, la finestra mobile verrà popolata /etc/resolv.confcon i valori da daemon.json.

2. Correggi gli host /etc/resolv.conf

A. Ubuntu 16.04 e precedenti

• Per Ubuntu 16.04 e precedenti, è /etc/resolv.confstato generato dinamicamente da NetworkManager.

• Commenta la riga dns=dnsmasq(con a #) in /etc/NetworkManager/NetworkManager.conf

• Riavvia NetworkManager per rigenerare /etc/resolv.conf:
  sudo systemctl restart network-manager

• Verifica sull'host: cat /etc/resolv.conf

B. Ubuntu 18.04 e versioni successive

• Ubuntu 18.04 è stato modificato per utilizzare systemd-resolvedper generare/etc/resolv.conf . Ora, per impostazione predefinita, utilizza una cache DNS locale 127.0.0.53. Questo non funzionerà all'interno di un container, quindi Docker passerà automaticamente al server DNS 8.8.8.8 di Google, che potrebbe rompersi per le persone dietro un firewall.

• /etc/resolv.confè in realtà un symlink ( ls -l /etc/resolv.conf) che punta a /run/systemd/resolve/stub-resolv.conf(127.0.0.53) per impostazione predefinita in Ubuntu 18.04.

• Basta cambiare il collegamento simbolico a cui puntare /run/systemd/resolve/resolv.conf, che elenca i server DNS reali:
  sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

• Verifica sull'host: cat /etc/resolv.conf

Ora dovresti avere un valido /etc/resolv.confsull'host per la finestra mobile da copiare nei contenitori.

Risolto seguendo questo consiglio:

[...] puoi provare a resettare tutto?

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

Costringerà la finestra mobile a ricreare il bridge e a reintegrare tutte le regole di rete

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

Sembra che l'interfaccia sia stata "impiccata" in qualche modo.

Aggiornamento per le versioni più recenti della finestra mobile:

La risposta di cui sopra potrebbe ancora portare a termine il lavoro per te, ma è passato un bel po 'di tempo da quando questa risposta è stata pubblicata e la finestra mobile è più raffinata ora, quindi assicurati di provarle prima di iniziare a manipolare con iptablestutto.

sudo service docker restart oppure (se ci si trova in una distribuzione Linux che non utilizza upstart) sudo systemctl restart docker

Il modo previsto per riavviare la finestra mobile non è di farlo manualmente ma utilizzare il servicecomando o init:

service docker restart

Aggiornamento di questa domanda con una risposta per OSX (utilizzando Docker Machine)

Se stai eseguendo Docker su OSX usando Docker Machine, allora per me ha funzionato:

docker-machine restart

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

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

Quindi (almeno nella mia esperienza), se esegui il ping di google.com da un contenitore, tutto andrà bene.

Non so cosa sto facendo, ma ha funzionato per me:

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

Stavo usando DOCKER_OPTS="--dns 8.8.8.8"e in seguito ho scoperto che il mio container non aveva accesso diretto a Internet ma poteva accedere alla mia intranet aziendale. Ho cambiato DOCKER_OPTSil seguente:

DOCKER_OPTS="--dns <internal_corporate_dns_address"

sostituendo internal_corporate_dns_addresscon l'indirizzo IP o FQDN del nostro DNS e la finestra mobile riavviata utilizzando

sudo service docker restart

e poi ha generato il mio contenitore e verificato che avesse accesso a Internet.

Ero sconcertato quando ciò è accaduto casualmente per me per uno dei miei contenitori, mentre gli altri contenitori andavano bene. Il contenitore era collegato ad almeno una rete non interna , quindi non c'era nulla di sbagliato nella Composedefinizione. Il riavvio del daemon VM / docker non ha aiutato. Inoltre non era un problema DNS perché il contenitore non poteva nemmeno pingun IP esterno. Ciò che ha risolto per me è stato ricreare le reti docker. Nel mio caso, ha docker-compose down && docker-compose upfunzionato.

Comporre

Ciò forza la ricreazione di tutte le reti di tutti i container:

docker-compose down && docker-compose up

Modalità sciame

Suppongo che tu abbia semplicemente rimosso e ricreato il servizio, che ricrea le reti del servizio:

docker service rm some-service

docker service create ...

Se le reti del contenitore sono esterne

Basta rimuovere e ricreare le reti esterne di quel servizio:

docker network rm some-external-network

docker network create some-external-network

Per me era il firewall dell'host. Ho dovuto consentire il DNS sul firewall dell'host. E ha anche dovuto riavviare la finestra mobile dopo aver modificato l'impostazione del firewall host.

Nessun accesso a Internet può essere causato anche da impostazioni proxy mancanti . In tal caso, --network hostpotrebbe non funzionare neanche. Il proxy può essere configurato impostando le variabili di 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" ... 

Non dimenticare di impostare anche no_proxy, altrimenti tutte le richieste (comprese quelle a localhost) passeranno attraverso il proxy.

Ulteriori informazioni: Impostazioni proxy nel Wiki di Archlinux.

Per me era una regola di inoltro di iptables. Per qualche motivo la seguente regola, quando accoppiata con le regole iptables della docker, ha fatto sì che tutto il traffico in uscita dai container colpisse 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

Ho avuto il problema su Ubuntu 18.04. Tuttavia, il problema riguardava il DNS. Ero in una rete aziendale che ha il proprio server DNS e bloccare altri server DNS. Questo serve a bloccare alcuni siti Web (porno, torrent, ecc.)

Per risolvere il tuo problema

1. trova il tuo DNS sul computer host

2. usa --dns your_dns come suggerito da @jobin

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

Su windows (8.1) ho ucciso l'interfaccia virtualbox (tramite taskmgr) e ho risolto il problema.

Potresti aver avviato la finestra mobile con le opzioni DNS --dns 172.x.x.x

Ho avuto lo stesso errore e rimosso le opzioni da /etc/default/docker

Le linee:

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

Per Ubuntu 19.04 usando openconnect 8.3 per VPN, ho dovuto ricollegare /etc/resolve.conf a quello in systemd (opposto a answerby wisbucky)

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

I passaggi per il debug

1. Connettiti alla VPN aziendale
2. Cerca le impostazioni VPN corrette in /etc/resolv.conf o /run/systemd/resolve/resolv.conf
3. Qualunque abbia le impostazioni DNS corrette, lo collegheremo simbolicamente all'altro file (Suggerimento: posizionane uno con le impostazioni corrette a sinistra del compito)

Versione Docker: Docker versione 19.03.0-rc2, build f97efcc

Se utilizzi OSX, potrebbe essere necessario riavviare il computer dopo l'installazione di Docker. Questo è stato un problema a volte.

Inizialmente il mio contenitore docker era in grado di raggiungere Internet esterno (questo è un servizio / contenitore docker in esecuzione su un Amazon EC2).

Poiché la mia app è un'API, ho seguito la creazione del mio contenitore (è riuscito a estrarre tutti i pacchetti necessari) con l'aggiornamento delle mie tabelle IP per instradare tutto il traffico dalla porta 80 alla porta che era la mia API (in esecuzione su docker) ascoltando.

Quindi, più tardi, quando ho provato a ricostruire il contenitore, non è riuscito. Dopo molte difficoltà, ho scoperto che il mio passaggio precedente (impostazione della regola di port forwarding IPTable) ha compromesso la capacità di rete esterna della docker.

Soluzione: interrompere il servizio IPTable:

sudo service iptables stop

Riavvia il Docker Daemon:

sudo service docker restart

Quindi, prova a ricostruire il tuo contenitore. Spero che questo ti aiuti.

Azione supplementare

Ho completamente ignorato che non avevo bisogno di scherzare con le tabelle IP per inoltrare il traffico in entrata a 80 alla porta su cui era in esecuzione l'API in esecuzione sulla finestra mobile. Invece, ho appena spostato la porta 80 sulla porta su cui era in esecuzione l'API nella finestra mobile:

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

Aggiungendolo qui nel caso in cui qualcuno si imbatta in questo problema all'interno di un contenitore virtualbox che esegue la finestra mobile. Ho riconfigurato la rete di virtualbox in bridge anziché nat, e il problema è scomparso.

per me, il mio problema era dovuto al fatto che iptables-services non era installato, questo ha funzionato per me (CentOS):

sudo yum install iptables-services
sudo service docker restart

Su centos 8, il mio problema era che non avevo installato e avviato iptables prima di avviare il servizio docker. Assicurarsi che il servizio iptables sia attivo e funzionante prima di avviare il servizio docker.

Ho anche riscontrato un problema simile durante il tentativo di impostare un progetto utilizzando Docker-Compose su Ubuntu.

Il Docker non aveva affatto accesso a Internet, quando ho provato a eseguire il ping di qualsiasi indirizzo IP o a cercare un URL - non è riuscito tutto il tempo.

Ho provato inutilmente tutte le possibili soluzioni con la risoluzione DNS sopra descritta.

Ho trascorso l'intera giornata a cercare di capire cosa diavolo stesse succedendo e alla fine ho scoperto che la causa di tutti i problemi era l'antivirus, in particolare il firewall che per qualche motivo ha impedito a Docker di ottenere l'indirizzo IP e la porta.

Quando l'ho disabilitato, tutto ha funzionato bene.

Quindi, se hai installato un antivirus e nulla aiuta a risolvere il problema, il problema potrebbe essere il firewall dell'antivirus.

Ho avuto un problema simile negli ultimi giorni. Per me la causa è stata una combinazione di systemd, docker e il mio provider di hosting. Sono in esecuzione CentOS aggiornato (7.7.1908).

Il mio provider di hosting genera automaticamente un file di configurazione per systemd-networkd. A partire da systemd 219, che è la versione corrente di CentOS 7, systemd-networkd ha assunto il controllo dei parametri sysctl relativi alla rete. Docker sembra essere incompatibile con questa versione e reimposterà i flag di inoltro IP ogni volta che viene avviato un contenitore.

La mia soluzione era quella di aggiungere IPForward=truela [Network]sezione del mio file di configurazione generato dal provider. Questo file potrebbe trovarsi in diversi punti, molto probabilmente in /etc/systemd/network.

Il processo è anche descritto nei documenti docker ufficiali: https://docs.docker.com/v17.09/engine/installation/linux/linux-postinstall/#ip-forwarding-problems

per me, usando centos 7.4, non si trattava di /etc/resolve.conf, iptables, regole nat di iptables né docker stesso. Il problema è che l'host non ha il pacchetto bridge-utils che docker richiede per costruire il bridge usando il comando brctl. yum installa -y bridge-utils e riavvia la finestra mobile, risolvi il problema.