DEIM Forum 2017 A6-2

インターネット非接続時における複数 NAT 越え P2P 通信方式の検討
田中 有彩†前野誉††

大和田泰伯†††

高井峰生†,††††

小口 正人†† お茶の水女子大学 〒 112-8610 東京都文京区大塚 2-1-1†† 株式会社スペースタイムエンジニアリング 〒 101-0025 東京都千代田区神田佐久間町 3-27-3††† 情報通信研究機構 〒 980-0812 宮城県仙台市青葉区片平 2-1-3†††† UCLA Computer Science Department 3803 Boelter Hall, Los Angeles, CA 90095-1596, USA
E-mail: †{g1320523,oguchi}@is.ocha.ac.jp, ††tmaeno@spacetime-eng.com, †††yowada@nict.go.jp,††††mineo@ieee.org
あらまし

多くのネットワークアプリケーションはクライアント・サーバ型通信を使用しており，災害時には被災域外への通信の遮断や輻輳を起こす恐れがある．そのため災害時においてインターネットにつながらない場合，もしく
は衛星回線等によりインターネット接続回線が非常に細い場合においても情報共有できるアプリケーション通信環境が必要である．そこで本研究では，インターネット非接続時でもプライベートネットワーク間で NAT 越えを実現することにより，P2P 型通信を用いた情報共有を行うことを目指す．方法としては，シグナリングサーバと STUN サー
バ，必要に応じて TURN サーバを用意し，WebRTC を用いて，NAT 配下にある端末同士の P2P 型通信を可能にすることを検討する．
キーワード NAT 越え，P2P，災害，シグナリング，STUN，TURN

Studies of P2P communication system using multiple NATs traversal noton the Internet
Arisa TANAKA† , Taka MAENO†† , Yasunori OWADA††† , Mineo TAKAI†,†††† , and Masato
OGUCHI†† Ochanomizu University
2-1-1 Otsuka, Bunkyouku, Tokyo 112-8610 JAPAN†† Space-Time EngineeringKandaSakumacho 3 ‒ 27 ‒ 3, Chiyoda-ku, Tokyo, 101-0025, JAPAN††† National Institute of Information and Communications Technology 2-1-3, Katahira, Aoba, Sendai-city,Miyagi, 980-0812, JAPAN†††† UCLA Computer Science Department 3803 Boelter Hall, Los Angeles, CA 90095-1596, USA
E-mail: †{g1320523,oguchi}@is.ocha.ac.jp, ††tmaeno@spacetime-eng.com, †††yowada@nict.go.jp,††††mineo@ieee.org

1. は じ め に型通信を使用しているため，災害時には被災域外への通信の遮断や輻輳を起こす恐れがある．そのため災害時においてイン

現在, インターネットは人々にとって欠かせない生活の一部ターネットにつながらない場合，もしくは衛星回線等によりイとなっており, 人類共通の重要な情報インフラとして広く普及

ンターネット接続回線が非常に細い場合においては情報共有がされている. 中でも多くの人が通話や電子メール,SNS など, 連できなくなってしまう．そこでインターネットにつながってい絡を取る手段としてインターネットを利用している. そのためない状況下でも情報共有できるアプリケーション通信環境が必突然インターネットが使えなくなり, 連絡が取れなくなってし要だと考えた.

まうことは人々への不安や困惑を招く可能性がある. 特に地震通信方法としてはクライアント・サーバ型通信ではなく P2P大国である日本にとって, その可能性は大きいと言える. また型通信を利用する. これは, クライアント・サーバ型通信では,多くのネットワークアプリケーションはクライアント・サーバ

災害時にサーバが使えなくなってしまうともはや通信ができな—1—くなってしまうためである. これに対し P2P 型通信であれば,どの関連研究もサーバを必要とする前提での NAT 越えと災害時に 1 つアクセスポイントがあれば端末同士での通信が可なっている. そのため, 本研究の特徴とも言える NAT ルータ自能となるためである.

体にサーバを搭載するという点は非常に有益だと考えられる.

またモバイル・アドホックネットワーク (MANET) とは基地局や固定網に依存せず, 移動端末を構成要素とする自律分散形のネットワークである [1]. 既存の施設や設備を必要とせずに

3. P2P (Peer to Peer) 方式とクライアント・サーバ方式ネットワークを構成できるという利点にも関わらず, なかなか実用化はされていない. これは,MANET を利用した多くのも

