NAT越えに関する技術とその仕組み 須之内

NAT越えに関する技術とその仕組み株式会社ニューロン 須之内 雄司

sunouchi@newrong.com

はじめに - 自己紹介

須之内 雄司

株式会社ニューロン所属

ネットワーク関連の研究開発NAT越えに関する技術など

アジェンダ

今後のコンピューティングの世界像とP2P

P2P通信とNAT問題

従来のNAT越え問題の解決方法

NAT越え技術

まとめ

今後のコンピュータの進化

1. 既存ハードのネットワーク化PC・PDA・家電・携帯・カーナビ既存のハードがネットワーク化し連携することでそれがより便利に使えるようになる

2. 小型ハード同士の連携ICタグ・GPS・Traceability・センサー単機能な小型デバイス同士が人間の行動や環境にあわせて連携する

3. 全デバイスの連携偏在化した小型デバイスからPCまでの全てのデバイスが人間の行動や環境にあわせてシームレスに連携する

まずは、従来からあるハードを連携させることが重要に

ユビキタス：コンピュータが偏在化する持ち歩く⇒偏在化させる

偏在化するネットワーク端末同士の連携が重要

ユビキタス：コンピュータが偏在化する持ち歩く⇒偏在化させる

偏在化するネットワーク端末同士の連携が重要

家電・デバイスのネットワーク化

プリンタのネット対応により外出先からの遠隔出力

プリンタのネット対応により外出先からの遠隔出力

インターネット

遠隔地PCへのリモートアクセス遠隔地PCへのリモートアクセス USBに差し込むだけで通話ができるインターネット電話

USBに差し込むだけで通話ができるインターネット電話

IP携帯電話のHOTSPOTでの利用

IP携帯電話のHOTSPOTでの利用

ストレスなく利用できるビデオチャット

ストレスなく利用できるビデオチャット

オフィスIP電話オフィスIP電話

ホームサーバ・ハードディスクビデオレコーダの外部からの予約・参照

ホームサーバ・ハードディスクビデオレコーダの外部からの予約・参照

SIPサーバ認証・課金サーバなど

リアルタイム通信対戦型ゲームリアルタイム通信対戦型ゲーム

家電へのアクセス方法

ハブ的モデルハブ的モデル P2P的モデルP2P的モデル

家電・デバイスへのアクセスはＰ２Ｐになっていく

ホームサーバにあらゆる機器とつながり、サービスを提供する

ホームサーバがあらゆる機器をサポートしなくてはらないため、スケールしない

全ての機器がサービスを提供し、ユーザは個々の機器から直接サービスを受ける

Ｐ２Ｐ接続の弊害

多くの端末はプライベートアドレスが割り振られているため

直接通信を行うことができない

多くの端末はプライベートアドレスが割り振られているため

直接通信を行うことができない

家庭の多くはブロードバンドルータをゲートウェイとして利用しているため、家庭内の端末にはプライベートＩＰアドレスが割り振られている

プライベートＩＰアドレスは電話で言うところの内線番号であり、家の外からは呼び出すことはできない

従来のNAT越え問題の解決方法

中継サーバを利用する

グローバルアドレスを持つサーバを経由して接続する

■デメリット

ネットワークや処理の負荷が集中する

レイテンシが増加する

サーバ設置コストがかかる

ポートフォワーディングの設定ルータの指定のポート宛のパケットを内部の端末に

フォワードさせる

■デメリット

いちいちアプリケーションごとに設定するのは面倒

ルータごとに設定方法が違う

初心者には難しい

集中負荷

ユーザに負担がかからないＮＡＴ越え技術が必要ユーザに負担がかからないＮＡＴ越え技術が必要

NAT越え技術

直接通信を行うためNAT越え技術UPｎP

STUN

Teredo

TCPのNAT越え

UPｎP

Microsoftが中心にすすめている規格

家庭内の電化製品とPCを接続するための規格HTTP+XML

ルータにリクエストを投げてポートを開いてもらう

プライベートネットワーク(10.0.0.*) インターネット

2.マップされたポート宛にデータを投げると内部の端末に届く

1.マッピングの生成リクエスト・レスポンス

UPｎPの問題点

実装のバグ

対応ルータでしか使えない

UPnP非対応のルータでは利用ができない

ルータ固有のバグが色々存在する•Case Sensitive•少し間違えるとルータがハングアップする•アロケートされているポートを上書きする

全てのルータに対応するには骨が折れる作業が必要全てのルータに対応するには骨が折れる作業が必要

