В моем докерном контейнере нет интернета

Ответ 1

Исправлено, следуя этому совету:

[...] вы можете попробовать сбросить все?

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

Это заставит докер воссоздать мост и переустановить все сетевые правила

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

Кажется, интерфейс как-то "завис".

Обновление для более новых версий докера:

Вышеприведенный ответ все еще может выполнить вашу работу, но прошло довольно много времени с тех пор, как этот ответ был опубликован, и докер теперь более отточен, поэтому убедитесь, что вы сначала попробовали это, прежде чем углубляться в iptables и все.

sudo service docker restart или (если вы находитесь в дистрибутиве Linux, который не использует upstart) sudo systemctl restart docker

Ответ 2

Первое, что нужно проверить, - запустить cat/etc/resolv.conf в контейнере докера. Если у него есть недопустимый DNS-сервер, такой как nameserver 127.0.xx, то контейнер не сможет разрешить имена доменов в IP-адресах, поэтому ping google.com не удастся.

Второе, что нужно проверить, - запустить cat/etc/resolv.conf на главной машине. Docker в основном копирует хост /etc/resolv.conf в контейнер каждый раз при запуске контейнера. Поэтому, если хост /etc/resolv.conf ошибочен, тогда будет контейнер докеров.

Если вы обнаружили, что хост /etc/resolv.conf ошибочен, у вас есть 2 варианта:

1. Жесткий код DNS-сервера в daemon.json. Это легко, но не идеально, если вы ожидаете изменения DNS-сервера.

2. Исправить хосты /etc/resolv.conf. Это немного сложнее, но он генерируется динамически, и вы не кодируете DNS-сервер.

1. DNS-сервер с жестким кодом в docker daemon.json

• Редактировать /etc/docker/daemon.json

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

• Перезапустите демон докеров, чтобы эти изменения вступили в силу:
  sudo systemctl restart docker

• Теперь, когда вы запускаете/запускаете контейнер, докер заполняет /etc/resolv.conf значениями из daemon.json.

2. Исправить хосты /etc/resolv.conf

A. Ubuntu 16.04 и ранее

• Для Ubuntu 16.04 и ранее, /etc/resolv.conf динамически генерировался NetworkManager.

