webrtcの裏側にあるnatの話 - a talk on nat behind webrtc

WebRTCの裏側にあるNATの話- A talk on NAT behind WebRTC -

@iwashi86

2014/11/26 WebRTC Meetup Tokyo #5

●AttributeName Yoshimasa Iwase

@iwashi86web iwashi.co

●Work

・Web Engineer@NTT Com

・HTML5 Experts.jp Editor

●Recently

・HTML5 Experts.jpにてWebRTC特集掲載！

本題今日はNATの話

(WebRTCなので特にUDPのNAT)

https://flic.kr/p/4HKJE1

なぜ、いまさらNAT？

Internet

NAT NAT

WebRTCのクライアントはNAT配下に居ることが多い

Internet

NAT NAT

クライアント達は何の工夫も無しには直接通信できない・・・

Dropped…

Internet

NAT NAT

そこで、WebRTCでは主にSTUN※を使って

なんとか穴あけしている

Reached!

STUN STUN

※UDP Hole Punchも

Internet

NAT NAT

でも、ダメなケースもある…(その場合はTURNで中継)

STUN STUN

Dropped…

そもそも

https://flic.kr/p/b6WaSP

なんで通ったり落ちたりするの？

https://flic.kr/p/oH1mPu

気になる！（技術者的な意味で）

そんなあなたに良いRFC（4787）

UDP向けNATの振舞いについて熱く語っているRFC

あと、Obsoleteだけど3489(Classic STUN)も参考になる

Full Coneとか、Symmetric NATとか、その辺りの用語はこのRFCで登場

（ただし、区分けがちょっと足りない）

続きはRFCで！

https://flic.kr/p/6n5y3k

が、RFC読むと1分で、こうなる↓

そこで本トークでは特にWebRTCに関係するNAT振舞い

のエッセンス(12章)を紹介(＝RFC 4787をざっくりと)

免責：正確性はRFC原典の用語を参照のこと

https://flic.kr/p/p1Q8WT

Requirement

RFCの抜粋です

マッピングの話から

3 種類のマッピング：1. Endpoint independent

エンドポイントに依存しない2. Address Dependent

アドレスに依存する3. Address and Port Dependent

アドレスとポートに依存する

NAT1.1.1.100

1.1.1.200

192.168.1.2

192.168.1.1 1.1.1.1

NAT1.1.1.100

1.1.1.200

192.168.1.2

192.168.1.1 1.1.1.1

元：192.168.1.2:10000

先：1.1.1.100:80

NAT1.1.1.100

1.1.1.200

192.168.1.2

192.168.1.1 1.1.1.1

元：1.1.1.1:12345

先：1.1.1.100:80

元：192.168.1.2:10000

先：1.1.1.100:80

NAT1.1.1.100

1.1.1.200

192.168.1.2

192.168.1.1 1.1.1.1

元：1.1.1.1:12345

先：1.1.1.100:80

元：192.168.1.2:10000

先：1.1.1.100:80

元：192.168.1.2:10000

先：1.1.1.200:80

NAT1.1.1.100

1.1.1.200

192.168.1.2

192.168.1.1 1.1.1.1

元：1.1.1.1:12345

先：1.1.1.100:80

元：1.1.1.1:12345

先：1.1.1.200:80

元：192.168.1.2:10000

先：1.1.1.100:80

元：192.168.1.2:10000

先：1.1.1.200:80

NAT1.1.1.100

1.1.1.200

192.168.1.2

192.168.1.1 1.1.1.1

元：1.1.1.1:12345

先：1.1.1.100:80

元：1.1.1.1:12345

先：1.1.1.200:80

元：192.168.1.2:10000

先：1.1.1.100:80

元：192.168.1.2:10000

先：1.1.1.200:80

エンドポイント(宛先)

に拘らないマッピング

NAT1.1.1.100

1.1.1.200

192.168.1.2

192.168.1.1 1.1.1.1

NAT1.1.1.100

1.1.1.200

192.168.1.2

192.168.1.1 1.1.1.1

元：1.1.1.1:12345

先：1.1.1.100:80

元：192.168.1.2:10000

先：1.1.1.100:80

NAT1.1.1.100

1.1.1.200

192.168.1.2

192.168.1.1 1.1.1.1