仕様の違い

正式なUPｎPフォーマットとは別に古いバージョンのMSNメッセンジャーが使っていた別のUPnPフォーマットしか解釈できないものがある

STUN

RFC3489: Simple Traversal of UDP through NAT

UDPでNAT越えするのにも使えるプロトコル

ピア間の通信に関しては特に定義されていないルータに穴を開け、マップされたソケットアドレスを調べる

ルータのマッピングアルゴリズムを調べる

STUNの基本機能

送信先ポートから送り返してもらう

プライベートネットワーク(10.0.0.*) インターネット

192.168.0.2:1000から来たな

ルータの外側は192.168.0.2で、1000番ポートにマップされた

1.STUNのリクエスト

2.STUNのレスポンスリクエスト元のソケットアドレスが格納される

•ルータの外部アドレスを調べる•ローカルのポートがルータのどのポートにマップされたかを調べる

STUNの基本機能

別のポート・別のIPアドレスから送り返してもらう

プライベートネットワーク(10.0.0.*) インターネット

違うＩＰ・ポートからのデータも通る！

•ルータによってパケットを通すものと通さないものがある•ルータがどのようなマッピングを行っているかを調べる

1.STUNのリクエスト

2.STUNのレスポンス

STUNで定義されているルータのタイプ

Full ConeFull Cone

Restricted ConeRestricted Cone

Port Restricted ConePort Restricted Cone

SymmetricSymmetric

NAT越えが楽

NAT越えが困難

ルータのポートマッピング手法によって４つのタイプに分類される

ルータのポートマッピング手法によって４つのタイプに分類される

ルータのタイプ： Full Coneルータ

内部の端末のポートとルータのポートが1:1でマップされる

開いたポートはどこからのパケットでも受け取れる

相手ルータPC

………

*:*192.168.0.2:200010.0.0.1:1000

プライベートネットワーク(10.0.0.*) インターネット

サーバA

サーバB

ルータのタイプ：Restricted Coneルータ

内部の端末のポートとルータのポートが1:1でマップされる

送ったことのあるＩＰアドレスからのパケットのみを通す

サーバBへ一度パケットを投げれば受け取れるようになる

宛先ルータPC

………

サーバA:*192.168.0.2:200010.0.0.1:1000

プライベートネットワーク(10.0.0.*) インターネット

サーバA

サーバB

ルータのタイプ： Port Restricted Coneルータ

内部の端末のポートとルータのポートが1:1でマップされる

送ったことのあるＩＰアドレス&ポート番号からのパケットのみを通す

他のソケットアドレスも一度パケットを投げれば受け取れるようになる

宛先ルータPC

………

サーバA:5000192.168.0.2:200010.0.0.1:1000

プライベートネットワーク(10.0.0.*) インターネット

サーバA

サーバB

ルータのタイプ： Symmetricルータ

RFCの定義では「前述の３つ以外」

一般的には最初に送った宛先以外からは受け付けない実装

同一ソケットから別の宛先に送った場合、ルータに別のポートがマップされる

宛先ルータPC

サーバA:6000192.168.0.2:300010.0.0.1:1000

サーバA:5000192.168.0.2:200010.0.0.1:1000

プライベートネットワーク(10.0.0.*) インターネット

サーバA

STUNを利用したNAT越え

プライベートネットワーク(10.0.0.*)

インターネットSTUNサーバ

プライベートネットワーク(10.0.0.*)

呼制御サーバ

1.STUNを使い、ルータのどのポートにマップされたかを調べる

2.サーバを通じて相手にルータにマップされたソケットアドレスを教えあう

3.相手のから通知されたソケットアドレスにパケットを投げ合う

STUNの問題点

ルータの実装によっては疎通が困難

Symmetricルータ環境では、STUNサーバを使ってポートのマッピングを調べても、ピアとの通信の際には別のポートがマップされるため、相手にアドレスを伝えられない。

ルータのセキュリティ機構がピアから投げられたパケットを攻撃などと勘違いし、通信が妨害されることや、その他実装の仕様により疎通が困難なケースがある

SymmetricルータのNAT越え

2000番ポートですよ

3000番ポート？？

STUNの最近の変更点

ルータタイプのチェック手法を削除

一部のルータはペイロードまで読み取り、IPアドレスでパターンマッチングし、内部・外部のアドレスを変換してしまうものがあり、IPアドレスXORすることでルータ改変を防げる。

