ユーザー空間プロキシが無効になっている場合、コンテナからホストポートにアクセスする

Question

問題を再現できません。

2つのDockerブリッジネットワークを定義しました。

eecf335e7600   net1                   bridge    local
5c7ca74637b0   net2                   bridge    local

c1ネットワークからコンテナを起動し、net1コンテナポートを8080ホストポートに公開します8081。

$ docker run -d --rm --net net1 -p 8081:8080 --name c1 \
  --add-host host.docker.local:host-gateway  alpinelinux/darkhttpd

c2ネットワークからコンテナを起動し、net2コンテナポートを8080ホストポートに公開します8082。

$ docker run -d --rm --net net2 -p 8082:8080 --name c2 \
  --add-host host.docker.local:host-gateway  alpinelinux/darkhttpd

これで、コンテナ内のc1ホストポートにアクセスしてコンテナのWebサービスにアクセスできるようになりました。c28082

$ docker exec c1 wget -O- http://host.docker.local:8082
Connecting to host.docker.local:8082 (172.17.0.1:8082)
writing to stdout
-                    100% |********************************|   191  0:00:00 ETA
written to stdout
<html>
<head>
...

コンテナからc2ホストポートにアクセスして、コンテナのWebサービスにアクセスできます。c18081

$ docker exec c2 wget -O- http://host.docker.local:8081
Connecting to host.docker.local:8081 (172.17.0.1:8081)
writing to stdout
-                    100% |********************************|   191  0:00:00 ETA
written to stdout
<html>
<head>
...

すべてが宣伝されたとおりに動作しているようです。同じ手順を繰り返しても結果が異なる場合は、最初に確認する必要があるのは、ホストにトラフィックを妨げるファイアウォールルールがあることを確認することです。

修正する

--add-host期待どおりにそのオプションを使用する代わりに、ホストアドレスのみを選択しても動作は同じです。たとえば、次のような場合があります。

$ ip -o addr |grep -o '.*inet [^ ]*'
1: lo    inet 127.0.0.1/8
2: eth0    inet 192.168.123.106/24
4: docker_gwbridge    inet 172.23.0.1/16
8: br-70f125dc5b7d    inet 192.168.208.1/20
15: br-a87cc1462629    inet 172.29.0.1/16
18: docker0    inet 172.17.0.1/16
35: br-eecf335e7600    inet 172.18.0.1/16
36: br-5c7ca74637b0    inet 172.19.0.1/16

その後、これらはすべて機能します。

$ docker exec c2 wget -O- 192.168.123.106:8081 | head -3
Connecting to 192.168.123.106:8081 (192.168.123.106:8081)
writing to stdout
-                    100% |********************************|   191  0:00:00 ETA
written to stdout
<html>
<head>
 <title>/</title>
$ docker exec c2 wget -O- 172.29.0.1:8081 | head -3
Connecting to 172.29.0.1:8081 (172.29.0.1:8081)
writing to stdout
-                    100% |********************************|   191  0:00:00 ETA
written to stdout
<html>
<head>
 <title>/</title>
$ docker exec c2 wget -O- 172.18.0.1:8081 | head -3
Connecting to 172.18.0.1:8081 (172.18.0.1:8081)
writing to stdout
-                    100% |********************************|   191  0:00:00 ETA
written to stdout
<html>
<head>
 <title>/</title>

など。

無効にする前にこの問題があったことは確実であるため、質問には言及していません。

これはデフォルト設定と比較してかなり大きな設定変更です。 :)

ユーザーレイヤープロキシを無効にすると、すべてが機能しなくなります。

この記事興味があるかもしれないもの：

前のセクションでは、Dockerがiptables NATルールを使用して公開されたポートをコンテナサービスにマップできない2つのシナリオを特定しました。

別のDockerネットワークに接続されているコンテナがサービスにアクセスしようとしたとき（DockerがDockerネットワーク間の直接通信をブロックしている場合）

ローカルプロセスがループバックインターフェイスを介してサービスにアクセスしようとした場合。

どちらの場合も、Dockerはユーザーレベル（Linuxプロセス）TCPまたはUDPプロキシを使用します。公開されたポートでコンテナを起動したら、netstatコマンドを使用してプロキシを簡単に識別できます（標準のFlaskアプリケーションを再利用します）。

Answer 1