P2P 方式とは，ネットワーク上で対等な関係にある端末間をのが, 端末側での事前準備を必要とする方式であったことが一相互に直接接続し，データを送受信する方式 (図 1) である．ま因であると言える. そこで通常の MANET は端末同士間でのた，そのような方式を用いて通信するソフトウェアやシステム通信としていることが多いが, 今回は NAT(Network Addressの総称でもある．データの送り手と受け手が分かれているクラTranslator) ルータ同士での通信とする. つまり, この仕組みをイアント・サーバ方式 (図 2) などと対比される用語で，利用者端末自体に作るのではなく，NAT ルータ自体に作ることで，間を直接繋いで音声やファイルを交換するシステムが実用化さ

NAT ルータ同士の MANET を構築し，端末側での準備の必要れている．これにより，特定のサーバを介さずに，端末同士のなく NAT ルータを利用して P2P 型通信によりデータを共有す通信を可能にする．

ることを最終目標とする.

クライアント・サーバ方式とは, サービスを提供する側（サー本研究では初期段階として，インターネット非接続時でもバ）とサービスを受ける側（クライアント）をネットワークでプライベートネットワーク間で NAT 越えを実現することによ結び, クライアントからの要求にサーバが応答する形で処理をり，P2P 型通信を用いた情報共有を行うことを目指す．方法と進める方式である. 通常のネットワーク通信で利用されているしては，シグナリングサーバと STUN サーバ，必要に応じてのはクライアント・サーバ方式である. また MANET はモバTURN サーバを用意し，WebRTC 技術を用いて，NAT 配下にイル環境において P2P 接続を利用し, 一時的なネットワークをある端末同士の P2P 型通信を可能にすることを検討する．ま構成するものである. 通常の MANET は端末間の P2P 接続をずはプライベートネットワーク間での NAT 越え P2P 型通信に用いるが, 本研究では端末が所属するプライベートネットワーよる情報共有の実験を行った.

ク間の接続を利用する点が特徴である.

2. 関 連 研 究
現在，NAT の外部から内部のネットワークへ通信を開始できないという NAT 越え問題に対する研究が多くなされている.

[2] では，外部ノードとホームゲートウェイが連携することにより NAT 越え問題を解決する従来の NAT-f(NAT-free

図 1 P2P 方 式protocol) の誰でもホームネットワーク内の内部ノードにアクセスできてしまうという課題に対し，サービス単位でグルーピングすることにより，外部ノードからのアクセス制御と内部ノードが提供するサービスの制御を同時に実現できることが示されている.

[3] では，DNS サーバと NAT ルータを利用して両者を協調させることにより NAT 越えを実現する方式が提案されている.
その提案方式は NTS(NAT-Traversal Support) システムと呼ばれており,DNS サーバを改造した NTS サーバ,NAT ルータを改造した NTS ルータ, 実行するプロトコルとして NTS プロトコルが使用されている. また端末の機能追加が必要な NAT-fとは異なり，一般のユーザ端末に機能を追加することなく, かつエンドエンドで NAT 越えを実現できる方式である.

[4] では，STUN では本来対応することができないシンメト

図 2 クライアント・サーバ方式

リック型 NAT を STUN を拡張することで超えて，NAT の外側から TCP 通信を開始する手法の実装が行われている. 本来ならば STUN は UDP 通信におけるものが多く，それと比較して TCP 通信における研究は少ないため，珍しい研究である. しかし本研究では後述する WebRTC 技術を利用するため, プロ
トコルは UDP を対象としている.

—2—

が P2P セッションを確立するには，シグナリングにより通信

4. NAT 越え技術と WebRTC

相手の IP アドレスや接続ポート番号等の情報を互いに交換し4. 1 NAT 越えなければいけないため，どちらの端末からもアクセスできるシ

多くの端末はプライベートネットワークに所属して NAT 配グナリングサーバが必要となる．

下にあり，端末から外のネットワークへ通信をすることが通常

ICE とは STUN や TURN などの NAT 越えの手順をまとめである．しかし逆に，外から NAT 配下の端末へ直接通信するたものであり，通信できそうな候補を集め，シグナリングによことはできない．