ルータの実装のバリエーションが多いため、綺麗に分類することができない。最新のRFCでもプロトコルのセマンティクスは残っているため、旧RFCで定義されていたルータタイプのチェックは行える。

IPアドレスをXORして送るフィールドの追加

IPv6サポート

内部ネットワークがIPv4で、外部ネットワークがIPv6(又はその逆)の場合などに対応。

Teredo

IPv4環境でのIPv6ネットワークの透過的接続を実現Microsoftを中心にすすめられている

ietf-draftの段階

クライアントにはTeredoサーバからIPv6アドレスが振られ、Microsoftの実装では仮想ネットワークデバイスとして認識されるIPv4間はSTUNを利用

IPv4-v6間はTeredo Relay Serverを中継させて通信する

Teredoのアドレッシング

TeredoプレフィクスTeredoプレフィクス

TeredoサーバのIPv4アドレス

TeredoサーバのIPv4アドレス

フラグフラグ

外部ポート外部ポート

IPv6アドレスと同じ形式

32 bit

32 bit

48 bit

16 bit

Teredoアドレスだということを示す固定のプレフィクス

Teredoサーバのアドレス

クライアントのルータのタイプ

TeredoサーバがTeredoクライアントにアクセスするためのUDPソケットアドレス。

外部IPv4アドレス外部IPv4アドレス

Teredoサーバの仕組み

２．サーバを通じてクライアントＢに接続要求を送る

３．クライアントＡにパケットを送る。１の段階でクライアントＡのルータにマッピングができているため、パケットはクライアントＡに届く。

ピアにアクセスするためのv4アドレスやNATのタイプがアドレスに格納されているため、サーバがステートレス

ピアにアクセスするためのv4アドレスやNATのタイプがアドレスに格納されているため、サーバがステートレス

１．クライアントＢのソケットアドレスにパケットを投げる。マッピングがないため、ルータはパケットを破棄するがクライアントＡのルータにマッピングが生成される

クライアントA クライアントB

Teredoの問題点

Symmetricが未対応

宛先ルータ送信元

クライアントB:6000192.168.0.2:3000クライアントA:1000

サーバ:5000192.168.0.2:2000クライアントA:1000

ソケットアドレスのマッピングが1:1のため、サーバとの通信に使われるルータのアドレスが

ピアとの通信には使用できない。クライアントA クライアントB

TCPのNAT越え

TCPでNAT越しにセッションを成立させるすみません、コード書けませんでした

話半分で聞いてください

興味がある方は是非試してみてください(試してみた方は是非結果を教えてください)

TCPの普通の流れ

3-way handshake

クライアントA クライアントB

クライアントA クライアントB

ルータA ルータB

syn

syn-ack

ack

syn

TCPのNAT越えの仕組み

3-way handshakeではなく、4-way handshakeを行う詳解TCP/IP Vol.1 p284

クライアントA クライアントB

(syn) src:ルータA:xxx dst:ルータB:yyy

(syn) src:ルータB:yyy dst:ルータA:xxx

ルータA ルータB

クライアントA クライアントB

ルータA ルータB

クライアントA クライアントB

ルータA ルータB

マッピングが生成されているため、内部に届く

(syn) src:ルータB:yyy dst:ルータA:xxx

(syn) src:ルータA:xxx dst:ルータB:yyy

(ack) src:ルータB:yyy dst:ルータA:xxx

(ack) src:ルータA:xxx dst:ルータB:yyy

TCPのNAT越えの課題

TCPのスタックの実装

通信相手が通常のTCPスタックを利用している場合、4-way handshakeに対応していない可能性がある。また、ルータが4-way handshakeを妨害してしまう可能性がある

ユーザモード(一般のアプリケーション)として実装する場合、独自のTCPスタックをRaw Socket(直接IPの上で通信するためのソケット)で実装しなくてはならない。また、Raw SocketはAdministrator/Root権限がないと利用できない。

TCPのスタックが未対応の可能性

STUNと同様にTCPもマッピングを調べる方法があるかが不明。

マップされるポート

まとめ

今後はあらゆる機器がネットワークにつながっていき、P2Pは必要不可欠になっていく

多くの家庭がルータを利用している中、NAT越え問題は解決しなくてはならない問題である

現在あるNAT越え技術は全て汎用的ではなく、不確定要素が多い

ご清聴ありがとうございました

P2Pアプリケーション開発キット

NAT Traversal SDK

当製品は、ブロードバンド環境で使われるアプリケーションにおけるNAT越え問題を解決するためのライブラリとサーバを提供するソフトウェア開発者向けキットです。

