Cerevoアドベントカレンダー2016、最終日です。といっても、どうやら大トリは弊社代表が年末までに昨年のネタの更新版を出すようなので、私はトリらしい何かとかでもなく、テックブログらしく技術ネタを書きたいと思います。
まつけんです。CTOをしています。今日はハードはほぼ関係ない、ソフトというかUDP/IP、TCP/IPな世界の話です。IPレイヤーより上でのお話です。
まず、NATと言われて動作を想像できる方どれくらいいるでしょうか。今や、ルータという名でNATが動作する機器は各家庭にほぼ設置されているのではないかと思いますし、携帯向けネットワークも昨今はLarge Scale NATもしくはCarrier Grade NATの導入という形でちょっと話題になったようにNATが導入されています。そんな世界では、グローバルIPが直接振られるのではなく、ルータやキャリア側でローカルIPからグローバルIPへのアドレス変換が行われるのが一般的です。NATと言いますが、今挙げた例は、正確に言えば、IP masquarade（マスカレード）です。NATはNetwork address translationなのでアドレス変換をするというもう少し広い意味で、グローバルIPとローカルIPが1:1で変換されるようなケースも包含されますし、サブネットを分けたローカルネットワークでの1:1や1:Nでの変換などにも利用されることもあります。
今回は、最も一般的な多:1でローカルIPからグローバルIPへとソースアドレスを書き換えて通信を行う（グローバルIPアドレスを共有する典型例）、ほぼどんな環境でも導入されていると言っても過言でなくなった、いわゆるIPマスカレードされている環境でのP2Pでの通信を実現する、NAT Traversalのお話です。
NAT Traversalとは
まず、NAT Traversal、日本語で言うと、NAT越え（NAT超えかもしれません。ここでは越えで統一します。）はなぜ必要なのか。IPv4アドレスが世に溢れ、すべてのデバイスにグローバルIPが割り当てられている状態であればそもそもNAT越えは必要ないわけですが、現実にはIPv4アドレスは足りないし、ルータ下にいない直接グローバルIPをデバイスがもつというのはセキュリティ的にも推奨されない（デバイス自身がbindしているポートへの通信をローカルネットワーク内のパケットに限定でき、脅威となるデバイスやサーバが容易に直接のアクセスがしづらい）のが現実です。そんなNATがあふれる世界でもP2P通信をしたい、という需要を満たすためにNAT Traversalという技術（というか、手法でしょうか）が考えだされるわけです。これはもうかなり昔からあるもので、様々な資料がネット上にもありますが、一度、自分の整理のためにこの記事を書いてみている次第です。
ルータの下にいるデバイス同士が直接するのはなぜそんなに難しいのでしょうか。まず簡単な通信の流れを下記図を見ながら説明します。もっとも一般的な構成として、ルータ下のネットワークをローカルネットワーク、ルータの外に存在するネットワークをグローバルネットワークとして考えます。そのときに、ルータ下のデバイスがグローバルネットワークと通信とパケットをルータの外のネットワークにあるアドレスに送ります。そのローカルネットワークの内からNATを通して外へという形で出て行く分にはルータがアドレス変換をよしなに行います。これがIPマスカレードです。やることはそんなに難しくなく、TCPの場合、ソースになったIPアドレスとポート（つまり、デバイスのIPとポート）と、宛先になるIPアドレスとポート、ソースアドレス書換後のルータ自身のグローバルネットワーク側のアドレスとポートを、最初にデバイスからパケットが来た時に組み合わせで覚えます。その上で、ソースアドレスをNATが動作しているルータ自身のIPとポートに書き換え、宛先にパケットを投げる、宛先からパケットが返ってくれば覚えてるマップにしたがって、その返信パケットの宛先をローカルネットワークにいる通信元のデバイスに書き換えてパケットを送信します。こうすることで、デバイスはソースアドレス変換が行われたことを知ることなく、外のインターネットな世界と通信ができるわけです。
NATを越えてデバイス同士が直接通信するには
これの安直な解決方法のひとつがサーバーリレーです。要はデバイス同士が同じサーバに接続をして（この場合、サーバがグローバルIPを持っているのでどちらもルータ下のローカルネットワークから容易に接続ができる）その後の通信はサーバが介在して両者で通信を行います。ただ、この方式、TCPレベルで解決するには宛先を別途アプリレイヤーで指定する必要がありますし、なによりも、トラフィックがすべてサーバを経由するので、サーバの通信量が2倍、そして、サーバを経由するため経路としてはあきらかに冗長に長くなりレイテンシが悪化します。これは、P2Pでの典型的な例である、ビデオチャットやゲーム対戦の特性に対してあまりマッチしません。
ここまで前提を並べてきて、やっと本題にたどり着きました。それぞれのデバイスがルータの下にいたとしても直接パケットをどうにかして届かせたいという必要性が出てきます、それがNAT越えです。ここからはNAT越えを単純な手法から順に説明していきましょう。まずは極めて単純なUDP hole punchingです。これはあとから紹介しますが、特定の動作をするNATでしか通用しません。ここから、NATの種別ごとにどういう形で対応を増やしていくか、というのがこのNAT越えの議論のおもしろいところです。
ここで、唐突にでてきたcone NATを含め、NATの動作によって分類をまず行いましょう。
- full cone NAT
- address restricted cone NAT
- port restricted cone NAT
- sequential port smmetric NAT
- random port symmetric NAT
というふうに考えると、NAT越えの方法と特性が分類されます。まずはconeとsymmetricの差を考えてみましょう。
cone NATはシンプルな動作です。ルータ下のデバイスがグローバルアドレスに対して通信を開始し、パケットを送信したとき、ルータはソースになるIPとポートを覚えるのみです。それにしたがって、ルータのグローバル側のIPとポートをマップします。つまり、グローバル側のIPとポートに対して、グローバル側にいるデバイスであれば誰でもパケットを送信し、それはルータ下のデバイスにパケットはアドレスを書き換え転送されます。したがって、下記のような流れを経れば、UDPによるP2P通信が可能になるわけです。
- ローカルネットワークAに存在するデバイスをαとし、ローカルネットワークBにいるデバイスをβとします。αとβが互いにUDPパケットを直接送受信できるのが最終目標です。
- αとβを仲介するサーバをSとします。まず、P2P通信を開始したいという意思をαとβで共有します。そして、通信を開始するぞとなるタイミングをSから受け取ります。
- すると、αとβはまず、サーバSに対して、UDPパケットを送信します。すると、パケットはαとβそれぞれのNATされたグローバルのIPとポートを観測することができます（ソースアドレスはNATされたルータのものが見えます）
- それをαの情報はβへ、βの情報はαへと、サーバから通知を行います。（たとえば、P2P通信開始処理の間は、サーバとの間にTCPがはられていてここでやりとりするとかです。）
- αはβのルータのグローバルのIPとポートに対して、UDPパケットを投げます。βも同様です。
- cone NATであるため、ソースアドレスやポートに制限はありませんから、それぞれのUDPパケットは無事、それぞれのデバイスに届くことになります。
さて、cone NATの場合、こういったサーバが介在してアドレスとポートを伝えるという処理はあるものの、まだまだ単純な処理で終わります。次はaddress restricted cone NATとport restricted cone NATを攻略していきましょう。
address restricted cone NAT, port restricted cone NATはそれぞれfull cone NATに比べて制限が増えます。マッピングするときに、ソースのIP、ポート以外に、宛先のアドレスを覚えるのがaddress restricted cone NAT、ポート番号までも覚えるのがport restricted cone NATです。それぞれ攻略をしていきましょう。
address restricted cone NATは割りと簡単です。要は送った宛先のIPからのパケットでないと受け取りません。でも、サーバに送ってしまえば宛先はサーバになるわけでサーバからのパケットしか受けないことになります。では、αからβに送ったパケットはどうしてもNATに阻まれるはずです。でも、ここでcone NATのもう一つの特徴が際立ってきます。
cone NATの定義のひとつに、NATの外側のポートはソースアドレスになるデバイスのポートに従います。すなわち、αがport 30000をbindしてパケットを送ったとしたら、基本的には、NATもport 30000を利用するのがcone NATです。ここからが実際のNAT越えの方法をまた流れに沿って説明しましょう。
α、βそれぞれがサーバに向かってUDPパケットを投げ、サーバはそのIPアドレスとポートを観測します。そして、それをαとβに伝える。
すると、βはαのIPアドレスとポートに対して、UDPパケットを投げます。ここで重要なのは、βはbindするポートをサーバにUDPパケットを送ったときと同じポートを使います。このとき、NATはfull cone NATであれば通りますが、address restricted portやport restricted portでは、サーバとIPアドレスもポートも違う訳ですから通りません。が、β側のNATにはαのIPアドレスとポートへのパケットが記録され、βのIPアドレスとポートは維持されるわけです。ここで、αがβのIPドレスとポートに対してパケットを投げたとします、そうすると、βはさきほどのパケットはNATに阻まれたとはいえ、NATのマッピングができあがっているため、αからのパケットはβに到達します。また、このパケットでも、αはサーバへのUDPパケットを送ったポートをbindしていればNATには同様のマッピングがβのIPアドレスとポートに対してできあがるわけです。これで、αとβはそれぞれのNATを越えて通信ができるようになりました。
ここまで、cone NATの場合のNAT越えを説明してきました。実はこれはすでによくある方式として、STUNという形で標準化されています。実際はユーザ認証なども含みますが、P2Pの経路開通を行う方式はまさにいままでの説明通りです。いくつかのアプリケーションではSTUNが実装されているので参考にしてみてください。
ここからが、難しく解決できない問題に対して考えて行く形になります。
Symmetric NATです。これはcone NATと違い、ポート番号が再利用されません。つまり、ソースとなるデバイスでポートを固定したとしても宛先によって、別ポートが割り当てられることになります。そのため、サーバで観測したとしても、そのポートを再利用する方法がないのです。
さて、この場合、どういった方法でSymmetric NATを攻略するかを考えます。Symmetricの何がツライかというと、NATの外側のポートを観測してもそれを利用できないことです。いや、それは本当でしょうか。観測できることではなく、NATでどのポートが利用されるかと言い換えられるわけで、つまるところ、NATのポートは当たるなら予測でも良いわけです。では、予測可能か、が重要になります。Symmetric NATと言われるのもを更に分類しましょう。といっても、NATの内（ソースとなるデバイスのポートは固定）から外への通信が起こった際に、ポートがシーケンシャルに変化するか、ランダムに変化するか、です。
つまるところ、方法としては、例えばこうです。ソースとなるデバイスからサーバに対して、複数のパケットを打ちます。その際、bindするポートを固定します。そして、サーバの受けるポートはパケット数分変化させます。ここでは3発のパケットをサーバに対して投げてみます。そして、サーバからポートを観測します。このとき、ポートがどう変化するかです。例えば、+1されていく、+2されていく、-3されていく、ランダムに変化する、様々なパターンが見えるはずです。ランダムに変化する場合を除いて、NATの特性を予測するわけです。+1される場合はどうするか、もう分かりますね。NAT下のデバイスが1つしかなく、ほかの通信がないと仮定すれば、αからβへの通信を同じポートをbindした上でパケットを投げます。サーバで観測されたポート番号+1されたβはパケットを投げ込みます。そうすることで、NATのグローバル側のポートは予測され、そこにパケットを投げ込めば、おそらくは疎通するはずです。
ここからが考えどころです。実際にはNAT下のデバイスは複数あって他のUDPパケットが送られてポート番号はずれるかもしれません。もしくは、同じbindしたポートから通信しても、宛先のアドレスが違えば外側のポートが変わるかもしれません。前者はリトライでカバーするか、複数のポートをつかってα、βから送ってどれかが疎通したらその後はそれを使うかなどいくつかの方法が考えられますね。宛先のアドレスが違えば届かないことを考えると、サーバも複数のIPアドレスを持ち、それぞれに対しておくったときのポート変化も観測する必要があります。このあたりから観測の方法がどんどんと複雑化していくため、これに対して、どう対処していくかがNAT越えの最大の難所です。いままで、cone NAT, SymmetricNATという類型で説明してきましたが、昨今、この類型に意味がないと言われる所以がこのあたりから始まります。（とはいえ、NAT Traversalという技術を理解するにはこの類型も私は有用だと思っています。）
とはいえ、越えられないひとつに、ランダムにポートが割り当てられるSymmetric NATは対処のしようがなさそうです。この場合のみサーバーリレーを行うというのが疎通する確率を100%にする一つの方法です。そうではなく、ランダムにポートを開けるNATに対するポート予測方法をなんらか確立できる手法もあるかもしれません。もし、すでに公知だよという場合はぜひ情報へのポインタを教えてください。
ここまでで、UDP hole punchingのなんとなくの基本を学んできました。cone NATへの対処はSTUNの仕様、規格を読んでみてください。たぶん、この文章よりはよっぽど分かりやすいです、ここまで読んでいただく方にそう言うのもアレですが。また、実際、Symmetric NATの場合の方法としては、 https://tools.ietf.org/html/draft-takeda-symmetric-nat-traversal-00 を読むのがおそらく一番詳しく丁寧です。そういった意味でも、ここでの解説は初歩の初歩です、じゃあどう実装するんだというのから、サーバで何を観測するのか、そもそもNATが複数段あったらこの手法は果たして通用するのか。観測を複雑にしていけばいくほど、開通までの時間がかかります、それは本当にターゲットのアプリケーションにとって許容できるのか。Large Scale NATではこの穴開けが通用するのか、キープアライブはどうするか、セキュリティ的に必要な相手のパケットだけを見分けられるのか、認証はどうするか等、現実世界では、この抜け穴のような手法に対しての課題は山盛りです。そんなところの実地調査として、UDP hole punching自体はあまり表に見えない手法ではありますが意外なところで結構導入されていたりしますので、とあるゲーム機なんかで、P2Pで対戦通信しているな？とおもったときに、パケットキャプチャしてみるのもオススメです。
さて、最後に、いままでは、UDP hole punchingをベースに説明をしてきましたが、ではTCPの場合はどうなるでしょうか。まず、TCPにはcone NATという概念はまずあり得ません。それは、宛先との通信はステートをもって（つまりシーケンス番号を使って）通信されるため、宛先を限定しないポートマッピングというのはほぼ意味がありませんし、ほかのパケットを転送するというのはただのセキュリティホールです。なので、通常は、上記類型で言えば、Symmetric NATしか存在しません。また、さらに面倒くさいところが、TCPの通信シーケンスの始め方です。接続元はSYNパケットを送り、接続先はSYN、ACKをセットにして送ります、そして、接続元からACKが送られて、はじめてTCPでの通信は始まります。つまり、UDP hole punchingのように最初の一発のパケットはなかったことにするわけにはいきません。あくまで、SYNパケットは両者に届かないわけにはいかないのです。この通信開始の流れを3-handshakeと呼びます。
でも、それでもTCPでNATを越たい、という人にはヒントはあります。まず、TCPでの仕様では、3-handshakeだけでなく、4-handshakeでも問題なく通信は開始できます。つまり、αからSYN、βからもSYN、その後、双方からACKが送信されるようなケースです。ここから見えてくるのは、要はSYNをUDP hole punchingの最初のパケットとしてつかって複数送ったとしてもひとつだけ届けば通信は確立されるということです。これは、どこかで少し話題になりましたが、TCPの仕様に実際、TCP Simultaneous Openという名前で記載があります。ここまでくればあとの考えは分かりますね。これで、Symmetric NATと同じ手法でNAT越えはおそらく可能になります（これは私は実際に実装したことはないので、たぶん）
さて、というわけで……。ざっと、通常言われるNAT Traversalの手法の入り口を紹介してきました。STUN以上のもので簡単な実装を見られるものはいくつかあります。また、Symmetric NATへの対処の実装も、いくつかGitHubを漁ればでてきます。 https://github.com/zerotier/ZeroTierOne など。
とはいえ、NATの越方は様々、この上でどういう通信をするかも様々です。UDPでしか通信できない経路ではアプリケーションでは使い勝手が悪い場合もあります。そういう場合には、TCP over UDPを実装してあげてVPN的に使うのもよいかもしれません（OpenVPNが使っているようなTUN/TAPデバイスという仮想トンネルデバイスはLinuxではよく使われますね）また、NATに関わらず通信するためのサーバリレーの方法としてはメジャーなのがTURNを使った実装でしょうか。越えられなかったらTURNをつかってサーバリレーをするというところまでフローを実装するとより使いやすくなります。また、今回は出てきませんでしたが、ルータに実装されているUPnP実装では静的なポートマッピングが可能なものが多く存在します。UDP hole punchingとは別の方法で、NATの外→内の通信を可能にできる方法なので、こちらも組み合わせるとより多くのNATに対応できるはずです。でも、この場合も複数段NATがある場合はじゃあどうする、みたいなことがなかなかに難しいポイントです。まずは、ローカルネットワークとグローバルネットワークを見分けるような方法を実装しなければなりません。方法はいくつかありそうですが、ICMPでTTLを変化させて使うとできそうな気もします。要はtracerouteですね。
昨今、IPv6も徐々に普及し始め、NAT Traversalは不要になるかと思っていましたが、NATはIPマスカレードではなく、1:1のアドレス変換として生き残る雰囲気も少しだけ感じます。そんな中で、意外にNAT Traversalは必要とされる技術なのかもしれません。WebRTCは特性上、P2P通信ができれば好ましく、NAT TraversalもSTUNなどを使って行われるケースもあるようです、同時にTURNも使われる例の最たるものとしても。
今後どうなっていくか
さて、最後に、将来はというところを少し。これまでは、UDP/TCPの話をしてきました、それ以外もあります。SCTPが一番最有力なのではないかと思います。現状、メジャーではないものの、すでに実装はLinuxではしっかり入っていますし、途中経路のルータさえしっかり対応すれば（これが一番大変なんですが）、様々な課題を解決しています。ここから、SCTPを解説しはじめると、この記事はいつになっても終わらない形になってしまいますので、NAT Traversalにまつわるアレコレはここまでで一度締めさせていただきます。年末年始の空いた時間でSCTPを調べていただくときっと楽しいのではと思ったりしています。
最後に
この記事が果たしてアドベントカレンダーの最後に相応しかったかどうかはよくわかりませんが、NAT Traversalという古くからあるけれどマイナーな、でも、結構有用だと思っている技術の導入となる方がいたりすると幸いです。
途中から図がなくなったのは気力が間に合わなかったので、後で追加できたらしたいなと思っています。
著者プロフィール
![[1日目] 高価な市販NASを買わずに、HDDがクラッシュしても大丈夫な運用しやすい社内のファイル共有サーバを構築する方法](/wp-content/plugins/vk-post-author-display/images/thumbnailDummy.jpg)