元：1.1.1.1:12345

先：1.1.1.100:80

元：192.168.1.2:10000

先：1.1.1.100:80

元：192.168.1.2:10000

先：1.1.1.200:80

NAT1.1.1.100

1.1.1.200

192.168.1.2

192.168.1.1 1.1.1.1

元：1.1.1.1:12345

先：1.1.1.100:80

元：192.168.1.2:10000

先：1.1.1.100:80

元：192.168.1.2:10000

先：1.1.1.200:80元：1.1.1.1:54321

先：1.1.1.200:80

今回は、同じマッピングじゃない（下図だとPortが異なる）

NAT1.1.1.100

1.1.1.200

192.168.1.2

192.168.1.1 1.1.1.1

元：1.1.1.1:12345

先：1.1.1.100:80

元：192.168.1.2:10000

先：1.1.1.100:80

元：192.168.1.2:10000

先：1.1.1.100:8888

じゃあ、同じホストの別ポートに送ると？？

NAT1.1.1.100

1.1.1.200

192.168.1.2

192.168.1.1 1.1.1.1

元：1.1.1.1:12345

先：1.1.1.100:80

元：192.168.1.2:10000

先：1.1.1.100:80

元：192.168.1.2:10000

先：1.1.1.100:8888

同じマッピング！つまり、宛先にのみ依存している。

元：1.1.1.1:12345

先：1.1.1.100:8888

同じマッピング！つまり、宛先にのみ依存している

NAT1.1.1.100

1.1.1.200

192.168.1.2

192.168.1.1 1.1.1.1

NAT1.1.1.100

1.1.1.200

192.168.1.2

192.168.1.1 1.1.1.1

元：1.1.1.1:12345

先：1.1.1.100:80

元：192.168.1.2:10000

先：1.1.1.100:80

元：192.168.1.2:10000

先：1.1.1.100:8888

３つ目のケースで、同じホストで違うポートに送ると？？？

NAT1.1.1.100

1.1.1.200

192.168.1.2

192.168.1.1 1.1.1.1

元：1.1.1.1:12345

先：1.1.1.100:80

元：192.168.1.2:10000

先：1.1.1.100:80

元：192.168.1.2:10000

先：1.1.1.100:8888

違うマッピングができる！

元：1.1.1.1:54321

先：1.1.1.100:8888

https://flic.kr/p/kSFs6b

WebRTC的にイケてるのはどれでしょう？（正確には、P2P的にイケてるのはどれでしょう？）

1. Endpoint independent

2と3は、STUNで自分のNATの外側のアドレス（= Server-Reflexive Address、Mapped-Address）を調

べても、結局使えない…。

なのでRFCも・・・

MUSTになってる！

NATはパブリック側(外側)のIPアドレスを複数貯めておける。その貯めたアドレスを使う場合は、

「同じ宛先には同じ送信元アドレス」を使いましょう、ということ。

ポート多重ダメ・ゼッタイ

ポート多重(Port Overloading)

NAT1.1.1.100

1.1.1.200

192.168.1.2

192.168.1.1 1.1.1.1

元：192.168.1.2:10000

先：1.1.1.100:80

元：192.168.1.3:10000

先：1.1.1.200:80

192.168.1.3

NAT1.1.1.100

1.1.1.200

192.168.1.2

192.168.1.1 1.1.1.1

元：1.1.1.1:10000

先：1.1.1.100:80

元：192.168.1.2:10000

先：1.1.1.100:80

元：192.168.1.3:10000

先：1.1.1.200:80元：1.1.1.1:10000

先：1.1.1.200:80

192.168.1.3

NAT1.1.1.100

1.1.1.200

192.168.1.2

192.168.1.1 1.1.1.1

元：1.1.1.1:10000

先：1.1.1.100:80

元：192.168.1.2:10000

先：1.1.1.100:80

元：192.168.1.3:10000

先：1.1.1.200:80元：1.1.1.1:10000

先：1.1.1.200:80

192.168.1.3

同じの使っちゃうケース同じの使っちゃうケース

ちなみに帰り道(復路)は、送信元が大事

NAT1.1.1.100

1.1.1.200

192.168.1.2

192.168.1.1 1.1.1.1

元：1.1.1.1:10000

