NAT64/DNS64～作ってみた/使ってみた～

先日、NAT64およびDNS64技術について当ブログにて紹介させていただきました。その後行った環境の整備や、あるイベント向けにNAT64環境の構築を行った際に、幾つかの構築上の留意点がありました。皆様がNAT64の利用環境を構築される際にご参考としていただければと考え、今回ご紹介させていただきます。

■端末の動作関係

1．Android端末向けのIPv6アドレス自動設定には、RAでのDNSアドレスの配布が必要でした。

当記事執筆時点のAndroid端末はDHCPv6に対応しておらず、IPv6のDNSアドレスを配布するには、RAでDNSアドレスを配布する RDNSSオプションの設定が必要でした。（OS 5.02などの複数の端末で確認。）

しかしながら、手元で利用可能な機器ではRDNSSオプションが発行できるものがなく、安価なブロードバンドルータなどで対応しているものも見つけることができませんでした。物理的に持ち運びが可能な環境としたかったため、今回はPCを利用して仮想ルータを構築しました。仮想ルータにはvyosのversion 1.1.7を利用しています。

PCには仮想環境で利用できるポートが1つしかなかったため、別途3ポートのスイッチを別途用意し、Tag VLANでuplinkとWi-Fi APへの接続構成を構築しています。

vyosでVLANを設定するとパケットにタグを付与する設定となるため、vSwitchではタグをすべて受け入れるようトランクモードに設定する必要があります。

また、NAT64のユーザ環境にはIPv6しか与え無いため、この仮想ルータのホストを管理するためにGUIが操作可能な作業用PCがIPv6を持っていなければならず、設置にひと手間かかるなどのトラブルもありました。

2．Windows10はRDNSSオプションでDNSの自動設定はできませんでした。

IPv6のDNSの配布にRDNSSオプションだけを設定した環境では、Windows 10はIPv6のDNSアドレスを取ることができませんでした。そのため、DHCPv6を構築しました。

vyosのversion 1.1.7のDHCPv6機能では、アドレス配布時には問題が無いのですが、なぜかDHCPv6 informのapplyにはDNSv6のアドレスが入らなかったため、外部にISC DHCPv6サーバを構築し、vyosはリレーエージェントとして利用しました。vyosには複数VLANを作ることができ、RAパラメータもそれぞれ柔軟に変更できます。そのため、Wi-Fi AP側でVLAN別に複数のSSIDを送信できるよう構築することで、複数の要件の試験環境を構築するのに便利です。現在の環境では、RAのパラメータはmフラグを無効、oフラグを有効とし、RDNSSを配布しています。AndroidはOフラグが有効でもRDNSSからDNSを取得することができました。（OS 5.0.2で確認）

3．iPhone iOSでのアドレス表示がおかしくなりますが疎通には問題ありませんでした。

iOS 9.3.4では、IPv6アドレスを取得している際、Wi-FiのIPアドレス表示画面ではなぜかDNSのみしか表示されないという事象が起きました。これは、アドレス表示ができるアプリをインストールする、外部のサイトで接続に利用しているアドレスを確認するなどにより、実際利用しているアドレスを確認することができました。

■構築上のトラブル

NAT64を利用してインターネットへアクセスする動作には複数のシステムが関わります。そのため、疎通できない場合の問題解析には、切り分けが重要となりました。まずは、IPv4区間の問題なのか、IPv6区間の問題なのか、一部だけしか見られないのか、全部見られないのか、などがポイントとなると考えられます。また、アクセスできているが構築の意図通りではないというケースが複数あり、注意が必要でした。これらは切り分けにもパケットキャプチャなどが無いと困難なことがありました。

1. 適切な端末へのDNS64サーバのDNSアドレスの提供

DNS64を行うDNSサーバのアドレスは、トラフィックをNAT64に経由させない機器に与えると不要なアドレスの変換をしてしまい、問題を起こします。