• Прокомментируйте строку dns=dnsmasq (с #) в /etc/NetworkManager/NetworkManager.conf

• Перезапустите NetworkManager для восстановления /etc/resolv.conf:
  sudo systemctl restart network-manager

• Проверьте на хосте: cat/etc/resolv.conf

B. Ubuntu 18.04 и более поздние

• Ubuntu 18.04 изменен для использования systemd-resolved для создания /etc/resolv.conf. Теперь по умолчанию он использует локальный DNS-кеш 127.0.0.53. Это не будет работать внутри контейнера, поэтому Docker по умолчанию будет использовать DNS-сервер Google 8.8.8.8, который может сломаться для людей за брандмауэром.

• /etc/resolv.conf на самом деле символическая ссылка (ls -l/etc/resolv.conf), которая по умолчанию указывает на /run/systemd/resolve/stub-resolv.conf (127.0.0.53) по умолчанию в Ubuntu 18.04.

• Просто измените символическую ссылку на пункт /run/systemd/resolve/resolv.conf, в котором перечислены реальные DNS-серверы:
  sudo ln -sf/run/systemd/resolve/resolv.conf/etc/resolv.conf

• Проверьте на хосте: cat/etc/resolv.conf

Теперь у вас должен быть действительный /etc/resolv.conf на хосте для докеров, который будет копироваться в контейнеры.

Ответ 3

Предполагаемый способ перезапуска докеры - это не делать это вручную, но использовать команду service или init:

service docker restart

Ответ 4

Обновление этого вопроса с ответом для OSX (с использованием Docker Machine)

Если вы запускаете Docker на OSX с помощью Docker Machine, то для меня работало следующее:

docker-machine restart

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

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

Затем (по крайней мере, по моему опыту), если вы выполните ping google.com из контейнера, все будет хорошо.

Ответ 5

Я использовал DOCKER_OPTS="--dns 8.8.8.8" и позже обнаружил, и мой контейнер не имел прямого доступа к Интернету, но мог получить доступ к моей корпоративной интрасети. Я изменил DOCKER_OPTS на следующее:

DOCKER_OPTS="--dns <internal_corporate_dns_address"

заменяя internal_corporate_dns_address на IP-адрес или полное доменное имя нашего DNS и перезагруженный докер, используя

sudo service docker restart

а затем породил мой контейнер и проверил, что он имеет доступ к Интернету.

Ответ 6

Для меня это был хост-брандмауэр. Мне пришлось разрешить DNS на брандмауэре хоста. А также пришлось перезапустить докер после изменения настройки брандмауэра хоста.

Ответ 7

Для меня это было правило пересылки iptables. По какой-то причине следующее правило, в сочетании с правилами iptables докера, вызвало весь исходящий трафик из контейнеров, чтобы попасть в 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

Ответ 8

У меня была проблема с Ubuntu 18.04. Однако проблема была в DNS. Я был в корпоративной сети с собственным DNS-сервером и блокировал другие DNS-серверы. Это блокировать некоторые сайты (порно, торренты,... так далее)

Чтобы решить вашу проблему

1. найти свой DNS на главной машине

2. используйте --dns your_dns, как было предложено @jobin

   docker run --dns your_dns -it - имя cowsay --hostname cowsay debian bash

Ответ 9

Я не знаю, что я делаю, но это сработало для меня:

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

Ответ 10

Возможно, вы запустили свой докер с параметрами dns --dns 172.x.x.x

У меня была такая же ошибка и были удалены параметры из /etc/default/docker

Строки:

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

Ответ 11

В окнах (8.1) я убил интерфейс виртуального интерфейса (через taskmgr), и он решил проблему.

Ответ 12

Отсутствие доступа в Интернет также может быть вызвано отсутствием настроек прокси. В этом случае --network host может не работать. Прокси-сервер можно настроить, установив переменные среды http_proxy и https_proxy:

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

Не забудьте также установить no_proxy, или все запросы (в том числе на localhost) пройдут через прокси.

Дополнительная информация: Настройки прокси в вики Archlinux.

Ответ 13

Если вы находитесь на OSX, вам может потребоваться перезагрузить компьютер после установки Docker. Иногда это было проблемой.

Ответ 14

Первоначально мой контейнер-докер смог добраться до внешнего интернета (это докер-сервис/контейнер, работающий на Amazon EC2).

Поскольку мое приложение является API, я следил за созданием моего контейнера (ему удалось достать все необходимые ему пакеты) с обновлением моих IP-таблиц для маршрутизации всего трафика с порта 80 на порт, который мой API (работает на докере) был прослушивание.

Затем, позже, когда я попытался восстановить контейнер, он потерпел неудачу. После большой борьбы я обнаружил, что мой предыдущий шаг (настройка правила переадресации портов IPTable) испортил возможности внешнего сетевого подключения докеров.

Решение. Остановите службу IPTable:

sudo service iptables stop

Перезапуск Docker Daemon:

sudo service docker restart

Затем попробуйте восстановить свой контейнер. Надеюсь это поможет.

Следовать за

Я полностью упустил из виду, что мне не нужно было связываться с IP-таблицами, чтобы пересылать входящий трафик до 80 к порту, на котором запущен API, работающий на докере. Вместо этого я просто использовал порт 80 для порта, на котором запущен API в докере:

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

Ответ 15

Я был в замешательстве, когда это произошло случайно для меня с одним из моих контейнеров, в то время как другие контейнеры были в порядке. Контейнер был подключен как минимум к одной не внутренней сети, поэтому с определением Compose. Перезапуск демона VM/docker не помог. Это также не было проблемой DNS, потому что контейнер не мог даже ping внешний IP. Для меня это решило воссоздать сеть (и) докеров. В моем случае сработал docker-compose down && docker-compose up.

компоновать

Это заставляет воссоздать все сети всех контейнеров:

docker-compose down docker-compose up && docker-compose up

Режим роя

Я полагаю, вы просто удалите и воссоздаете сервис, который воссоздает сервисные сети:

docker service rm some-service

docker service create...

Если контейнерная сеть являются внешними

Просто удалите и воссоздайте внешние сети этого сервиса:

docker network rm some-external-network

docker network create some-external-network

Ответ 16

Просто добавьте это здесь, если кто-то столкнется с этой проблемой в контейнере виртуального бокса, на котором работает докер. Я переконфигурировал сеть виртуальных боксов вместо моста вместо nat, и проблема исчезла.

Ответ 17

Для Ubuntu 19.04, использующей openconnect 8.3 для VPN, мне пришлось использовать символическую ссылку /etc/resolve.conf на тот, что указан в systemd (в отличие от answerby wisbucky)

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

Шаги для отладки

1. Подключиться к компании VPN
2. Найдите правильные настройки VPN в /etc/resolv.conf или /run/systemd/resolve/resolv.conf
3. В зависимости от того, какие настройки DNS правильные, мы будем ссылаться на этот файл с другим файлом (подсказка: поместите файл с правильными настройками слева от назначения)

Версия Docker: версия Docker 19.03.0-rc2, сборка f97efcc

Ответ 18

Я также столкнулся с такой проблемой при попытке настроить проект с помощью Docker-Compose в Ubuntu.

Docker вообще не имел доступа к Интернету, когда я пытался пропинговать любой IP-адрес или nslookup какой-то URL - он все время терпел неудачу.

Я перепробовал все возможные решения с разрешением DNS, описанные выше, но безрезультатно.

Я провел весь день, пытаясь выяснить, что происходит, и, наконец, выяснил, что причиной всех неприятностей был антивирус, в частности его брандмауэр, который по какой-то причине заблокировал Docker для получения IP-адреса и порта.

Когда я его отключил - все работало нормально.

Итак, если у вас установлен антивирус и ничего не помогает решить проблему - проблема может быть в брандмауэре антивируса.

Ответ 19

У меня была похожая проблема за последние несколько дней. Для меня причиной стала комбинация systemd, docker и моего хостинг-провайдера. Я использую последнюю версию CentOS (7.7.1908).

Мой хостинг-провайдер автоматически создает файл конфигурации для systemd-networkd. Начиная с systemd 219, которая является текущей версией CentOS 7, systemd-networkd контролирует параметры sysctl, связанные с сетью. Docker, похоже, несовместим с этой версией и будет сбрасывать флаги IP-пересылки при каждом запуске контейнера.

Моим решением было добавить IPForward=true в [Network] -section моего конфигурационного файла, созданного моим провайдером. Этот файл может находиться в нескольких местах, скорее всего, в /etc/systemd/network.

Процесс также описан в официальных документах Docker: https://docs.docker.com/v17.09/engine/installation/linux/linux-postinstall/#ip-forwarding-problems