先：1.1.1.100:80

元：192.168.1.2:10000

先：1.1.1.100:80

元：192.168.1.3:10000

先：1.1.1.200:80元：1.1.1.1:10000

先：1.1.1.200:80

192.168.1.3

NAT1.1.1.100

1.1.1.200

192.168.1.2

192.168.1.1 1.1.1.1

元：1.1.1.100:80

先：1.1.1.1:10000

元：192.168.1.2:10000

先：1.1.1.100:80

192.168.1.3

往路

復路

元：1.1.1.200:80

先：1.1.1.1:10000このアドレスで復路を打ち分ける

もともとの送信元ポートが0-1023ならNAT後も0-1023、もともとの送信元ポートが1024-65535ならNAT後も1024-65535、

といったように同じレンジを使うのがRECOMMENDED

NATするときのポート番号は、Before−＞Afterで奇数偶数を同じにしようねということ。

つまり、もともとのポートが偶数なら、NAT後も偶数ということ。

マッピングの保持時間は2分以下だとダメだよ。5分以上がオススメで、自由に設定してOK。

ただし、0-1023のウェルノウンポートはIANAに従ってね。

マッピング更新するトラフィックの向きはアウトバウンド（外向き）のトラフィックがMUST。

インバウンドやってもいいけど、攻撃されちゃうかもね。

NATによっては、NAT前後のIPレンジが同じことも。例えば、10.0.0.0/Xから10.0.0.0/XのNATもあり得る。

（ご家庭だとあんまり無いけど）

そんなときはには、どっちかで対応すること：(1)内外でアドレスかぶらんように

(2)アドレスがコンフリクト（衝突）してもよしなに翻訳転送してね

大事！絵！

3 種類のフィルタリング：1. Endpoint independent

NAT1.1.1.100

1.1.1.200

192.168.1.2

192.168.1.1 1.1.1.1

元：1.1.1.1:12345

先：1.1.1.100:80

元：192.168.1.2:10000

先：1.1.1.100:80

NAT1.1.1.100

1.1.1.200

192.168.1.2

192.168.1.1 1.1.1.1

元：1.1.1.1:12345

先：1.1.1.100:80

元：192.168.1.2:10000

先：1.1.1.100:80

まず外側に送る

NAT1.1.1.100

1.1.1.200

192.168.1.2

192.168.1.1 1.1.1.1

元：1.1.1.1:12345

先：1.1.1.100:80

元：192.168.1.2:10000

先：1.1.1.100:80

さっきと宛先が違うホストから来ても通せる

＝エンドポイントに依存しない

元：1.1.1.200:80

先：1.1.1.1:12345

NAT1.1.1.100

1.1.1.200

192.168.1.2

192.168.1.1 1.1.1.1

NAT1.1.1.100

1.1.1.200

192.168.1.2

192.168.1.1 1.1.1.1

元：1.1.1.1:12345

先：1.1.1.100:80

元：192.168.1.2:10000

先：1.1.1.100:80

NAT1.1.1.100

1.1.1.200

192.168.1.2

192.168.1.1 1.1.1.1

元：1.1.1.1:12345

先：1.1.1.100:80

元：192.168.1.2:10000

先：1.1.1.100:80

最初に送ったホストと違うから落ちる

（＝アドレスに依存している）

元：1.1.1.200:80

先：1.1.1.1:12345

NAT1.1.1.100

1.1.1.200

192.168.1.2

192.168.1.1 1.1.1.1

元：1.1.1.1:12345

先：1.1.1.100:80

元：192.168.1.2:10000

先：1.1.1.100:80

元：1.1.1.200:80

先：1.1.1.1:12345

同じホストからならOK

（上図だと、同じホストで異なるPort)

NAT1.1.1.100

1.1.1.200

192.168.1.2

192.168.1.1 1.1.1.1

NAT1.1.1.100

1.1.1.200

192.168.1.2

192.168.1.1 1.1.1.1

元：1.1.1.1:12345

先：1.1.1.100:80

元：192.168.1.2:10000

先：1.1.1.100:80

NAT1.1.1.100

1.1.1.200

192.168.1.2

192.168.1.1 1.1.1.1

元：1.1.1.1:12345

先：1.1.1.100:80

