DockerでのIPv6サポートに関する小さなテキストと、Dockerネットワーキングのニュアンスがいくつかあります。

IPv4

ウォームアップするには、通常のIPv4専用システムを検討してください。 ホストマシンにはeth0



インターフェイスがあります。 外部IPアドレスがこのインターフェイスにバインドされています。 ループバックインターフェイスもあります。 そのようなマシンにdockerをインストールすると、 bridge



というデフォルトのネットワークが作成されます。 このネットワークでは、別のdocker0



インターフェイスがホストマシン上に作成されます。 また、 172.17.0.1



などのIPアドレスも持っています。 コンテナを起動すると、Dockerは選択されたネットワーク（デフォルトではbridge



）からコンテナアドレスを割り当てます。 たとえば、 172.17.0.5



。 コンテナ内に、 eth0



インターフェイスが表示され、アドレス172.17.0.5



そこにあります。 したがって、アドレスは基本的に整理されます。 ここで、コンテナ内のプロセスが外部リソースにアクセスする方法と、コンテナの外に出ることを可能にする方法を理解してみましょう。 コンテナ内のプロセスがネットワークを介して外部インターネットにアクセスする場合、アドレス、ルート設定、構成済みのDNSリゾルバーが必要です。 すでにアドレスがあり、ルートはdockerによって自動的に（内部eth0



直接、次にiptablesを介して）ルーティングされ、DNS dockerは/etc/resolv.conf



ファイルからホストマシンを配置します（同時に、localhostにつながる行がそこから削除されます）理由）。 DNSには注意が1つあります。デフォルトのネットワークを使用せず、docker network createコマンドで独自のネットワークを作成した場合、このネットワークでコンテナーを起動すると、別のDNSサーバー127.0.0.11



が/etc/resolv.conf



追加されます。 この特別なDNSサーバーは組み込みDNSサーバーと呼ばれ、エントリポイントコンテナで手動で削除する場合を除き、いかなる方法でも無効にすることはできません。 この機能は、IPv4のみの環境での作業にはほとんど影響しませんが、IPv6では問題になる可能性があります。 IPv6について説明するときに、これに戻りましょう。 そのため、トラフィックが外部ネットワークに正常に到達するためのすべてが揃っています。 コンテナ内のプロセスが何らかのポートをリッスンし、外部からアクセスできるようにする場合は、指定されたインターフェイスをリッスンするようにプロセスを構成し、-pフラグでコンテナを開始する必要があります。 この場合、ドッカーはホストマシン上で別のドッカープロキシプロセス（いわゆるユーザーランドプロキシ）を起動し、ホストマシンのすべてのインターフェイスにバインドし、指定されたコンテナーにトラフィックをプロキシします。

ちなみに、コンテナに指定されたアドレスは、他のコンテナから直接利用できます（エキゾチックなトポロジが考慮されない限り）。 たとえば、1つのコンテナのアドレスが172.17.0.5



で、ポート80でリッスンしている場合、ホストマシンと他のコンテナの両方からこのアドレスでアクセスできます。 -p 80:80



フラグを指定してコンテナを実行する必要はありません。 このフラグは、ホストマシンの外部インターフェイスでポートにアクセスできるようにすることを目的としています。

IPv6

ここで、アプリケーションにIPv6ホストへのアクセス方法を教える必要があると想像してください。 ホストマシンが、eth0のIPv4アドレスに加えて、IPv6アドレスを受信したと仮定します（グローバルにルーティング可能なリンクローカルアドレスはカウントされません）。 また、IPv4-DNSサーバーの代わりに、IPv6サーバーがあります（AAAA要求に応答できるIPv4経由でアクセス可能なDNSサーバーがあるのは奇妙です）。 コンテナにもIPv6を使用できるようにするには、次のものが必要です。

1. コンテナのIPv6アドレスを配布する方法を選択します
2. カスタムネットワークを作成するか、デフォルトのブリッジネットワークを構成します
3. /etc/resolv.conf
   
   
   
   コンテナに登録されているDNSサーバーがAAAA要求に応答できることを確認します

DNSは最後の手段です。最初にIPアドレスにアクセスする方法を学習し、次にDNSサポートを追加する必要があるためです。

基本的に、IPアドレスを配布するための次のオプションがあります（ --net=host



を除く、これは考慮しません。すべてがそこで機能するはずです）。

1）サイズ/ 80以上のプロバイダーからの実際のサブネット

プロバイダーが実際の/ 64サブネット（または少なくとも/ 80）を提供する場合、これが最も簡単なオプションです。 ほとんどの場合、-- --ipv6 --fixed-cidr-v6={{ }}



オプション--ipv6 --fixed-cidr-v6={{ }}



