組織として、最初のIPv6割り当てを要求しました。現在、私たちは完全なIPv4組織であり、グローバルIPv4アドレス割り当てがEdgeルーターで構成され、(主に)Edgeファイアウォール経由でNAT)に使用され、プライベートIPv4アドレスで内部的にホストされているWebサーバーに使用されます。
外部向けサービスをIPv6インターネットで利用できるようにする1つの方法は、内部ネットワーク全体にIPv6デュアルスタックを実装し、グローバルにアクセス可能なIPv6アドレス(既存のIPv4アドレスに加えて)をこれらのサーバーに直接割り当てることです。
ただし、IPv6移行テクノロジに関する多くの投稿や記事、およびNATの賛成論と反対論)をIPv6の世界で読んだ後でも、既存のセットを本質的に複製できるかどうかはまだよくわかりませんアップしますが、IPv6アドレスを使用します。つまり、エッジルーターでグローバルにルーティング可能なIPv6インターフェースをファイアウォールの関連するIPv6「外部」インターフェースと単純に1:1 NAT IPv4アドレス?
これは明らかに、ISPとIPv6 BGPピアリングの取り決めがあり、内部アドレッシングのニーズはRFC1918で満たされているが、選択した外部サービスをIPv6でアクセスできるようにしたいという原則に基づいています。
最初のコメントで述べたように、長期的にはNATソリューションを実装するよりも安価であるため、デュアルスタックに移行することを強くお勧めします。(とにかくそれを行う必要がありますが、なぜ今ではないのですか?)
しかし、それでも、あなたの問題については、2つの可能性があります ソリューション/回避策:
はい。
ステートフルNAT64実装が必要になります。通常、これらはローカルIPv6クライアントにパブリックIPv4インターネット上のリソースへのアクセスを提供するために使用されますが、パブリックインターネット上のIPv6クライアントがローカルIPv4リソースにアクセスできるようにするために使用することを妨げるものは何もありません。ファイアウォールを使用して、NAT64ゲートウェイを介してアクセスできるホストを制限できます。
一般的に私はノーと言うでしょう。
このアプローチの主な問題は、トラフィックの送信元IPアドレスに関する情報が失われることです。 128ビットのソースIPを32ビットのフィールドに詰め込む方法はありません。したがって、追跡して悪用を報告することは困難です。
Serveralがあります。優先順位の高いものから順に提示します。
最初のオプションは、サーバーとネットワークエッジ間のネットワークのこれらのセグメントにデュアルスタックを展開することです。これは、ネットワーク全体にIPv6の展開を開始する場合に適しています。
2番目のオプションは、ネットワークエッジから問題のサーバーにつながるトンネルを展開することです。トンネルは、IPv4ネットワークを介してipv6トラフィックをサーバーに送り、サーバーはそれをネイティブに処理できます。
3番目のオプションは、リバースプロキシです。アプリケーションレベルで機能するため、外部IPアドレス情報をアプリケーションレベルのヘッダーにエンコードできます。この情報を利用するには、アプリケーション側の変更が必要になる場合がありますが、他の理由で大規模な展開ではリバースプロキシの設定が非常に一般的であるため、多くのアプリケーションはすでにそれをサポートしています。
IPv6を介してIPv4サービスを利用できるようにするこの方法は非常に一般的です。静的NAT64マッピングを実行できるファイアウォールが必要です。私はJuniper SSGボックスを自分で使ってそれを行いました。
ただし、断片化の問題がいくつかありました。 IPv6ヘッダーはIPv4ヘッダーよりも大きいため、変換によってパケットがわずかに大きくなります。これにより、IPv6パケットが断片化される可能性があり、断片化されたすべてのトラフィックを無視するデバイスを見ました。このようなデバイスが壊れているユーザーの問題を回避するには、IPv4側のMTUを少し減らし(1480または1400が一般的な値です)、変換後でもパケットが1500バイト未満になるようにします。