元：192.168.1.2:10000

先：1.1.1.100:80

元：1.1.1.200:80

先：1.1.1.1:12345

同じホストでも、ポートが異なるとNG

（かなり厳しいフィルタリング）

https://flic.kr/p/kSFs6b

RFC的にイケてるのはどれでしょう？

（本日２回目）

ただし、RFC4787ではセキュリティを気にする場合は、2. Address DependentもRECOMMENDEDとしている。

WebRTC的に言えば、Mappingとの組み合わせが需要で、「3. Address and Port Dependent」でもつながるはず

ヘアピン接続もサポートしてね！

ヘアピン接続点線のマッピングができている状態で、PC-Aから、PC-BのNAT後のアドレスを指定して、NAT折り返しで接続すること

NATPC-A

192.168.1.1 1.1.1.1

送信先アドレスとして外側のアドレスを指定する

のがポイント

ALG(Application Level Gateway)の機能はOFFしてね(例：勝手にペイロードの中身も書き換えないでね)

好き勝手に動作を変えないでね(deterministic behaviorしてね)

（力尽きたので）そこまでWebRTCに関係しないので

省略

https://flic.kr/p/4LXLZ2

14個おしまい！(一部ショートカット有り)

ん？そもそも

なんで通ったり落ちたりするの？

答えの前にUDPホールパンチング

PC-A PC-B

NAT NAT

PC-A PC-B

NAT NAT

マッピングが無いので落ちる

PC-A PC-B

NAT NAT

マッピングが無いので落ちる

だが、PC-B向けに穴が開いた(マッピングが出来た)

PC-A PC-B

NAT NAT次に反対向きに打つと今度は疎通OK

PC-A PC-B

NAT NAT次に反対向きに打つと今度は疎通OK

しかも、PC-A

向けの穴が開くということは、

PC-A PC-B

NAT NATいまなら

一発目の向きも疎通OK

再掲：なんで通ったり落ちたりするの？

Mapping × Filtering の特性で決まる(特にUDPホールパンチングで通す場合)

- Endpoint Independent Mapping

- Endpoint Independent Filtering

- Endpoint Independent Filteringいつなんとき

誰のでも挑戦を待つ猪木的NAT

- Address Dependent Mapping

- Address Dependent Filtering

相手が狙うべきアドレスが変わっちゃうから通らない（STUNで調べたアドレスが

おまけMiscellaneous Topics

http://www.netmanias.com/en/?m=view&id=techdocs&no=6065

古いRFCのNAT分類はマッピング×フィルタリングで説明できる

注今日の話はあくまでRFCの話！ホントの動作は装置依存です！

参考資料Further Study

P2P通信技術：NAT超え〜STUNとUPnPと、時々、TURN〜http://homepage3.nifty.com/toremoro/study/voip2008/NATTraversal.p

NAT技術者にお勧めするRFCとドラフトhttp://toremoro.tea-nifty.com/tomos_hotline/2008/06/natrfc_e2f2.html

P2Pとファイアウォールhttp://homepage3.nifty.com/toremoro/p2p/firewall.html

ISPのNATには何が求められるか？http://www.janog.gr.jp/meeting/janog22/program/day1/data/day1-5-

1_Nishitani.pdf

参考資料：

共存/移行技術とP2P対戦ゲームの相性https://www.janog.gr.jp/meeting/janog30/doc/janog30-v64-pre-stun-

ryosato-02.pdf

webrtcの裏側にあるnatの話 - a talk on nat behind webrtc

Technology

webrtc build mcu on browser

webrtc の紹介

let's begin webrtc

webrtc boot camp (webrtc conference japan 2016)...

webrtc sfu mediasoup sample

beispiel einer webrtc-lösung - comconsult research...webrtc...

webrtc 허영남 20150528

webrtc meetup barcelona 2017

webrtc by eyeball networks

webrtc agent console

getting started with webrtc

webrtc bootcamp handson

understanding webrtc - infographic

presentación webrtc y lynckia

webrtc 전망 최진호_webappscamp

webrtc 현재와 미래 최진호 2016

janus @ webrtc meetup stockholm

webrtc sur.gdgdevfest.com - @dperilla

node.js with webrtc datachannel

future internet - webrtc