ホスト上のiptables 443リダイレクトが、Dockerコンテナからの送信HTTPS要求を妨害する可能性がありますか？

Question

私は最近、Dockerとiptablesという非常に複雑な問題を診断しました。

私は、次の iptables設定でUbuntuのホストを持っている：

$ sudo iptables -L -t nat 
[...] 
Chain xyz (1 references) 
target  prot opt source    destination   
REDIRECT tcp -- anywhere    anywhere    tcp dpt:https /* xyz */ redir ports 8443 

ルールは8443にポート443からのすべての着信トラフィックをリダイレクトする場所では、Javaベースのアプリケーションにトラフィックをリダイレクトするように意図されている

私のDockerコンテナとは無関係ですが、同じマシン上で動作し、自己署名入りのSSL証明書を持っています。

Dockerの既定のネットワーク設定を使用して同じマシン上でDockerコンテナを実行し、コンテナ内からwget HTTPS要求を発行すると、Docker（またはOS）がUbuntuのポート8443への送信接続をリダイレクトしているようですホスト、そしてローカルのJavaベースのアプリケーションに接続し、接続は（ほとんどの場合）接続を受け付け、無効な（自己署名された）証明書の詳細を返します。その結果、コンテナ内のアプリケーションは、インターネット上の実際のサーバーと通信する必要がなく、ホスト上のこのローカルJavaアプリケーションと通信することになります。

また、Ubuntuホストから直接発行されたwget HTTPSリクエストがインターネット上のターゲットサーバにヒットすることも確認しました。この問題は、同じホスト上で実行されているDockerコンテナによって開始された要求でのみ発生します。

これはなぜ起こるのか説明できますか？

Answer 1

この例は完全ではありません。このチェーンがどこからリンクされているかはわかりません。私はとにかく答えるつもりですが、IPtablesのルールを、問題を再現するだけのものにすることをお勧めします。

iptablesの仕組みは、入ってくるパケットにマッチしたルールが適用されていることです。それに一致するルールは、そのターゲットが適用されます。

あなたのケースでは、アウトバウンドパケットがこのルールで照合されるため、リダイレクトされる可能性があります。

REDIRECTターゲットはルーティング前のテーブルにあり、着信トラフィックに限定されないため、何らかの方法で一致を制限する必要があります。最も簡単なのはおそらく、! -i loをルールに追加することです。これにより、ループバックインターフェイスを介して到着するパケットの照合が防止されます。