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

Мой сценарий: я хотел бы, чтобы мои сервисы на базе Docker знали, какой IP обращается к ним из интернета (это требование моего приложения).

Я работаю на облачном VPS, debian jessie, с docker 1.12.2.

Я использую nc в режиме подробного вывода для открытия порта 8080.

docker run --rm -p "8080:8080" centos bash -c "yum install -y nc && nc -vv -kl -p 8080"

Скажем, у VPS есть домен example.com, и с другой машины, у которой, допустим, есть IP dead:::::beef, я выполняю команду

nc example.com 8080

Сервер говорит:

Ncat: Version 6.40 ( http://nmap.org/ncat )
Ncat: Listening on :::8080
Ncat: Listening on 0.0.0.0:8080
Ncat: Connection from 172.17.0.1.
Ncat: Connection from 172.17.0.1:49799.

172.17.0.1 находится в локальной сети сервера и, конечно, не имеет отношения к моему клиенту. На самом деле:

docker0   Link encap:Ethernet  HWaddr ....
          inet addr:172.17.0.1  Bcast:0.0.0.0  Mask:255.255.0.0

Если я запускаю контейнер в режиме сетевого взаимодействия хоста

docker run --rm --net=host -p "8080:8080" centos bash -c "yum install -y nc && nc -vv -kl -p 8080"

и снова обращаюсь к своему серверу

nc example.com 8080

Я получаю ожидаемый результат:

Ncat: Connection from dead:::::beef.
Ncat: Connection from dead:::::beef:55650.

Мои вопросы:

• Почему docker “маскирует” IP-адреса, когда не находится в режиме сетевого взаимодействия хоста? Я думаю, что процесс демона docker, вероятно, именно тот, кто открывает порт, получает соединение, а затем передает его процессу контейнера, используя собственное внутреннее соединение сетевого интерфейса. nc, работающий в контейнере, таким образом видит, что вызов поступает с IP демона docker.
• (Как) могу ли я сделать так, чтобы мой сервис docker знал о внешних IP, обращающихся к нему, без использования режима сетевого взаимодействия хоста?

Согласно документации, драйвер по умолчанию (т.е., когда вы не указываете --net=host в docker run, это драйвер сетевого взаимодействия bridge.

Дело не в том, что docker “маскирует” IP-адреса, а в том, как режимы сетевого взаимодействия bridge и host отличаются.

В контексте Docker, сетевая сеть bridge использует программный мост, который
позволяет контейнерам, подключенным к одной и той же сетевой сети bridge, общаться
между собой, обеспечивая изоляцию от контейнеров, которые не подключены
к этой сетевой сети bridge. Драйвер моста Docker автоматически устанавливает
правила на хост-машине, чтобы контейнеры на разных сетевых сетях bridge не могли
напрямую общаться друг с другом.

Docker создает изолированную сеть, чтобы каждый контейнер в сетевой сети bridge мог общаться. В вашем случае это docker0. Таким образом, по умолчанию контейнеры на вашем хосте docker общаются в этой сети.

Как вы, вероятно, уже догадались, да, 172.17.0.1 является маршрутом по умолчанию в сети docker0, но это не действует как маршрутизатор, пересылающий пакеты до места назначения, поэтому вы видите его в качестве источника в выводе netcat.

На самом деле, вы можете проверить это, запустив ss -tulnp на вашем хосте docker. Вы должны увидеть, что процесс, прослушивающий порт 8080, это docker.

С другой стороны, использование драйвера сетевого взаимодействия хоста означает, что нет изоляции между контейнером и хостом. Вы можете проверить это, запустив ss -tulnp на вашем хосте docker; вы должны увидеть, что процесс, прослушивающий сокет, вместо Docker (в вашем случае это должен быть nc).

У меня была точно такая же проблема, и это решение от @TosoBoso хорошо сработало для меня с обратным прокси Nginx перед моим веб-бэкендом. Документ Echo документ также помог мне лучше понять эту проблему.

В основном вам нужно переписать заголовки (по крайней мере, вам нужен X-Real-IP) в вашей конфигурации Nginx, и затем вы сможете перехватить это позже в своей программе.

    location /api/ {
      proxy_pass http://127.0.0.1:7006/api/;
      proxy_set_header Host $http_host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
    }

Для пользователей Caddy вам нужна всего одна строка

header_up X-Real-IP {remote_host}