ドッカーホストのJenkinsが、コンテナ内部のHTTP要求に応答するのはなぜですか？

Question

私は、JenkinsとDockerの両方がインストールされているマシンで、かなり独特な動作をしています。明確にするために、JenkinsはDockerコンテナとして実行されていませんが、jenkinsユーザーの下で実行されています。

容器にcurlを実行している場合は、私が手403

：

$ curl -I www.google.co.uk 
HTTP/1.1 200 OK 
Date: Tue, 30 May 2017 13:40:17 GMT 
Expires: -1 
Cache-Control: private, max-age=0 
Content-Type: text/html; charset=ISO-8859-1 
P3P: CP="This is not a P3P policy! See https://www.google.com/support/accounts/answer/151657?hl=en for more info." 
Server: gws 
X-XSS-Protection: 1; mode=block 
X-Frame-Options: SAMEORIGIN 
Set-Cookie: NID=104=mMKjBy002X3N_SkhkD_8xuAwpFuw03CFi0iOJjNX81FUHfMT6qTq95LcgRwdhrV_GZoUF9LQ1B9qAQPriN9Er3Bu2JWoqPgvt16TduuVj5QsNs9GiJTQBtaSXWic7G9E; expires=Wed, 29-Nov-2017 13:40:17 GMT; path=/; domain=.google.co.uk; HttpOnly 
Transfer-Encoding: chunked 
Accept-Ranges: none 
Vary: Accept-Encoding 

ジェンキンスが非難することは明らかであるが、I：ホスト上のコンテナの外

root@ada71c8116bf:/# curl -I www.google.co.uk 
HTTP/1.1 403 Forbidden 
Date: Tue, 30 May 2017 13:41:07 GMT 
X-Content-Type-Options: nosniff 
Set-Cookie: JSESSIONID.f1223778=36hjq9sozhveoe1bfsss1dnq;Path=/;HttpOnly 
Expires: Thu, 01 Jan 1970 00:00:00 GMT 
Content-Type: text/html;charset=UTF-8 
X-Hudson: 1.395 
X-Jenkins: 2.46.3 
X-Jenkins-Session: 2836b130 
X-You-Are-Authenticated-As: anonymous 
X-You-Are-In-Group-Disabled: JENKINS-39402: use -Dhudson.security.AccessDeniedException2.REPORT_GROUP_HEADERS=true or use /whoAmI to diagnose 
X-Required-Permission: hudson.model.Hudson.Read 
X-Permission-Implied-By: hudson.security.Permission.GenericRead 
X-Permission-Implied-By: hudson.model.Hudson.Administer 
Content-Length: 793 
Server: Jetty(9.2.z-SNAPSHOT) 

は、私が期待される応答を取得しますなぜコンテナから出るHTTPトラフィックを傍受するのか分かりません。 Googleに正常に動作しているため、HTTPS要求を送信しています。この問題は他のマシンにはありません（Jenkinsがインストールされていない可能性が高いためです）。それで、ここで何が起こっているのですか？ DockerコンテナからHTTPをインターセプトすることを止めるためにJenkinsを取得するにはどうすればよいですか？オプションジェンキンス 『を防ぐクロスサイトリクエストフォージェリのエクスプロイトを』オフに更新

はもはや403sを返さないようにジェンキンスの原因となります。代わりに、Jenkinsはコンテナ内の任意のHTTP要求にダッシュボードページ（デフォルトページ）で応答します。

また、DNSはうまく動作します。ホスト名は正しいIPアドレスに解決されます。

私はWiresharkを出すつもりです。

Answer 1

Wiresharkを使用すると、HTTPトラフィックをホスト上のポート8090にリダイレクトしていることがわかりました。幸運なgoogleは私にホストのIPテーブル（iptables -t nat -L -n）をチェックさせてくれました。そして、すべてのポート80トラフィックをどこからでもからポート8090にリダイレクトするルールが十分にあることを確信しました。誰かがJenkinsユーザーの利益のためにこのリダイレクトを明確に設定しました。

解決策は、ドッキング・サブネットからのトラフィックをリダイレクトしないようにIPテーブルを変更することでした。

のテーブルの前に：

$ sudo iptables -t nat -L -n 
Chain PREROUTING (policy ACCEPT) 
target  prot opt source    destination    
REDIRECT tcp -- 0.0.0.0/0   0.0.0.0/0   tcp dpt:80 redir ports 8090 
DOCKER  all -- 0.0.0.0/0   0.0.0.0/0   ADDRTYPE match dst-type LOCAL 

Chain INPUT (policy ACCEPT) 
target  prot opt source    destination   

Chain OUTPUT (policy ACCEPT) 
target  prot opt source    destination   
REDIRECT tcp -- 0.0.0.0/0   127.0.0.1   tcp dpt:80 redir ports 8090 
DOCKER  all -- 0.0.0.0/0   !127.0.0.0/8   ADDRTYPE match dst-type LOCAL 

Chain POSTROUTING (policy ACCEPT) 
target  prot opt source    destination   
MASQUERADE all -- 172.17.0.0/16  0.0.0.0/0   

Chain DOCKER (2 references) 
target  prot opt source    destination   
RETURN  all -- 0.0.0.0/0   0.0.0.0/0 

はコマンド変更するには：

$ sudo iptables -t nat -R PREROUTING 1 ! -s 172.17.0.0/16 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8090 
$ sudo iptables -t nat -R OUTPUT 1 ! -s 172.17.0.0/16 -d 127.0.0.1/32 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 8090 

結果のIPテーブル：

$ sudo iptables -t nat -L -n 
Chain PREROUTING (policy ACCEPT) 
target  prot opt source    destination   
REDIRECT tcp -- !172.17.0.0/16  0.0.0.0/0   tcp dpt:80 redir ports 8090 
DOCKER  all -- 0.0.0.0/0   0.0.0.0/0   ADDRTYPE match dst-type LOCAL 

Chain INPUT (policy ACCEPT) 
target  prot opt source    destination   

Chain OUTPUT (policy ACCEPT) 
target  prot opt source    destination   
REDIRECT tcp -- !172.17.0.0/16  127.0.0.1   tcp dpt:80 redir ports 8090 
DOCKER  all -- 0.0.0.0/0   !127.0.0.0/8   ADDRTYPE match dst-type LOCAL 

Chain POSTROUTING (policy ACCEPT) 
target  prot opt source    destination   
MASQUERADE all -- 172.17.0.0/16  0.0.0.0/0   

Chain DOCKER (2 references) 
target  prot opt source    destination   
RETURN  all -- 0.0.0.0/0   0.0.0.0/0