IPv4枯渇の現実
最近、私は大規模なマイクロサービスクラスターをIPv6専用インフラに移行するプロジェクトを主導しました。プライベートIPv4アドレスの重複管理という煩わしさから解放され、ルーティングテーブルを簡素化したいと考えたのです。理論上、それは完璧なアーキテクチャの転換でした。しかし、本番環境では即座に障害に直面しました。いくつかのレガシーな監視エージェントや独自のサードパーティ製ライブラリが、IPv4をハードコードしていたのです。それらはAAAAレコードを認識できず、128ビットのアドレスを処理することもできませんでした。
このシナリオは、現代のDevOpsにおいてよくある悩みです。IPv6のスケーラビリティが必要である一方で、世界はいまだにレガシーなプロトコルに固執しています.IPv6専用ホストで10年前のバイナリを実行しようとして「Network unreachable（ネットワークに到達できません）」というエラーを見たことがあるなら、そのもどかしさがわかるはずです。
標準的なNAT64だけでは不十分な理由
多くのエンジニアは、まず NAT64とDNS64の組み合わせから始めます。この組み合わせは、WebブラウザやDNSに厳密に依存するアプリケーションではうまく機能します。アプリが api.example.com を要求すると、DNS64がIPv6アドレスを合成し、NAT64が変換を処理します。しかし、アプリケーションの設定に 1.1.1.1 のようなIPがハードコードされている場合、この仕組みは機能しません。また、DNSルックアップを完全にバイパスするカスタムプロトコルでも失敗します。
ローカルインターフェースにIPv4スタックが見つからないため、アプリケーションはクラッシュします。ここで 464XLAT が不可欠になります。これはローカルマシン上に論理的なIPv4インターフェース（CLAT）を提供します。この仮想インターフェースは、アプリケーションに標準的なIPv4ネットワーク上にいると錯覚させ、実際のトランスポートはIPv6ネットワーク上で行われます。
464XLATの仕組み：CLATとPLAT
464XLATは、2つの異なるコンポーネントを使用してギャップを埋めます。
- PLAT (Provider-side Translator): プロバイダーやコアインフラチームによって管理されるNAT64ゲートウェイです。IPv6パケットをパブリックインターネットに到達させるためにIPv4に変換し直します。
- CLAT (Customer-side Translator): Linuxホスト側で設定する部分です。仮想の
clatインターフェースを作成します。アプリがIPv4パケットを送信すると、CLATはそれをIPv6ヘッダーでカプセル化し、PLATにルーティングします。
私は10Gbpsのトラフィックが発生する環境でこの構成をデプロイしましたが、非常に堅牢に動作し続けています。開発者がレガシーコードを1行も書き換えることなく、プロトコルのギャップを解消できるのです。
解決策：TAYGAによるCLATの実装
LinuxでCLATを実装する場合、TAYGA がデファクトスタンダードです。これは非常に軽量なステートレスNAT64デーモンです。TAYGAは余計なことをせず、高速な変換のみに特化しています。
ステップ1：前提条件
ホストに機能するIPv6接続があり、ネットワークのNAT64プレフィックスを把握していることを確認してください。ほとんどのネットワークでは、標準的なウェルノウンプレフィックス 64:ff9b::/96 が使用されます。
# Debian/UbuntuにTAYGAをインストール
sudo apt update
sudo apt install tayga -yステップ2：TAYGAの設定
/etc/tayga.conf を開き、仮想IPv4アドレスとNAT64プレフィックスを定義します。この設定により、TAYGAに2つのアドレス空間のマップ方法を指示します。
# /etc/tayga.confを編集
tun-device nat64
ipv4-addr 192.168.255.1
prefix 64:ff9b::/96
dynamic-pool 192.168.255.0/24この設定では、192.168.255.1 が内部ゲートウェイとして機能します。dynamic-pool は、TAYGAが受信IPv6トラフィックをローカルシステムにマッピングするために使用するローカルIPv4アドレスの範囲を提供します。
ステップ3：インターフェースの初期化
次に、ネットワークインターフェースを作成し、ルーティングを定義します。Linuxカーネルに対し、すべてのIPv4宛てトラフィックをTAYGAインターフェース経由で送信するように指示する必要があります。
# nat64デバイスを作成
sudo tayga --mktun
# インターフェースを起動
sudo ip link set nat64 up
sudo ip addr add 192.168.255.1 dev nat64
# すべてのIPv4トラフィックを変換インターフェース経由に強制
sudo ip route add 0.0.0.0/0 dev nat64ステップ4：デーモンの起動
ここでTAYGAサービスを起動します。サーバーが再起動してもトランスレーターが自動的に再開するように、systemdを使用します。
sudo systemctl enable tayga
sudo systemctl start taygaルーティングとソースIPの処理
ソースアドレスの設定は、初心者にとって混乱を招きやすいポイントです。IPv4パケットが nat64 インターフェースに入ると、TAYGAはそれをIPv6に変換します。新しいIPv6ソースアドレスは、NAT64プレフィックスと内部IPv4アドレスの組み合わせになります。
これを機能させるには、IPフォワーディングを有効にする必要があります。また、ファイアウォール（iptablesまたはnftables）が変換されたトラフィックをブロックしていないことを確認してください。
# IPv6フォワーディングを有効化
sudo sysctl -w net.ipv6.conf.all.forwarding=1
# nat64インターフェースを通過するトラフィックを許可
sudo iptables -A FORWARD -i nat64 -j ACCEPT
sudo iptables -A FORWARD -o nat64 -j ACCEPT変換のテスト
設定を確認するために、パブリックなIPv4専用アドレスにpingを送信します。GoogleのDNS (8.8.8.8) はIPv6をサポートしていますが、ここではIPv4経路のテストを強制するために使用します。
ping -4 8.8.8.8pingが正常に返ってくれば、CLATは機能しています。これで、レガシーアプリケーションは有効なIPv4ルートを認識し、IPv6専用ネットワーク越しに問題なく通信できるようになります。
現場からのベストプラクティス
いくつかのIPv6移行を管理してきた経験から、一般的な落とし穴を避けるための最適化を推奨します。
- MTU問題の修正: IPv6ヘッダーは40バイトですが、IPv4ヘッダーは20バイトです。この20バイトの差により、大きなデータ転送中にパケットがドロップすることがあります。接続がハングする場合は、
nat64インターフェースのMTUを1260に下げてください。 - ログの監視: TAYGAの出力はsyslogに送信されます。接続が切れた場合は、
tail -f /var/log/syslogを実行してください。PLATへの有効なルートが見つからない場合、明確にログに記録されます。 - プレフィックスの確認: プレフィックスが必ず
64:ff9b::/96であると思い込まないでください。一部のエンタープライズネットワークではカスタムプレフィックスを使用しています。常にネットワークチームに確認するか、dig +short amir.ipv6-test.com AAAAを使用してネットワークがどのようにアドレスを合成しているかを確認してください。
最後に
IPv6への移行のために、信頼性の高いレガシーソフトウェアを捨てる必要はありません。464XLATは、インフラを最新の状態に保ちつつ、透過的で高性能なブリッジを提供します。TAYGAをCLATデーモンとして使用することで、プロバイダーからIPv6アドレスしか割り当てられていない場合でも、デュアルスタック環境を維持することが可能です。