り相手とその候補を交換し，相手との通信を試みる仕組みであこの問題を解決する手法を NAT 越え（NAT Traversal）とる．また,STUN による P2P 通信を図 3 に,TURN による通信を図 4 に示す．

いう．

4. 2 STUN と TURNSTUN (Session Traversal Utilities for NATs) とは，NAT越えの方法の一つである． 通信するホストが STUN サーバにUDP 接続を行い，NAT が割り当てたグローバル IP アドレスとポート番号を取得する．NAT の種類にはフルコーン型・制限コーン型・ポート制限コーン型・シンメトリック型と全部で4 種類ある (表 1)．STUN が対応できる NAT は，フルコーン型・制限コーン型・ポート制限コーン型の 3 つに限られる．
表 1 から分かるように, 表が下に行くほど利用制限が厳しくなっている. 特に一番厳しいシンメトリック型は STUN で対応できない. そのため，シンメトリック型には TURN(TraversalUsing Relay NAT) を使用することで，全ての NAT に対応する． しかしすべての通信を TURN サーバ経由で行うため，P2P

図 3 STUN による P2P 通信通信ではなくなり, またサーバにも高負荷が掛かってしまう．
表 1 NAT の種類
種類名NAT が割り当てたポートにアク利用制限の厳しさセスできるインターネット側の端末の制限
フルコーン型

どの端末でもアクセス可緩やか制限コーン型

NAT 配下の端末がアクセスした

厳しめ

端末からアクセス可
ポート制限コーン型

NAT 配下の端末がアクセスした 制限コーン型より厳しい端末とポート番号からだけアクセス可シンメトリック型

通信元の端末と通信先の端末が 1

かなり厳しい対 1 の場合にしか使えない

4. 3 WebRTC
WebRTC(Web Real-Time Communications) とは， ブラウ

図 4 TURN によるサーバ経由通信

ザでリアルタイムコミュニケーションを実現するための仕組みである． つまり，P2P 通信を利用して端末間の相互接続が可能である．プロトコルには UDP が使われているため，高速な通5. 想 定 環 境信ができる．WebRTC による P2P 通信をするためには，シグナリングと ICE(Interactive Connectivity Establishment) が必要である．

災害時の通信環境を想定したものを図 5 に示す．この時, プライベートネットワーク同士が NAT ルータを介してアドホッ

シグナリングとは，通信相手の IP アドレス情報やポート番クに接続した際に自律的にシグナリングサーバ，STUN/TURN号等の情報を解決する手法である．ICE は後述する NAT 越え

サーバを一意に検出し，NAT 越えの P2P 通信による情報共有通信のためのセッション確立のための情報交換を行うプロトコが行える仕組みを備えた Wi-Fi AP 兼 NAT ルータを用いるこルである．とを想定している.
災害時においてインターネットに繋がらない状況でも, この

4. 4 NAT 越えと P2P 通信
WebRTC を用いてプライベートネットワーク内の端末同士の P2P 通信を行うためには， NAT 越えが必要となる．このNAT ルータの Wi-Fi につなぐことで,Wi-Fi に繋がっている端末同士が情報共有を行うことが可能になる. 本研究ではこのような通信環境を想定して検討を行った.

時，シグナリングと ICE という仕組みが利用される．端末同士—3—

である Socket.io で構築されたシグナリングサービスを使用している.

図5 想定環境

6. ローカル環境における NAT 越え実験

図7 実験環境

6. 1 動作の流れ
本研究での端末の動作の流れを図 6 に示す．これには NAT

無線 LAN を搭載した Debian GNU/Linux8 ubilinux サー

越え技術と P2P 通信技術が使用されている．動作は以下の通バ 2 台にそれぞれ hostapd をインストールし，Wi-Fi AP 兼りとなっている．

NAT ルータとして動作させた．このルータの仕様を表 2 に示す. ESSID は AP(COM9) がtest-p2p ，AP(COM10) がtest-nat となっている．これにより 2 つの異なるプライベートネットワークを作成した. この時の Wi-Fi の仕様を表 3 に示す.

Client としては PC2 台をそれぞれ別の Wi-Fi AP に繋げて設置した．IP アドレスは Client1 が 192.168.42.100，Client2が 192.168.50.100 となっている．
サーバとして，アクセスポイント (COM9) のイーサネットである IP アドレス 192.168.1.144 のポート番号 8080 にシグナリングサーバである easyRTC を，ポート番号 3478 に STUN
兼 TURN サーバである coturn を構築した．またシグナリン
グサーバにおける STUN/TURN サーバの設定は,IP アドレス

