HN 日本語サマリー

← 一覧へ戻る
プログラミング

インターネットの集中化とNATの原罪

Internet centralization and the original sin of NAT (dreamstation.systems)

41 pointsby robinpie23 コメント

要約

この記事は、IPアドレス枯渇問題の解決策として導入されたネットワークアドレス変換(NAT)が、直接的なピアツーピア接続を困難にし、インターネットの集中化を招いた経緯を解説しています。NATの仕組み、ポートフォワーディングやSTUN/TURN/ICEといった回避策の限界、そしてIPv6が本来目指していた解決策がなぜ普及しなかったのかを論じ、NATがオープンなインターネットを損なった初期の要因の一つであると結論付けています。

全文翻訳

インターネットの集中化とNATの原罪 ファイル転送、Randall Munroe、https://xkcd.com/949、Creative Commons Attribution-NonCommercial 2.5 このコミックでは、一般の人がFTPサーバーを持つという概念がすぐに却下されます。そして、はい、それは一般的ではありません。平均的なコンピューターユーザーにとって、誰かがあなたのコンピューターに接続できるという考えは、エキゾチック、あるいは危険にさえ感じられます。インターネット上の他の人に自分のIPアドレスを知られることへの非常に一般的な皮肉な恐怖を見てください。ネットワークの専門家ではないがコンピューターに詳しい人が、インターネットというもののメンタルモデルはおそらく、それを個人のコンピューターとは意味のある方法で区別する「サーバー」や「クラウド」の定義を含んでいるでしょう。真のピアツーピアは、もし彼らがそれを考えたとしても、WebRTC、STUN、TURN、ICEなど、多くの労力を要する取り組みです。NAT、CGNAT、そして制限的なISPの世界に住んでいることを考えると、これは完全に間違っているわけではありませんが、オリジナルのインターネットのエレガントな設計を壊しています。 なぜあなたはFTPサーバーを持たないのか ネットワークアドレス変換(NAT)は、1994年にRFC 1631で初めて正式に提案されました。その要約には次のように書かれています。「IPインターネットが直面している最も説得力のある2つの問題は、IPアドレスの枯渇とルーティングのスケーリングです。これらの問題に対する長期的および短期的な解決策が開発されています。短期的な解決策はCIDR(Classless InterDomain Routing)です。長期的な解決策は、より大きなアドレスを持つ新しいインターネットプロトコルのさまざまな提案で構成されています。」Classless InterDomain Routingはこの投稿の主題ではありませんが、基本的に私たちは人々にネットワークサイズの選択肢を増やしましたが、実装は複雑でしたが、哲学的にはほとんど議論の余地がありませんでした。RFC 1631は、IPアドレスの枯渇とルーティングのスケーリングに対する2番目の短期的な解決策としてNATを提案しました。今日のホームルーターに遍在するNATとは正確には同じではありませんが、基本的な考え方は同じです。これは、パケットをトラフィックルーティングデバイスを通過させる際にIPパケットヘッダーのネットワークアドレス情報を変更することにより、複数のデバイスが(ルーティングデバイスの反対側のデバイスの観点から)IPアドレスを共有できるようにします。その後、特定のIPアドレスをプライベート使用のために予約し、これらはほとんどのIPネットワークで組み合わせて使用されます。ネットワーク内ではプライベートアドレスを使用し、ルーターでは1つのパブリックIPアドレスにNATします。典型的なホームルーターでは、NATを使用して外部サーバーに接続する方法は通常次のようになります。 1. あなたのコンピューターは次のようなパケットを送信します。 ソースIP: 10.11.70.21 ソースポート: 50413 宛先IP: 67.215.249.229 宛先ポート: 70 それはあなたのルーターに到達し、ルーターはそれを次のように変更します。 ソースIP: 146.7.15.85 ソースポート: 60612 宛先IP: 67.215.249.229 宛先ポート: 70 サーバーは次のように応答します。 宛先IP: 146.7.15.85 宛先ポート: 60612 あなたのルーターはそれを次のように書き換えます。 宛先IP: 10.11.70.21 宛先ポート: 50413 これを深く考えると、外部サーバーが最初にあなたと通信したい場合、どうなるのか疑問に思うかもしれません。それは146.7.15.85にパケットを送信しますが、あなたのルーターは…ああ、ダメだ。どこに送信すればよいかわかりません。 回避策 当然、人々はこれがすぐに問題であることに気づきました。なぜなら、人々はほぼ永遠に、自分の部屋からゲームサーバー、FTPサーバー、Webサーバーを実行したいと思っていたからです。そのため、NATの周りに回避策のエコシステムが成長しましたが、そのどれもインターネットの本来の意図を回復するものではなく、すべてに対応できるわけでもありません。 ポートフォワーディング 最も直接的な解決策は、ルーターに「おい、ポート60612にパケットが来たら、質問なしで10.11.70.21のポート50413に送ってくれ」と伝えることです。これがポートフォワーディングであり、ほとんどの人が認識しているNATの回避策です。ポートフォワーディングの概念的な問題の1つは、1つのパブリックIP+ポートは依然として一度に1つのデバイスにしかマッピングできないため、2つのデバイスが同じパブリックIP+ポートで同時にサービスを運用できないことです。これはあなたが思うよりも大きな問題です。小規模または単一のプライベートIPに制限されている大規模なエンタープライズまたは大学のネットワークでは、これはさらに複雑なことをせずにオンプレミスホスティングを基本的に殺します。また、ISPが外部IPをNATの後ろに置いている場合もあります。これはキャリアグレードNAT(CGNAT)と呼ばれます。そして今、あなたは変換を行っているデバイスを制御できないため、ポートを転送できません。あなたはIPアドレスのフラグメントのフラグメントを得ています。また、NATのもう1つの問題は、誰もそれに手間をかけたくないということです。だからこそ、私たちはUPnPを発明しました。 UPnP UPnPとその現代の類似体であるNAT-PMPおよびPCPは、「誰もそれに手間をかけたくない」という問題を、ソフトウェアがルーターに直接ポート転送を要求できるようにすることで解決しようとしました。手動ポートフォワーディングと同様に、これはルーターへの要求です。ISPがあなたを妨害している場合は、運が悪いです。また、誤ったセキュリティの考え方のために頻繁に無効にされます。一部には、いくつかのバグのある初期実装のため、また、誰かがあなたのコンピューターに接続できるという考えが多くの人にとってエキゾチックまたは危険にさえ感じられるためです。ファイアウォールを設置する正当な理由はたくさんありますが、もしそうするなら、NATがパケットの送信先を知らないことに依存するのではなく、意図的に実装してください。 STUN、TURN、およびICE STUN(Session Traversal Utilities for NAT)は、ファイアウォールからの協力を得ようとするのではなく、パブリックインターネット上のサーバーに「パケットがあなたに届くとき、私のパケットはどのように見えますか?」と尋ねるだけです。STUNサーバーは、NATが割り当てたパブリックIPとポート、例えば146.7.15.85:60612を返します。「コーンNAT」では、ルーターがすべての送信接続に同一の外部ポートマッピングを使用するため、これはうまく機能します。このマッピングをピアに伝えれば、ピアは直接パケットを送信できます。この技術はホールパンチングとして知られています。しかし、「対称NAT」では、CGNATや機関ネットワークで一般的ですが、各宛先に対して異なるパブリックポートが得られます。この場合、STUNマッピングは、ピアがSTUNサーバーとは異なる方法であなたを見るため、ピアに接続するためには役に立ちません。 TURN:諦める TURN(Traversal Using Relays around NAT)は、単にリレーサーバーを介してトラフィックを転送するだけで、両方の側がアウトバウンドでそれに話しかけます。これはほとんどどこでも機能しますが、不要であるはずのサーバーを実行する人が必要であり、すべてのパケットがサードパーティを経由する追加の遅延を負担する必要があるため、これは非常に残念です。 ICE:すべてを試す ICE(Interactive Connectivity Establishment)は、どの技術も信頼できないことを受け入れ、優先順位に従ってすべてを試します。直接接続、STUNで検出された外部アドレス、TURNリレーなど、すべてを考慮します。リストを相手と交換し、何かが機能するまであらゆる手段を試します。これがWebRTCが行っていることであり、今日のインターネットで得られる最良のものです。しかし、私たちは単純な直接接続を、ほとんどの場合、外部インフラストラクチャに置き換えました。 長期的な解決策ではなかったもの RFC 1631が言及していた主要な「長期的な解決策」はIPv6であり、それはこれを修正し、すべての人に真にグローバルに一意なアドレスを与え、NATを不要にすることになっていました。しかし、IPv6の採用のシグモイド関数は早期に停滞しているように見え、実装されている場合でも、多くのISPや機関ネットワークは、慣性やさらに誤ったセキュリティの考え方からNATのようなことを続けています。NATが行うようにインバウンドを拒否するファイアウォール、または完全に不必要にIPv6に実際のNATを適用することです。これは、IPv4のプライベートRFC1918スペースの使用方法と同様の方法で、ユニークローカルアドレス(fc00::/7)をデプロイすることです。これは私には不可解です。 インターネットへの影響 オープンなインターネットを破壊したと非難できることはたくさんありますが、NATが初期の要因の1つだったと思います。サーバーの実行はかつては簡単でした。実行可能ファイルを実行し、人々にアドレスを伝え、完了です。今では、運が良ければ、ポートフォワーディングを設定する必要があるかもしれませんが、CGNATの後ろにいる場合はそれができないこともよくあります。