Mój kontener docker nie ma internetu

Miałem to dobrze, ale teraz przestało. Bezskutecznie wypróbowałem następujące polecenia:

docker run -dns 8.8.8.8 base ping google.com

docker run base ping google.com

sysctl -w net.ipv4.ip_forward=1 - zarówno na hoście, jak i na kontenerze

Wszystko co dostaję to unknown host google.com. Docker w wersji 0.7.0

Jakieś pomysły?

PS również ufwwyłączony

Pierwszą rzeczą do sprawdzenia jest uruchomienie cat /etc/resolv.confw kontenerze docker . Jeśli ma nieprawidłowy serwer DNS, na przykład nameserver 127.0.x.x, kontener nie będzie w stanie przekształcić nazw domen w adresy IP, więc ping google.comzakończy się niepowodzeniem.

Drugą rzeczą do sprawdzenia jest uruchomienie cat /etc/resolv.confna komputerze głównym . Docker w zasadzie kopiuje hosta /etc/resolv.confdo kontenera za każdym razem, gdy kontener jest uruchamiany. Więc jeśli host /etc/resolv.confjest zły, to samo będzie w kontenerze docker.

Jeśli zauważyłeś, że host /etc/resolv.confjest zły, masz 2 opcje:

1. Zakoduj serwer DNS na stałe w daemon.json. Jest to łatwe, ale nie idealne, jeśli spodziewasz się zmiany serwera DNS.

2. Napraw plik gospodarzy /etc/resolv.conf. Jest to trochę trudniejsze, ale jest generowane dynamicznie i nie kodujesz na stałe serwera DNS.

1. Serwer DNS z twardym kodem w docker daemon.json

• Edytować /etc/docker/daemon.json

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

• Zrestartuj demona Dockera, aby zmiany odniosły skutek:
  sudo systemctl restart docker

• Teraz, gdy uruchomisz / uruchomisz kontener, docker zapełni /etc/resolv.confwartości z daemon.json.

2. Napraw pliki hostów /etc/resolv.conf

A. Ubuntu 16.04 i wcześniejsze

• Dla Ubuntu 16.04 i wcześniejszych /etc/resolv.confbył dynamicznie generowany przez NetworkManager.