192.168.1.144 のポート番号 3478 とした. 2 台の AP とサーバは有線 LAN でつなぎ，同じネットワーク内となっているため，
図 6 NAT 越えと P2P 通信の処理

1) 相手と通信するには相手の外から見た IP アドレスが必要であるため，STUN・TURN サーバに自分の外から見たネットワークは全部で赤色と青色と緑色の 3 つとなっている．
そしてプライベートネットワーク間で情報共有ができるかどうかを試す．今回は Client1 から Client2 へ test.zip という 2MBの ZIP ファイル送受信を行う．

IP アドレス情報を問い合わせる．

表 2 Wi-Fi AP 兼 NAT ルータの仕様
CPU2) 自分の外から見た IP アドレス情報と様々な相手との経路情報を獲得．これにより，NAT 越え問題を解決．

Genuine Intel(R) CPU 4000@500 MHz

Storage

Compact Flash 6GB

OSDebian GNU/Linux8 ubilinux

WirelessLAN

IEEE 802.11n

3) 相手と通信したいことを通知．
4) 相手の情報や通信経路情報を交換．

表 3 Wi-Fi の仕様

5) P2P 通信または TURN による通信の開始．
SSID

プロトコル

セキュリティの種類

ネットワーク帯域

ネットワークチャンネル

6. 2 実 験 環 境

test-p2p802.11n

WPA2-パーソナル

2.4GHz7

本研究では，WebRTC のオープンソースソフトウェアであtest-nat802.11n

WPA2-パーソナル

2.4GHz4

る easyRTC， STUN 兼 TURN サーバが構築できるオープンソースソフトウェアである coturn を用い，実験用のローカル環境を構築した．その環境を図 7 に示す．これにより，ローカル環境における NAT 越え情報共有の実験を行う．
また easyRTC は WebRTC のビデオ・オーディオ・データアプリケーションなどが利用でき,Node.js の WebSocket 実装—4—

6. 3 実 験 結 果
Client1 における Wireshark によるパケットキャプチャを図8・図 9 と図 10 に，Client2 におけるものを図 11 と図 12 に示す．
図 8 から,STUN プロトコルで Client1 とサーバ間で Bind-

図 11 Client2 におけるパケットキャプチャ 1

ing Request が互いに送られていることが分かる. また互いにBinding Success Response とあるように, 成功していることが分かる. これにより,Client1 である 192.168.42.100 とサーバで
図 12 Client2 におけるパケットキャプチャ 2ある 192.168.1.144 の間で STUN による P2P 通信が可能になる. このことは次の図から見て分かる. 図 9 から，プロトコル

DTLS で Client1 とサーバが Application Data のやり取りを

6. 4 考察していることが分かる．これは先ほど述べたように,STUN にこれらの結果からプライベートネットワーク間での情報共有よる Binding Request の成功により,P2P 通信が可能となったは,Client1 とサーバ間では STUN が成功し,P2P 通信がなされためである. 図 10 は図 9 のキャプチャの 1 つをより詳しくており,Client2 とサーバ間では TURN による中継通信となっ見たものである. これによると,Src: 192.168.42.100 Src Port:ていることが分かった. これは Client2 が多段 NAT となって50909 と Dst : 192.168.1.144 Dst Port: 57775 でのやり取りいるからだと考えられる. STUN はその特性から NAT の最もであることが分かる. これは図 8 の 3,4 行目の info から分かる

外側から見た（すなわちサーバ側から見た) アドレスしか知りように,Binding Success Response による IP アドレスとポー得ないため, 多段 NAT に対応することができない. またそのト番号が使用されている.

場合,TURN サーバがピア間のパケットを中継することによっ

続いて Client2 について見ていく. 図 11 から,Client2 とサーてピア間の通信を実現されている. 以上のことから Client1 でバ間で TURN による情報共有が行われていることが分かる. こは P2P 通信,Client2 では多段 NAT となってしまっているたのときプロトコルが STUN となっているが, これは Wireshark