を構成に追加した直後にすべてが機能します。 それでもいくつかのsysctlオプションをインストールする必要があるかもしれません：

 net.ipv6.conf.all.forwarding=1 net.ipv6.conf.default.forwarding=1 net.ipv6.conf.eth0.accept_ra=2
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2）NDPプロキシ

十分な大きさのサブネットがなく、たとえば16個のアドレス（/ 124）のみの場合、NDPプロキシを使用できます。 この場合、コンテナーは独自にアドレスを指定する必要があります（カスタムネットワークを明示的に使用するか、デフォルトで暗黙的に、ドッカーがMACアドレスに基づいて予想どおりにアドレスを提供するという事実を使用し、MACアドレスは手動で指定できます）。 また、このような各アドレスをネイバーリストに追加し、いくつかのカーネルフラグを有効にする必要があります。 このオプションは、手作業が大量にあるため不便です。 このメソッドの詳細については、 ドキュメントを参照してください 。

3）IPv6 NAT

プロバイダーが1つのアドレスのみを割り当てる場合（またはNDPを台無しにしたくない場合）、NATを使用して構成できます。 この場合、任意のULAサブネット（ https://en.wikipedia.org/wiki/Unique_local_address）（IPv4の10.0.0.0/8



アナログ）を使用して、ip6tablesをサブネットとして構成できます。 親切な人がコンテナーを作成しました（ https://github.com/robbertkl/docker-ipv6nat ）。これは実行するのが非常に簡単で、動作します：新しいコンテナーを作成するときにip6tablesルールを自動的に編集します。 この場合、プロバイダー（またはIaaS）の動作に依存しないため、別のサービスプロバイダーに切り替えるリスクが軽減されるため、原則としてこのオプションが望ましいようです。 このモードでIPv6を機能させるには、構成にサブネットを登録する（または独自の新しいネットワークを追加する）だけで、小さなコンテナーを開始するだけです。 彼は残りを行います。

次に、選択した方法でネットワークを構成し、組み立てられた回路の操作性を確認する必要があります。

DNS

したがって、DNSを検討する必要があります。 デフォルトのネットワークを使用することに決めた場合、DNSに問題はないはずです。 しかし、カスタムネットワークを使用した場合、1つの機能があります。 実際には、Dockerがカスタムネットワークにコンテナーを作成するとき、Dockerは常に独自の組み込みDNSサーバーを追加します。 127.0.0.11



覚えていますか？ また、彼はipv6のみのドメインを解決できません。 これはおそらくバグです。 そして冗談は、それをオフにすることはできないということです！ それを取り除く唯一の方法は、アプリケーションを起動する前に手でresolv.confから行をルート化することです：

 RESOLV_CONF=$(sed 's/nameserver 127.0.0.11//g' /etc/resolv.conf) echo "$RESOLV_CONF" > /etc/resolv.conf
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

（インプレースオプションはここでは意図的に使用されていませんsed -i



でも同じことを試してください。理由は理解できます）

その後、コンテナはドメイン名を再び正常に解決できます。 構成はホストマシンからコピーされます。

次に、外部からの接続用にポートを開きたい場合、アプリケーションが不正に作成され、ipv6をサポートしていない場合の対処方法を確認する必要があります。

ポートが開く

すべて（ホストマシンとdockerの両方）がIPv4のみである場合、問題はありません。 アプリケーションだけが0.0.0.0にバインドできるはずです。 アプリケーションがローカルホストでのみリッスンできる場合、同じコンテナで実行されているカスタムtcpプロキシのみが保存します。 彼女はすべてのインターフェイスでリッスンし、データをローカルホストにブロードキャストします。 socatはこのタスクに非常に適しているはずです。

IPv6を扱っている場合、理想的には、プログラムがリッスンソケットを作成し、 SO_IPV6_ONLY



フラグなしで::



にバインドする必要があります。 このようなソケットは::



と0.0.0.0



両方を同時にリッスンします。 さらに、それはすべて多くの要因に依存します：

• ホストマシンにデュアルスタックがありますか、それともIPv6のみですか
• ユーザーランドプロキシが起動するか、フラグ--userland-proxy=false
  
  
  
  デーモンを実行するか
• 選択されているIPv6サポートメカニズム：実/ 64サブネット、NDPプロキシ、IPv6 NAT、またはその他のカスタムトポロジ

原則として、デュアルスタックとIPv6専用スタックの間に大きな違いはありません。 内部では、ドッカーはIPv4を基礎として使用し、IPv6を追加としてのみ考慮するため、デュアルスタックが引き続き存在します。 さらに行う必要があるのは、両方のプロトコルでポートに外部からアクセスできることを確認することだけです。