• Skomentuj linię dns=dnsmasq(z a #) w /etc/NetworkManager/NetworkManager.conf

• Uruchom ponownie NetworkManager, aby zregenerować /etc/resolv.conf:
  sudo systemctl restart network-manager

• Zweryfikuj na hoście: cat /etc/resolv.conf

B. Ubuntu 18.04 i nowsze

• Ubuntu 18.04 zmieniono na używanie systemd-resolveddo generowania/etc/resolv.conf . Teraz domyślnie używa lokalnej pamięci podręcznej DNS 127.0.0.53. To nie zadziała w kontenerze, więc Docker domyślnie użyje serwera DNS Google 8.8.8.8, który może się zepsuć dla osób za zaporą ogniową.

• /etc/resolv.confjest właściwie dowiązaniem symbolicznym ( ls -l /etc/resolv.conf), które /run/systemd/resolve/stub-resolv.confdomyślnie wskazuje na (127.0.0.53) w Ubuntu 18.04.

• Po prostu zmień łącze symboliczne, na które wskazuje /run/systemd/resolve/resolv.conf, które zawiera listę prawdziwych serwerów DNS:
  sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf

• Zweryfikuj na hoście: cat /etc/resolv.conf

Teraz powinieneś mieć ważny /etc/resolv.confna hoście, aby docker mógł skopiować do kontenerów.

Naprawiono postępując zgodnie z tą radą:

[...] czy możesz spróbować zresetować wszystko?

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

Zmusi to docker do odtworzenia mostka i ponownego wprowadzenia wszystkich reguł sieciowych

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

Wygląda na to, że interfejs został jakoś „powieszony”.

Aktualizacja dla nowszych wersji Dockera:

Powyższa odpowiedź może nadal wykonać zadanie za Ciebie, ale minęło sporo czasu, odkąd ta odpowiedź została opublikowana, a docker jest teraz bardziej dopracowany, więc upewnij się, że wypróbujesz je najpierw, zanim przejdziesz do zniekształcenia iptables.

sudo service docker restart lub (jeśli jesteś w dystrybucji Linuksa, która nie używa Upstart) sudo systemctl restart docker

Zamierzonym sposobem ponownego uruchomienia dockera nie jest zrobienie tego ręcznie, ale użycie polecenia serviceor init:

service docker restart

Aktualizacja tego pytania z odpowiedzią dla OSX (przy użyciu Docker Machine)

Jeśli używasz Dockera na OSX przy użyciu Docker Machine, wtedy zadziałało:

docker-machine restart

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

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

Wtedy (przynajmniej z mojego doświadczenia), jeśli pingujesz google.com z kontenera, wszystko będzie dobrze.

Nie wiem, co robię, ale to zadziałało:

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

Używałem DOCKER_OPTS="--dns 8.8.8.8"i później odkryłem, że mój kontener nie miał bezpośredniego dostępu do Internetu, ale mógł uzyskać dostęp do mojego firmowego intranetu. Zmieniłem DOCKER_OPTSna następujące:

DOCKER_OPTS="--dns <internal_corporate_dns_address"

Zastąpienie internal_corporate_dns_addressadresem IP lub FQDN naszego DNS i zrestartowałem docker przy użyciu

sudo service docker restart

a następnie stworzyłem mój kontener i sprawdziłem, czy ma dostęp do internetu.

Byłem zaskoczony, gdy stało się to dla mnie losowo dla jednego z moich pojemników, podczas gdy inne pojemniki były w porządku. Kontener został dołączony do co najmniej jednej sieci innej niż wewnętrzna , więc Composedefinicja nie zawierała żadnych błędów . Ponowne uruchomienie demona VM / Docker nie pomogło. Nie był to również problem z DNS, ponieważ kontener nie mógł nawet pingmieć zewnętrznego adresu IP. Rozwiązaniem dla mnie było odtworzenie sieci (sieci) dockera. W moim przypadku docker-compose down && docker-compose upzadziałało.

Komponować

Wymusza to odtworzenie wszystkich sieci wszystkich kontenerów:

docker-compose down && docker-compose up

Tryb roju

Przypuszczam, że wystarczy usunąć i odtworzyć usługę, która odtwarza sieci usługi:

docker service rm some-service

docker service create ...

Jeśli sieci kontenera są zewnętrzne

Po prostu usuń i utwórz ponownie zewnętrzne sieci tej usługi:

docker network rm some-external-network

docker network create some-external-network

Dla mnie był to firewall hosta. Musiałem zezwolić na DNS na zaporze hosta. Po zmianie ustawienia zapory hosta musiałem również ponownie uruchomić docker.

Brak dostępu do Internetu może być również spowodowany brakiem ustawień proxy . W takim przypadku --network hostmoże też nie działać. Serwer proxy można skonfigurować, ustawiając zmienne środowiskowe http_proxyi https_proxy:

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

Nie zapomnij również ustawić no_proxy, w przeciwnym razie wszystkie żądania (w tym kierowane do localhost) będą przechodzić przez proxy.

Więcej informacji: Ustawienia proxy na Archlinux Wiki.

Dla mnie była to reguła przekierowania iptables. Z jakiegoś powodu poniższa reguła, w połączeniu z regułami iptables platformy docker, spowodowała trafienie całego ruchu wychodzącego z kontenerów 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

Miałem problem na Ubuntu 18.04. Jednak problem był z DNS. Byłem w sieci firmowej, która ma własny serwer DNS i blokuje inne serwery DNS. Ma to na celu zablokowanie niektórych stron internetowych (pornografia, torrenty itp.)

Aby rozwiązać problem

1. znajdź swój DNS na komputerze hosta

2. użyj --dns your_dns zgodnie z sugestią @jobin

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

W systemie Windows (8.1) zabiłem interfejs virtualbox (przez taskmgr) i rozwiązałem problem.

Być może uruchomiłeś swój docker z opcjami dns --dns 172.x.x.x

Miałem ten sam błąd i usunąłem opcje z /etc/default/docker

Linie:

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

W przypadku Ubuntu 19.04 używającego openconnect 8.3 dla VPN, musiałem dowiązać symboliczne /etc/resolve.conf do tego w systemd (przeciwieństwo odpowiedzi wisbucky'ego)

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

Kroki do debugowania

1. Połącz się z firmową siecią VPN
2. Poszukaj poprawnych ustawień VPN w /etc/resolv.conf lub /run/systemd/resolve/resolv.conf
3. Niezależnie od tego, który ma prawidłowe ustawienia DNS, połączymy go z innym plikiem (Wskazówka: umieść jeden z poprawnymi ustawieniami po lewej stronie przypisania)

Wersja platformy Docker: wersja Dockera 19.03.0-rc2, kompilacja f97efcc

Jeśli korzystasz z systemu OSX, może być konieczne ponowne uruchomienie komputera po zainstalowaniu platformy Docker. Czasami był to problem.

Początkowo mój kontener docker był w stanie dotrzeć do zewnętrznego internetu (jest to usługa / kontener docker działający na Amazon EC2).

Ponieważ moja aplikacja jest interfejsem API, kontynuowałem tworzenie mojego kontenera (udało mi się pobrać wszystkie potrzebne pakiety), aktualizując moje tabele IP, aby kierować cały ruch z portu 80 do portu, na którym znajdował się mój interfejs API (działający w Docker) nasłuchiwać.

Później, gdy próbowałem odbudować kontener, nie udało się. Po wielu zmaganiach odkryłem, że mój poprzedni krok (ustawienie reguły przekierowania portów IPTable) zepsuł możliwości zewnętrznej sieci dokera.

Rozwiązanie: Zatrzymaj usługę IPTable:

sudo service iptables stop

Uruchom ponownie demona platformy Docker:

sudo service docker restart

Następnie spróbuj odbudować kontener. Mam nadzieję że to pomoże.

Zagryźć

Całkowicie przeoczyłem, że nie musiałem majstrować przy tabelach IP, aby przekazywać ruch przychodzący do 80 do portu, na którym działało API działające w dockerze. Zamiast tego utworzyłem alias portu 80 do portu, na którym działał interfejs API w dockerze:

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

Dodanie tego tutaj na wypadek, gdyby ktoś napotkał ten problem w kontenerze virtualbox z uruchomionym dockerem. Skonfigurowałem sieć virtualbox na mostkowanie zamiast nat i problem zniknął.

dla mnie mój problem polegał na tym, że iptables-services nie zostało zainstalowane, to zadziałało dla mnie (CentOS):

sudo yum install iptables-services
sudo service docker restart

Na centos 8 moim problemem było to, że nie zainstalowałem i nie uruchomiłem iptables przed uruchomieniem usługi docker. Upewnij się, że usługa iptables jest uruchomiona przed uruchomieniem usługi Docker.

Napotkałem też taki problem podczas próby skonfigurowania projektu za pomocą Docker-Compose na Ubuntu.

Docker nie miał w ogóle dostępu do internetu, kiedy próbowałem pingować dowolny adres IP lub nslookować jakiś URL - cały czas się nie udawało.

Bezskutecznie wypróbowałem wszystkie możliwe rozwiązania z opisaną powyżej rozdzielczością DNS.

Spędziłem cały dzień próbując dowiedzieć się, co się dzieje, aż w końcu dowiedziałem się, że przyczyną wszystkich problemów był program antywirusowy, w szczególności jego firewall, który z jakiegoś powodu zablokował Dockerowi uzyskanie adresu IP i portu.

Kiedy go wyłączyłem - wszystko działało dobrze.

Jeśli więc masz zainstalowany program antywirusowy i nic nie pomaga rozwiązać problemu - problemem może być zapora ogniowa programu antywirusowego.

Od kilku dni mam podobny problem. Dla mnie przyczyną była kombinacja systemd, docker i mojego dostawcy hostingu. Korzystam z aktualnego CentOS (7.7.1908).

Mój dostawca hostingu automatycznie generuje plik konfiguracyjny dla systemd-networkd. Począwszy od systemd 219, który jest aktualną wersją CentOS 7, systemd-networkd przejął kontrolę nad parametrami sysctl związanymi z siecią. Docker wydaje się być niekompatybilny z tą wersją i zresetuje flagi przekazywania IP za każdym razem, gdy kontener zostanie uruchomiony.

Moim rozwiązaniem było dodanie IPForward=truew sekcji [Network]mojego pliku konfiguracyjnego wygenerowanego przez dostawcę. Ten plik może znajdować się w kilku miejscach, najprawdopodobniej w/etc/systemd/network .

Proces jest również opisany w oficjalnych dokumentach docker: https://docs.docker.com/v17.09/engine/installation/linux/linux-postinstall/#ip-forwarding-problems

dla mnie, używając centos 7.4, nie było to kwestia /etc/resolve.conf, iptables, reguł iptables nat ani samego dockera. Problem polega na tym, że na hoście brakuje pakietu bridge-utils, którego docker wymaga do zbudowania mostu za pomocą polecenia brctl. yum install -y bridge-utils i zrestartuj docker, rozwiąż problem.