У моєму докерному контейнері немає Інтернету

У мене це було нормально, але зараз він припинився. Я спробував наступні команди безрезультатно:

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

Будь-які ідеї?

PS також ufwвідключений

Перше, що потрібно перевірити, це запустити cat /etc/resolv.confв контейнер докера . Якщо він має недійсний DNS-сервер, наприклад nameserver 127.0.x.x, контейнер не зможе вирішити доменні імена на ip-адреси,ping google.com не вдасться.

Друге, що потрібно перевірити, працює cat /etc/resolv.confна хост-машині . Docker в основному копіює хост /etc/resolv.confу контейнер щоразу, коли контейнер запускається. Тож якщо господаря/etc/resolv.conf помиляється, то так буде і з контейнером докера.

Якщо ви виявили, що хост /etc/resolv.confпомиляється, у вас є два варіанти:

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 8.8.8.8 DNS, який може зламатися для людей, що знаходяться за брандмауером.

• /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хост для docker для копіювання в контейнери.

Виправлено, дотримуючись цієї поради:

[...] чи можете ви спробувати скинути все?

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

Це змусить докер відтворити міст і знову встановити всі правила мережі

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

Здається, інтерфейс був якось "повішеним".

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

Вищенаведена відповідь може все-таки виконати роботу за вас, але минуло досить тривалий час, коли ця відповідь була розміщена, і докер зараз більш відполірований, тому переконайтеся, що ви спробуєте їх спочатку, перш ніж заходити в спілкування зі iptablesвсіма.

sudo service docker restart або (якщо ви перебуваєте в дистрибутиві Linux, який не використовує функцію запуску) sudo systemctl restart docker

Запропонований спосіб перезапустити докер - це не робити це вручну, а використовувати команду 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 з контейнера, все буде добре.

Я не знаю, що я роблю, але це працювало на мене:

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

Я використовував DOCKER_OPTS="--dns 8.8.8.8"і пізніше виявив, що мій контейнер не мав прямого доступу до Інтернету, але міг отримати доступ до моєї корпоративної інтранети. Я змінив DOCKER_OPTSнаступне:

DOCKER_OPTS="--dns <internal_corporate_dns_address"

замінивши internal_corporate_dns_addressIP-адресу або FQDN нашого DNS та перезапустивши докер за допомогою

sudo service docker restart

а потім породив мій контейнер і перевірив, чи має він доступ до Інтернету.

Мене натупили, коли це сталося випадково для мене одним із моїх контейнерів, тоді як інші контейнери були добре. Контейнер був приєднаний щонайменше до однієї не внутрішньої мережі, тому з Composeвизначенням нічого поганого не було . Перезавантаження демона VM / docker не допомогло. Це також не було проблемою DNS, оскільки контейнер не міг навіть pingзовнішньої IP-адреси. Для мене це вирішило відтворити докерську мережу. У моєму випадкуdocker-compose down && docker-compose up працювали.

Складіть

Це змушує відтворити всі мережі всіх контейнерів:

docker-compose down && docker-compose up

Режим рій

Я припускаю, що ви просто видалите та відтворите службу, яка відтворює мережі (-и) служби:

docker service rm some-service

docker service create ...

Якщо мережа (и) контейнера зовнішні

Просто видаліть і відтворіть зовнішні мережі цієї служби:

docker network rm some-external-network

docker network create some-external-network

Для мене це був брандмауер хоста. Я повинен був дозволити DNS на брандмауері хоста. А також довелося перезапустити докер після зміни налаштування брандмауера.

Немає доступу до Інтернету також не може бути спричинено відсутністю налаштувань проксі- сервера. У цьому випадку --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 Wiki.

Для мене це було правилом переадресації 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-сервери. Це для того, щоб заблокувати деякі веб-сайти (порно, торренти, ... тощо)

Щоб вирішити вашу проблему

1. знайдіть свою DNS на хост-машині

2. використання --dns your_dns як запропонував @jobin

   docker run --dns your_dns -it --name cowsay - ім'я cowsay debian bash

У Windows (8.1) я вбив інтерфейс virtualbox (через taskmgr), і це вирішило проблему.

Можливо, ви почали свій докер з опціями 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"

Для Ubuntu 19.04, що використовує openconnect 8.3 для VPN, мені довелося символізувати /etc/resolve.conf до того, що в systemd (навпроти відповіді 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 19.03.0-rc2, build f97efcc

Якщо ви перебуваєте на OSX, можливо, вам доведеться перезавантажити машину після встановлення Docker. Це часом було проблемою.

Спочатку мій контейнер докера зміг дістатися до зовнішнього Інтернету (Це докер-послуга / контейнер, що працює на Amazon EC2).

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

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

Рішення: Зупиніть свою послугу IPTable:

sudo service iptables stop

Перезапустіть демон Docker:

sudo service docker restart

Потім спробуйте відновити контейнер. Сподіваюся, це допомагає.

Слідувати

Я повністю не помітив, що мені не потрібно возитися з IP-таблицями, щоб пересилати вхідний трафік до 80 до порту, на якому працює API, що працює на docker. Натомість я просто псевдонімував порт 80 на порт, на якому працює API в докері:

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

Просто додайте це сюди, якщо хтось стикається з цією проблемою у вікні контейнера virtualbox, який працює докер. Я переналаштував мережу virtualbox на містку замість nat, і проблема пішла.

для мене моя проблема полягала в тому, що iptables-сервіси не встановлені, це працювало для мене (CentOS):

sudo yum install iptables-services
sudo service docker restart

У centos 8 моя проблема полягала в тому, що я не встановлював і запускав iptables перед початком служби docker. Переконайтеся, що служба iptables працює і працює перед тим, як розпочати службу докера.

Я також стикався з такою проблемою, намагаючись створити проект за допомогою Docker-Compose в Ubuntu.

У Докера взагалі не було доступу до Інтернету, коли я намагався ввести будь-яку IP-адресу або нанести якусь URL-адресу - він весь час провалювався.

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

Я провів цілий день, намагаючись з’ясувати, що за хек відбувається, і нарешті з’ясував, що причиною всіх проблем був антивірус, зокрема це брандмауер, який чомусь перешкодив Docker отримати IP-адресу та порт.

Коли я його відключив - все працювало нормально.

Отже, якщо у вас встановлений антивірус, і нічого не допомагає виправити проблему - проблемою може бути брандмауер антивірусу.

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

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

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

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

для мене, використовуючи centos 7.4, це не проблема видачі /etc/resolve.conf, iptables, iptables nat правил, а також самого docker. Проблема полягає у відсутності хоста пакета bridge-utils, якому докер вимагає побудувати міст за допомогою команди brctl. yum встановіть -y bridge-утиліти та перезавантажте докер, вирішіть проблему.