め,TURN による通信になったと考えられる.の仕様による表記であり, 本来は TURN プロトコルが使用されている. また図 12 から,Client2 の Peer, つまり通信相手がClient1 の IP アドレス 192.168.42.100 であることが分かる. つまり,Client2 の通信相手は Client1 であることが分かる. 以上のことから Client1 から Client2 への情報共有に成功している

7. まとめと今後の課題
最終目標に対し, ローカル環境における STUN/TURN を用いた NAT 越えと情報共有が可能であることが確認できた．
今後は，まず STUN を用いて P2P 通信ができるようにし, プことが分かる．このことよりローカル環境における 2 つのプラライベートネットワーク同士が NAT ルータを介してアドホッイベートネットワークを接続した NAT 越え情報共有ができてクに接続した際に自律的にシグナリングサーバ，STUN/TURNいることが確認できた．

サーバを一意に検出し，NAT 越えの P2P 通信による情報共有が行える手法を検討する．

謝辞

図 8 Client1 におけるパケットキャプチャ 1

本研究の一部はお茶の水女子大学と情報通信研究機構との共同研究契約に基づくものである．

文

図 9 Client1 におけるパケットキャプチャ 2

図 10 Client1 におけるパケットキャプチャ 3

献[1] 間瀬憲一” モバイル・アドホックネットワーク ”， シンポジウ
ム (47)，pp.13-26，2002 年 3 月.
[2] 鈴木秀和，渡邊晃” 通信グループに基づくサービスの制御が可能な NAT 越えシステム”，マルチメディア，分散，協調とモバイ
ル (DICOMO2009) シンポジウム，pp.372-378，2009 年 7 月.
[3] 宮崎悠, 鈴木秀和, 渡邊晃” 端末に依存しない NAT 越えシステムの提案と実装”，マルチメディア，分散，協調とモバイル(DICOMO2008) シンポジウム，pp.587-592，2008 年 7 月.
[4] 黒田隼之輔, 中山泰一” TCP における STUN を用いた対称型
NAT 越え手法の実装と評価”，情報処理学会全国大会講演論文
集，73rd,p.3.421-3.422，(2011)．
[5] 竹川知孝, 佐藤未来子, 並木美太郎 ” NAT 越えの通信を実現す
る STUN 及び TURN の 実環境への適用可能性について”，全国大会講演論文集，74rd,p.1.13-1.14,(2012)．
[6] 宮崎悠, 鈴木秀和, 渡邊晃” 端末の改造が不要な NAT 越え通信システム NTSS の提案と評価”，情報処理学会論文誌，Vol.51，—5—No.9，p.1873-1880，(Sep. 2010)．
[7] 鈴木秀和, 渡邊晃” 通信グループに基づくサービスの制御が可能な NAT 越えシステムの提案”，情報処理学会論文誌，Vol.51，
No.9，p.1881-1891，(Sep. 2010)．
[8] easyRTC
https://easyrtc.com/, 2016 年 10 月参照.
[9] STUNTMAN
http://www.stunprotocol.org/, 2016 年 11 月参照.
[10] coturn
https://github.com/coturn/coturn, 2016 年 9 月参照.
[11] udonchan.”WebRTC における NAT 越えの課題へのアプロー
チ” Qiita.
http://qiita.com/udonchan/items/693e43b13269207f904a, 2016年 12 月参照.
[12] がねこまさし.”そして壁の向こうへ。 NAT/Firewall を越えて通信しよう―WebRTC 入門 2016” HTML5Experts.jp.
https://html5experts.jp/mganeko/20618/, 2016 年 6 月参照.
[13] がねこまさし.”壁を越えろ！ WebRTC で NAT/Firewall を越えて通信しよう” HTML5Experts.jp.
https://html5experts.jp/mganeko/5554/, 2016 年 6 月参照.
[14] 吉川徹.”WebRTC で変わる Web の未来” QCon Tokyo.
http://www.qcontokyo.com/data 2013/ToruYoshikawa
QConTokyo2013.pdf, 2016 年 9 月参照.
[15] 望月いちろう.”WebRTC の現状 - STUN/TURN・シグナリン
グサーバーについて” 望月いちろうの README.md.
http://www.utali.io/entry/2016/09/07/142102, 2016 年 12月参照.
[16] Sam Dutton.”WebRTC in the real world: STUN, TURN
and signaling” HTML5ROCKS.
https://www.html5rocks.com/en/tutorials/webrtc/infrastructure/,
2017 年 2 月参照.

—6—