イベントの会場ネットワーク向けにNAT64を構築した際は、デュアルスタックの網と、実験的なNAT64網との2面を用意しました。しかし、構築中にデュアルスタック向けのDNSサーバもDNS64のサーバとしてしまったため、すべてのIPv4トラフィックがNAT64を経由してしまうという状態になりました。通常に疎通ができてしまうため、問題に気がつきにくい状態でした。今回はそうならなかったのですが、ネットワークにNAT64が無かった場合は、これらのトラフィックは単純に破棄されてしまうことになります。

2. IPv4のインターネットへの到達性

NAT64のセッションテーブルが適切に構築されているかどうかで、パケットがNAT64に到達しているか判断することができます。これを64:ff9b::/96の経路制御に問題が無いかどうか切り分けするために利用することができます。また、NAT64から端末へ戻るパケットは64:ff9b::/96がソースアドレスとなりますので、これらをドロップするようなフィルタが無いかどうか確認しておく必要があります。環境を構築した際は一部の装置にネットワークに割り当てられたアドレス以外はフィルタするよう設定していたため、修正が必要でした。

また、NAT64でインターネット向けに利用するNATプールとしてのipv4アドレスは、インターネットへの到達性が必要です。そのため、IPv4グローバルアドレスを利用しているか、特にサーバにポートが複数ある場合は、そのグローバルアドレスからインターネットへ到達可能な経路情報（デフォルトゲートウェイ）を持っているか注意が必要です。構築中NAT64のセッションテーブルが構築されているのにインターネットへ疎通ができなかった際は、デフォルトゲートウェイの問題でIPv4でインターネットへの疎通性が無い状態が発生していました。

3. IPv6がネイティブでアクセスしているか

通常のDNS64の利用では、IPv6へのアクセスはネイティブとなります。インターネットで利用されるサイトにはすでにIPv6が動作しているものも多くありますので、海外の大手SNSや大手検索エンジンなどへは、IPv6でアクセスされ、NAT64の接続試験とはなりません。そのため、国内の大手ニュースサイトや検索エンジンなど、IPv4のみ動作しているサイトと合わせて動作の確認が必要です。

DNS64をunboundで構築し、dns64-synthallオプションを有効とした場合は、デュアルスタックのサーバ宛の名前解決もDNS64変換されるようになり、トラフィックはNAT64経由となります。結果としてこの設定の有無で全体としてかなり動作が変わりますので、意図されずに設定がなされていないか注意が必要と考えられます。Mac OS XでNAT64の環境を構築するとこの機能が有効になっていることから、この機能を有効としている状態が設定サンプルとして公開されているサイトもありました。この点は設計ポリシーのすり合わせも必要になると思われます。

4.NAT64のセッションテーブルに関するタイマーとアドレスアサイン

NAT64のセッションテーブルに関する各タイマーの長さは、元となるRFC番号と共に、RFC6146の4章に纏められています。

TCP_ESTが2時間となっており、状況によってはセッション数が圧迫される可能性があります。今回構築に利用したjoolでは、FINに対し、RSTが送信され、通信が終了した際に、不要なセッションログが残ることを防ぐオプションがあります。今回のイベント向けの構築では、アドレス数が限定されているためこの機能の利用を検討しています。

–handle-rst-during-fin-rcv

また、Port数が足りないときは、まずページの枠組みなど一部分だけが表示され、時間がたち開放されたセッションでると新たにセッションが割り当てられページが部分ごとに徐々に埋まっていくという動作が確認されました。このような動作が確認された場合はアドレスやポート割り当ての追加などの対応をご検討ください。

5. アプリケーションの動作の確認

NAT64を有効としiPhoneで一ヶ月ほどメール、ブラウザ、一部のゲームやSNSなどのアプリの利用を続けていましたが、アプリケーションの動作で問題になるケースはほとんどありませんでした。一つだけ著名なVoIPアプリケーションはログインが完了せず、利用できませんでした。

Android5.02でも動作を確認しメール、ブラウザなどの基本動作に影響が出ないことを確認しております。

PC環境でも問題が出るケースがあることを確認しており、iPhoneと同じく著名なVoIPアプリケーションが動作しないほか、とある有名なブラウザゲームもログイン後ゲームが開始せず、利用できないことも確認しております。

こちらはプラットフォーム事業者様がすでに事象を認識されておりましたので、いつか改善されることを期待しております。