どんなネット環境でも使えるＰ２Ｐアプリケーションの実現

NAT越え問題を解決した直接通信により、インターネット上のデータセンターなどに中継サーバを設置せずに、リアルタイム通信が必要なビデオチャット・ボイスチャット（VoIP）・ファイルやアプリケーションの共有・オンラインゲーム・情報家電アクセスといったアプリケーションを容易に開発できるようになります。

中継サーバ・通信遅延の軽減

独自技術によってどんな環境でも使えるNAT越え技術を実現しました。中継サーバが不要のため負荷や遅延の解決にかかっていたコストを削減できます。

独自新技術と実証実験による安定した動作

どんな環境でも使えるNAT越えを実現するには、ルータに含まれるNAT装置の特性による問題を解決する必要があります。当製品は、従来技術で未解決だったルータ毎のＮＡＴ装置の特性による問題に、独自の新技術と実証実験で漏れなく対応することで、どんな環境でも使えるＮＡＴ越えを実現することに成功しました。

NAT Traversal SDKとXbox LiveのNAT越え機能比較

×○BEFSR41シスコ・リンクシス株式会社

○○BAR EX

×○BAR SW-4P HG株式会社コレガ

○○Router8100Cクリエイティブメディア株式会社

×○KY-BR-CB100京セラ株式会社

×○MR104Fオムロン株式会社

×○LD-BBR4M3エレコム株式会社

○○BA5000Pro

○○BA512R

×○MN7500

○○MN8500C株式会社エヌ・ティ・ティエム

イー

×○AR230Eアライドテレシス株式会社

×○AirMacアップルコンピュータ株式会社

×○SMC7004ABRアクトンテクノロジ株式会社

×○NP-BBRP

×○NP-BBRS株式会社アイ・オー・データ機器

XBOXNAT SDK製品モデル名ベンダー名

シスコ・リンクシス株式会社 ○○BEFSRU31

○○TE4621C住友電工ネットワークス株式会社

XBOXNAT SDK製品モデル名ベンダー名a

×○Cisco2621シスコシステムズ株式会社

×○RTA55iヤマハ株式会社

○○MR-NWGOPT70株式会社マイクロ総合研究所

○○BRL-01A

×○BRL-04EXプラネックスコミュニケーションズ株式会社

○○PBR001

○○PBR007株式会社パーソル

○○BLR3-TX4

○○BLR-TX4M

×○BLR-TX4株式会社バッファロー

○○ATermDR30F/CE

○○BR1500日本電気株式会社

×○CR-110

×○XR-300センチュリー・システムズ株式会社

弊社NAT Traversal SDKとマイクロソフト社Xbox Live!に組み込まれているNAT越え機能を日本で販売されているブロードバンドルータを用いて実証実験にて比較しました。

（日本で販売されているコンシューマ向けブロードバンドルータベンダーに関してはほぼ全てのメーカをカバーしています）

○：ユーザが設定をしなくても、全てのルータに対して安定動作が可能×：通信相手のルータ種別によって通信がつながらない場合あり

製品ロードマップ

IP携帯電話・ネット家電を主眼とした通信ミドルウェアのトータルな提供

基本モジュール

開発 NAT越え対応

SIPクライアント

IP機器の認証・アクセスコントロール

m2m-x規格

無線LANローミング技術

IP機器のなりすまし・不正アクセスの防止SIPと連携した認証およびアクセスコントロール機能を実装します。クライアント認証によってなりすましを防ぐと共に、通信の前段階でアクセスコントロールを行うことで、従来では防げなかった不正アクセスリスクを低減させます。

家電相互連携の標準規格に対応SIPを用いた家電連携の規格団体“UOPF”で策定されたm2m-x規格に準拠したクライアントスタックを開発します。

スケーラブルなIP端末管理技術

10万台以上の端末管理をスケーラブルに実現１０万台以上のIP端末で、電話やコンテンツのプッシュ、リモート管理などを行う場合に、サーバが端末をスケーラブルに管理するための機構を開発します。

IP携帯電話などの機器での無線LANローミング対応無線LANのアクセスポイントが切り替わった際に通信が途切れないようにする技術を開発します。

SIP

クライアント拡張モジュール

開発

サーバ負荷のかからないスケーラブルなSIPクライアントIP電話・IP携帯電話の基本プロトコルであるSIP及びG.711/RTPに対応します。NAT越えに対応することで、ISP限定でない広域IP電話サービスでもスケーラブルに動作します。