Upgrade to Pro — share decks privately, control downloads, hide ads and more …

STUN・TURNを ちょっとだけ深掘りしてみた

STUN・TURNを ちょっとだけ深掘りしてみた

WebRTC Meetup Tokyo #24 2023/06/23 の資料です。
Googleスライド版はこちら

お話すること
STUN・TURN概要
STUN・TURNのパケットについて
お話しないこと
NAT越えの仕組み
STUN・TURNサーバーのコードについて
今日のゴール
0x2112A442という値を見て、「あ! WebRTC Meetupで見たやつだ!!」になる

まとめ
1. STUNのパケットは、ヘッダーと属性で構成されている
2. STUNが返すアドレス・ポート番号は、0x2112A442とのXORを計算して、NATによ るデータの書き換えを回避している
3. WebRTCでは、オーバーヘッドの少ない方式でTURNを利用している
4. STUNのパケットを見てみると、いろいろ分かる!!

sublimer

June 23, 2023
Tweet

More Decks by sublimer

Other Decks in Programming

Transcript

  1. 本日お話すること・しないこと • お話すること ◦ STUN・TURN概要 ◦ STUN・TURNのパケットについて • お話しないこと ◦

    NAT越えの仕組み ◦ STUN・TURNサーバーのコードについて • 今日のゴール ◦ 0x2112A442という値を見て、「あ ! WebRTC Meetupで見たやつだ!!」になる
  2. STUN・TURNとは • STUN ◦ STUNサーバーから見たクライアントの情報を教えてくれる ◦ LANからインターネットに出ていく際に NATされている場合、自分のグローバル IPアドレス等が分か る

    • TURN ◦ 相手と直接通信できない場合に、通信を中継してくれる ◦ クライアントとサーバーの間は UDP、TCPが使える ◦ サーバーと送信先の間は、 WebRTCの場合はUDPが使われる
  3. • STUNのパケットは、ヘッダーと0個以上の属性で構成されている • STUNヘッダーは、以下の値が含まれた20 Byteのフィールド ◦ Type(14bit): クラス(2bit)とメソッド(12bit)を組み合わせた値 ◦ Length(16bit):

    ヘッダーのサイズを除いたメッセージのサイズ ◦ Magic Cookie(32bit): 0x2112A442(固定値) ◦ Transaction ID(96bit): クライアント側で生成されたランダムな値 • XOR-MAPPED-ADDRESS属性は、STUNサーバーから見た クライアントのIPアドレス & ポート番号 ◦ Magic CookieとのXORを取っている ◦ 「一部のNATの実装は、STUNのパケットの中身までアドレスを変換してしまう」 (らしい) [1] STUNのパケットについて [1]. https://datatracker.ietf.org/doc/html/rfc8489#section-14.2
  4. TURNの通信における登場人物 • TURNクライアント ◦ NATを越えて通信したいユーザー • TURNサーバー ◦ 通信を中継するサーバー •

    ピア ◦ クライアントが最終的にデータを届ける先 ◦ ピアが別のTURNサーバーの場合もある TURN クライアント TURNサーバー ピア N A T ここはSTUNのプロトコルで通信 ここはただのUDPの通信
  5. TURNでデータを送るまで 1. Binding Request → Binding Success Response 2. Allocate

    Request → Allocate Error Response a. TURNサーバーとピアの間の通信に UDPを使うことを要求 (REQUESTED-TRANSPORT) b. このタイミングでは認証情報は送らない c. 認証情報がないのでエラーレスポンスが返される d. エラーレスポンスには NONCE等の追加の情報が含まれる
  6. TURNでデータを送るまで 3. Allocate Request → Allocate Success Response a. TURNの認証情報と

    2. で得られたNONCEなどを用いて、MESSAGE-INTEGRITYを計算する b. MESSAGE-INTEGRITY属性を追加して再度リクエスト c. 認証が成功し、XOR-RELAYED-ADDRESSが得られる 4. CreatePermission Request → CreatePermission Success Response a. 実際にデータをやり取りするための許可を得るための処理 b. 「ピアである〇〇からのデータを転送して欲しい」と尋ねる c. 許可が得られればSuccessのレスポンスが返される
  7. TURNとの間のデータのやり取り 1. Channel-Bind Request → Channel-Bind Success Response a. TURNでメッセージを送受信する方法は、

    Send、Data methodを使う方法とChannelを使う方法の2 つがある b. WebRTCの通信では、オーバーヘッドが少ない後者が使われる c. どのピアと通信するかを、 Channel Number(0x4000〜0x4FFF)で識別する 2. ChannelData a. STUNヘッダーは持たず、Channel NumberとMessage Length、Dataのみを持つ b. Dataの中身をそのままピアに送信する c. ピアから来たデータは、そのまま Dataに入れてクライアントに送る
  8. 接続終了の処理 1. Refresh Request → Refresh Success Response a. Refresh

    RequestのLIFETIME属性を0として送ることで、通信終了を表す b. 通常、Refresh RequestはAllocationの有効期間延長のために使われる
  9. STUNの属性を一部紹介 • SOFTWARE ◦ STUN・TURNサーバーのソフトウェア名が入っている ◦ coturnの場合、「Coturn-TURN_SERVER_VERSION…」のような文字列になる ◦ SOFTWARE属性を見ると、どんな TURNサーバーを使っているか分かる

    (かも) • MESSAGE-INTEGRITY ◦ STUNメッセージのSHA1-HMACのデータ ◦ ヘッダーも含めて計算するが、 MESSAGE-INTEGRITY自身は含めないため、ヘッダーの Lengthを 書き換えて計算したりするのでちょっと面倒 • FINGERPRINT ◦ STUNメッセージのCRC-32のデータ ◦ ヘッダーも含めて計算するが、 FINGERPRINT自身は含めないため、ヘッダーの Lengthを書き換え て計算したりするのでちょっと面倒