У меня все получилось, но теперь оно прекратилось. Я пробовал следующие команды безрезультатно:
docker run -dns 8.8.8.8 base ping google.com
docker run base ping google.com
sysctl -w net.ipv4.ip_forward=1 - как на хосте, так и на контейнере
Все, что я получаю, это unknown host google.com. Докер версии 0.7.0
Любые идеи?
P.S. ufw также отключен
Исправлено, следуя этому совету:
[...] вы можете попробовать сбросить все?
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
Первое, что нужно проверить, - запустить 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 варианта:
Жесткий код DNS-сервера в daemon.json. Это легко, но не идеально, если вы ожидаете изменения DNS-сервера.
Исправить хосты /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 на хосте для докеров, который будет копироваться в контейнеры.
Предполагаемый способ перезапуска докеры - это не делать это вручную, но использовать команду service или init:
service docker restart
Обновление этого вопроса с ответом для 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 из контейнера, все будет хорошо.
Я использовал 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
а затем породил мой контейнер и проверил, что он имеет доступ к Интернету.
Для меня это был хост-брандмауэр. Мне пришлось разрешить DNS на брандмауэре хоста. А также пришлось перезапустить докер после изменения настройки брандмауэра хоста.
Для меня это было правило пересылки 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
У меня была проблема с Ubuntu 18.04. Однако проблема была в DNS. Я был в корпоративной сети с собственным DNS-сервером и блокировал другие DNS-серверы. Это блокировать некоторые сайты (порно, торренты,... так далее)
Чтобы решить вашу проблему
используйте --dns your_dns, как было предложено @jobin
docker run --dns your_dns -it - имя cowsay --hostname cowsay debian bash
Я не знаю, что я делаю, но это сработало для меня:
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
Возможно, вы запустили свой докер с параметрами 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"
В окнах (8.1) я убил интерфейс виртуального интерфейса (через taskmgr), и он решил проблему.
Отсутствие доступа в Интернет также может быть вызвано отсутствием настроек прокси. В этом случае --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.
Если вы находитесь на OSX, вам может потребоваться перезагрузить компьютер после установки Docker. Иногда это было проблемой.
Первоначально мой контейнер-докер смог добраться до внешнего интернета (это докер-сервис/контейнер, работающий на 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>
Я был в замешательстве, когда это произошло случайно для меня с одним из моих контейнеров, в то время как другие контейнеры были в порядке. Контейнер был подключен как минимум к одной не внутренней сети, поэтому с определением 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
Просто добавьте это здесь, если кто-то столкнется с этой проблемой в контейнере виртуального бокса, на котором работает докер. Я переконфигурировал сеть виртуальных боксов вместо моста вместо nat, и проблема исчезла.
Для Ubuntu 19.04, использующей openconnect 8.3 для VPN, мне пришлось использовать символическую ссылку /etc/resolve.conf на тот, что указан в systemd (в отличие от answerby wisbucky)
sudo ln -sf/etc/resolv.conf/run/systemd/resolve/resolv.conf
Шаги для отладки
Версия Docker: версия Docker 19.03.0-rc2, сборка f97efcc
Я также столкнулся с такой проблемой при попытке настроить проект с помощью Docker-Compose в Ubuntu.
Docker вообще не имел доступа к Интернету, когда я пытался пропинговать любой IP-адрес или nslookup какой-то URL - он все время терпел неудачу.
Я перепробовал все возможные решения с разрешением DNS, описанные выше, но безрезультатно.
Я провел весь день, пытаясь выяснить, что происходит, и, наконец, выяснил, что причиной всех неприятностей был антивирус, в частности его брандмауэр, который по какой-то причине заблокировал Docker для получения IP-адреса и порта.
Когда я его отключил - все работало нормально.
Итак, если у вас установлен антивирус и ничего не помогает решить проблему - проблема может быть в брандмауэре антивируса.
У меня была похожая проблема за последние несколько дней. Для меня причиной стала комбинация 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