IPv4中心の世界における高コストな現状
IPv4アドレスは単に不足しているだけでなく、非常に高価になっています。主要なクラウドプロバイダーがパブリックIPv4アドレス1つにつき月額3.50ドルから5.00ドル程度を課金するようになった現在、20個の小さなマイクロサービスを運用するだけで、IPアドレスのためだけに年間1,000ドル以上の追加コストが発生する可能性があります。内部環境をIPv6専用に移行することは、単なる技術的な挑戦ではなく、賢明な財務戦略と言えます。
私は数百万件のリクエストを処理する本番環境でこの構成を導入してきましたが、非常に安定しています。カーネルレベルのNAT64実装であるJoolとBIND9を組み合わせることで、透過的なゲートウェイを作成できます。これにより、IPv6専用サーバーは翻訳が行われていることを意識することなく、IPv4専用のAPI、アップデートリポジトリ、サードパーティサービスにアクセスできるようになります。
最適な翻訳手法を選択する
すべてのNAT64ツールが同じように作られているわけではありません。コマンドをコピー＆ペーストする前に、自身のアーキテクチャにどの翻訳方式が適しているかを判断する必要があります。
ステートレスNAT64とステートフルNAT64
ステートレスNAT64 (SIIT)は、シンプルな1対1のマッピングです。すべてのIPv6アドレスに専用のIPv4アドレスが割り当てられます。速度は非常に速いものの、アドレスの節約という観点ではあまり意味がありません。デュアルスタック構成と同じ速さでIPv4アドレスを消費してしまうからです。
ステートフルNAT64こそが、多くの場合に必要とされるものです。これは家庭用ルーターの従来のNAT (NAPT) と同じように機能します。1つのパブリックIPv4アドレスを、500台の内部IPv6サーバーで共有することが可能です。ゲートウェイは状態テーブル（ステートテーブル）を使用して接続を追跡します。JoolはこれをLinuxカーネル内部で処理するため、TAYGAのようなユーザ空間ツールのコンテキストスイッチによるオーバーヘッドを回避でき、レイテンシの増加を1ms未満に抑えることができます。
DNS64が橋渡しをする仕組み
NAT64がエンジンなら、DNS64はナビゲーターです。サーバーがlegacy-api.comにアクセスしようとすると、AAAAレコードを要求します。そのAPIがIPv4のみをサポートしている場合、DNS64サーバーはIPv4アドレス（例：93.184.216.34）を取得し、それを特別なプレフィックス（通常は64:ff9b::/96）でラップします。サーバーはその合成されたIPv6アドレスにパケットを送信し、Joolがプレフィックスを取り除いてIPv4インターネットへ送り出すという重労働を担います。
トレードオフ：本番環境で使えるか？
ネットワークにおいて「無料」のものはありません。移行する前に、現場での経験に基づいた以下のメリットとデメリットを検討してください。
- メリット:
- IPv4の節約: 数個のIPv4アドレスだけでデータセンター全体を運用できます。
- 管理の簡素化: プライベートIPv4サブネットの重複に悩まされることがなくなります（10.0.0.0/8の枯渇は現実の問題です）。ファイアウォールルールも1つのセットを管理するだけで済みます。
- 将来への対応: すでに「未来」の環境で運用していることになります。サービスが完全にIPv6に移行した際、何も変更する必要がありません。
- デメリット:
- ボトルネックのリスク: NAT64ゲートウェイが単一障害点（SPOF）となります。ゲートウェイがダウンすると、クラスター全体がオフラインになります。KeepalivedやVRRPによる高可用性（HA）構成が不可欠です。
- ペイロードの問題: FTPやSIPのような古いプロトコルの一部は、データパケット内にIPアドレスを埋め込みます。これらは特定のヘルパーがないと正常に動作しません。
- ロギング: 送信先のIPv4ウェブサーバーのログには、個別の内部サーバーではなく、ゲートウェイのIPアドレスのみが記録されます。
導入ガイド
ゲートウェイには専用のUbuntu 24.04インスタンスを使用することをお勧めします。パブリックIPv4アドレスと、ルーティングされたIPv6プレフィックスが必要です。
1. 必須パッケージのインストール
Joolはカーネル内で動作するため、OSのカーネルがアップデートされた際にも追従できるようDKMSが必要です。
sudo apt update
sudo apt install -y dkms make gcc linux-headers-$(uname -r) bind9 jool-dkms jool-toolsモジュールが有効であることを確認します：
sudo modprobe jool
lsmod | grep jool2. DNS64 (BIND9) の設定
AAAAレコードを合成してクライアントに対して「応答」するようにBINDを設定する必要があります。/etc/bind/named.conf.optionsを編集します：
options {
directory "/var/cache/bind";
recursion yes;
allow-query { any; };
# ここでDNS64の設定を行います
dns64 64:ff9b::/96 {
clients { any; };
};
dnssec-validation auto;
listen-on-v6 { any; };
};サービスを再起動します：sudo systemctl restart bind9
3. NAT64エンジンの起動
まず、パケットがインターフェース間を移動できるように、カーネルでフォワーディングを有効にします。
sudo sysctl -w net.ipv6.conf.all.forwarding=1
sudo sysctl -w net.ipv4.conf.all.forwarding=1次に、Joolに対して監視するプレフィックスと、外部との通信に使用するIPv4アドレスを指定します。1.2.3.4を実際のパブリックIPに置き換えてください。
# インスタンスの作成
sudo jool instance add "default" --netfilter --pool6 64:ff9b::/96
# パブリックIPへのマッピング
sudo jool pool4 add "default" 1.2.3.4 --udp --tcp --icmp4. 動作確認
IPv6専用クライアントに移動します。DNSの設定をゲートウェイのIPv6アドレスに向くように更新し、IPv4専用の宛先にアクセスを試みてみましょう：
# NAT64プレフィックス経由でGoogleのDNSにpingを送信
ping 64:ff9b::8.8.8.8
# DNS64の合成をテスト
curl -I http://ipv4only.arpa200 OKが返ってくれば、レガシーなインターネットへのトンネリングに成功しています。IPv6専用サーバーがIPv4専用リポジトリからフルスピードでアップデートを取得する様子を見るのは、非常に素晴らしい気分です。
結論
再起動時にこれらの設定が消えないように注意してください。joolコマンドをsystemdユニットにまとめるか、/etc/jool/jool.confを使用することを確認してください。IPv6専用アーキテクチャへの移行は、単にモダンであることだけではありません。それは、ビジネスの成長に合わせてコストを抑えつつ、よりスリムで安価、そして拡張性の高いインフラを構築することを意味します。
