家庭のルーターに何となく守られている今のネットは、最初からそうだったわけではない。この記事は、NATがIPアドレス不足の応急処置として入った結果、インターネットの「誰からでも直接つながる」という前提が少しずつ壊れていった、という話をたどっている。ファイルを送り合うだけでも面倒になり、ゲームや配信、WebRTCのような仕組みが複雑化した理由もそこにある。著者は、NATを単なる便利な仕組みではなく、オープンなインターネットを早い段階でねじ曲げた存在として見ている。
元記事は、xkcdの「普通の人がFTPサーバーを持っている」ような絵を起点にしている。昔のインターネットなら、自宅でサーバーを立てて相手に自分の住所を知らせれば、それで終わりだった。しかし今は、相手が先にこちらへ接続してくる、という発想自体が珍しくなった。著者はこの感覚の変化が、NATやCGNAT、そして接続制限の強いISPによって当たり前になったものだと説明する。
NATは1994年のRFC 1631で正式に提案された。背景にあった問題は、IPアドレスの枯渇と、ルーティングの拡張だった。CIDRも同じく短期的な対策だが、こちらはネットワークサイズの扱い方を変えるだけで、思想としては受け入れやすかった。一方のNATは、複数の機器で1つのIPアドレスを共有できるようにする技術だ。ルーターがパケットのヘッダーを書き換え、内側の私的なアドレスと外側の公開IPを対応づける。例えば、10.11.70.21:50413 から 67.215.249.229:70 へ送った通信は、ルーターを通ると 146.7.15.85:60612 からの通信に見え、返信はまた元の端末へ戻される。
ただし、この仕組みには最初から弱点があった。外部のサーバーがこちらへ先に話しかけたいとき、ルーター側は「どの端末に届ければいいか」を知らない。つまり、外からの着信を自然には受けられない。そこで、ポート転送、UPnP、NAT-PMP、PCP、STUN、TURN、ICEといった回避策が次々に生まれた。ポート転送は、特定の外部ポートを特定の端末へ手動で割り当てる方法だが、1つの公開IPとポートの組み合わせは同時に1台分しか使えない。大学や企業のように、そもそも割り当てが極端に少ないネットワークでは、それだけで運用が苦しくなる。さらに、ISP側でCGNATが使われていると、利用者は自分のルーターすら制御できないため、転送設定そのものができない。
UPnP系はソフトウェアからルーターに自動で穴を開ける考え方だが、セキュリティ上の不安から無効化されがちだ。著者は、NATに頼って「届くべきパケットが届かない」状態を作るくらいなら、きちんとしたファイアウォールを実装すべきだと述べる。STUNは外部から見える自分のIPとポートを知るための仕組みで、cone NATならhole punchingで直接接続できる。しかし symmetric NAT では宛先ごとに外向きポートが変わるので通用しない。TURNは中継サーバーを経由する方式で、ほぼどこでも動くが、そのぶん遅くなり、第三者のサーバー運用も必要になる。ICEはこれらを全部試して、つながる方法を総当たりする。WebRTCが実際にやっているのがそれで、著者は「今のインターネットで得られる最良のやり方」だと言う。
本来、NATが埋めるはずだった長期的解決策はIPv6だった。全員に固有のアドレスを配れば、NATは不要になるはずだったが、IPv6の普及は途中で失速したうえ、導入されても古い発想のまま内部でNAT的なことを続けるISPや組織がある。著者は、IPv6でさえ不必要に NAT をかけたり、Unique Local Addresses をIPv4の私設アドレスのように扱ったりする運用をかなり不可解だと見ている。
この記事でいちばん面白いのは、NATを単なる技術的な小細工ではなく、インターネットの文化を変えた装置として扱っている点だと思う。NATはアドレス不足への現実的な答えだった。しかしその副作用として、外から自分へ直接つながるという感覚が消えた。しかも多くの人はそれを「安全になったから」と受け取った。ここが厄介だと思う。安全のつもりで広まったものが、実際には通信の対称性を壊し、「外向きにしか話さない端末」が標準であるかのような感覚を作ってしまったからだ。
この見方は、いまのクラウド中心の設計にもつながる。スマートフォン、家電、ゲーム機、PCまで、まず外へ接続し、クラウド経由でつながる。相手が自分へ直接来るのではなく、両者が共通の中継点へ出ていく形だ。著者はそこをNATの帰結として見ているが、私はそれに加えて、アプリ設計側もその前提に深く乗ってしまったのだと思う。いったん「外部から入れない」環境が普通になると、プロダクトはその制約に合わせて進化する。すると、逆に直接接続できる環境があっても、使い道が用意されなくなる。
元記事はIPv6を「本来の解答」として置いているが、実際には技術があれば自然に戻れるわけではない。ここで効いてくるのは、運用の習慣だと思う。企業やISPは、NATがあった時代の「とにかく内向き通信は閉じておく」という感覚を、そのままIPv6へ持ち込んでしまうことがある。そうなると、アドレスの広さがあっても、接続の思想は狭いままだ。技術の世代交代が起きても、管理の癖までは勝手には更新されない。
ここで重要なのは、NATが悪者だからすべて元に戻せばいい、という単純な話ではないことだと思う。家庭内ネットワークの保護や、回線事情による節約には確かに意味があった。ただ、NATを「セキュリティ機能」と誤解したまま標準運用にしてしまった結果、直接接続の価値を学ぶ機会が減った。技術者でさえ、まず STUN、TURN、ICE を思い浮かべるようになったという著者の指摘は、その変化の大きさをよく表している。
この話はネットワークの昔話ではなく、今どんなサービスが作りやすいかに直結していると思う。NAT環境では、ちょっとしたファイル共有でも、ゲームでも、遠隔操作でも、まず「届くようにする」ための前処理が必要になる。そうすると、個人が自分の機器で何かを公開するコストが上がる。結果として、誰かが用意したクラウドやプラットフォームに乗るほうが簡単になる。著者が「自宅のPCでメールもサービスも動かすのが難しく、高くつく」と書いているのは、その構造のことだ。
私は、NATの最大の罪は通信を止めたことよりも、「普通の利用者がサーバー側に回る発想」を地味に消したことだと思う。人々は受け手であり、利用者であり、作り手でもあるはずだったのに、いつのまにか全部がクライアントとして扱われるようになった。そうなると、サービスの設計も集中しやすくなるし、代替も育ちにくい。この記事は、その変化を懐古ではなく構造として捉えている点が鋭い。
WebRTCの世界がやたら面倒なのは、技術が未熟だからというより、ネットワークの前提が壊れているからだというのがこの記事の主張だ。ICEは「何をやっても確実ではない」現実への妥協で、直接接続、STUN、TURNを順に試す。つまり、理想の単純さを諦めて、外部のインフラを積み上げて成立させている。ここには、インターネットが本来持っていた対等な接続より、現実の回線事情と運用制約が勝ってしまった感じがある。
ただ、私はここに少しだけ別の見方もあると思う。P2Pや自宅サーバーの復権を語るとき、しばしば「昔は簡単だった」が強調されるが、実際には当時から運用や保守の負担はあったはずだ。それでもなお、NAT以前のほうが「直接つなぐ」ことの意味ははっきりしていた。今はその意味を知る人ほど少数派になっている。この記事が刺さるのは、単に技術の話だからではなく、インターネットがどんな前提の上で成り立っていたかを思い出させるからだと思う。