ユーザーランドプロキシはもう少し複雑です。 最初に、デフォルト設定を使用する（ユーザーランドプロキシが有効になっている）か、完全に無効にするかを決定する必要があります。 実際、ポートの公開および転送トラフィックを完全にiptablesで構成できる場合、なぜ必要なのですか？ そして確かに、そのような機会があります。 --userland-proxy=false



オプションを--userland-proxy=false



engine構成に追加できます。 しかし、いくつかのニュアンスがあります。 まず、iptablesを使用して、現在開いているポートを上書きできます。 たとえば、一部のアプリケーションがポート80でリッスンしていた場合、Dockerが来て、このポートのパケットをコンテナに転送するルールを追加するように要求しました。 ファイアウォールは「OK」と応答し、その後、トラフィックは最初のアプリケーションへの着信を停止しました。 この状況でdocker-proxyは起動しないだけで、ポートがビジーであることを通知します。 また、iptablesは、ループバックインターフェイスからのトラフィックの転送を許可しません。つまり、ホストマシンのアドレス127.0.0.1および:: 1で、コンテナは使用できません。 最初のケースでは、おそらくチェックを実行できますが、原則としてローカルホストはあまり必要ありません。 しかし、最大の問題は、-- --userland-proxy=false



がまだ本番に対応していないことです。 ここでは、このオプションを有効にすると深刻な問題が発生する方法について説明します。 そして、どうやら、近い将来、これは修正されそうにない。 そのため、ユーザーランドプロキシを使用すると追加のメモリ消費が発生する場合でも、現時点ではユーザーランドプロキシをオフにしないことをお勧めします。

デュアルスタックでユーザーランドプロキシを使用すると、すべてのインターフェイスのポートでリッスンしますが、トラフィックを1つのIPアドレスのみに転送できることを覚えておく必要があります（バランサーではありません）。 コンテナにIPv4とIPv6の2つがある場合、どちらが選択されますか？ ソースでは、IPアドレスが選択されていることがわかります。

https://github.com/docker/libnetwork/blob/master/portmapper/mapper.go#L96

しかし、実際に選択されるのはどれですか？ 実験により、IPv4アドレスが常に選択されることが判明しました。 正確な答えを得るには、コードを調べる必要があります

https://github.com/docker/libnetwork/blob/master/drivers/bridge/bridge.go

いずれにせよ（基本的な推奨事項に戻る）、理想的には、すべてのインターフェイスをリッスンするようにアプリケーションに教える必要があります。 それ以外の場合、リスクがあります。 たとえば、IPv6 NAT +ユーザーランドプロキシが使用されている場合、アプリケーションはIPv4のみをリッスンし、ホストマシンにはデュアルスタックがあり、IPv4を介して外部から接続しようとするとすべてが正常になりますが、IPv6では機能しません。 なんで？ 着信IPv4パケットはdocker-proxyを介してコンテナのIPv4アドレスにプロキシされ、IPv6パケットはIPv6 NATによって作成されたip6tablesルールを使用してコンテナのIPv6アドレスに変換されるためです。 つまり、IPv4接続は合法的にユーザーランドプロキシを通過し、IPv6トラフィックは直接コンテナーに到達します！ これは、 python -m SimpleHTTPServer 8000



といくつかのnc6 -6 -l -p 8000 --continuous --exec cat



を同時にコンテナーで実行することで簡単に確認できます。 2つのプロセスは同じポートでリッスンしますが、異なるIPにバインドされます：「0.0.0.0」と「::」。 telnetはそれらとは独立して動作します。IPv6はIPv6、IPv4はIPv4につながります。 その後、このコンテナを提供するドッカープロキシプロセスを見つけて強制終了すると、IPv4接続は受け入れられなくなり、IPv6は何も起こらなかったように動作し続けます。

おわりに

1. IPv6 NATを使用します。 速くて便利で、リスクが最も少ないです。
2. アプリがすべてのインターフェイスでリッスンするようにします。 これにより、最小限のリスクでポートが開かれ、何かが機能していないことがわかります。
3. カスタムネットワーク（docker network create）を使用している場合は、スタートアップスクリプトにコードを追加して、組み込みDNSサーバーを/etc/resolv.confから削除します。 これにより、AAAA専用ドメインと連絡を取り合うことができます。
4. ユーザーランドプロキシを拒否しないでください。 広範囲のポートが必要な場合は、 --net=host
   
   
   
   を使用することをお--net=host
   
   
   
   

一般に、DockerでのIPv6サポートは完全に準備が整っているようには見えません。 ただし、かなり許容できる程度の生存を可能にする開発がすでにあります。 したがって、新しい時代が間近に迫っています。