「家庭用ルーター」って何をする機器？ 中ではどんな処理が行われている？

ルーターとしての仕事はネットワーク層で行われる

　現在のホームルーターに求められるものは、一にも二にも、高いパケットの転送性能である。実際の通信速度はISP側の設備やインターネット回線の混雑状況など外部要因の影響を受けてしまうが、有線、無線（Wi-Fi）ともにホームルーター単体で十分な速度が出せることが重要である。

　以下の図を見ていただきたい。これらの図はホームルーター内部におけるパケットの流れを理解してもらうためのもので、図1は、インターネットのTCP/IP 4階層モデルを示したものである[*6]。もう1つの図2は、ホームルーターにおいてパケットの転送制御がどこで行われているかをTCP/IP 4階層モデルを使い概念的に示したものである。図では単に「物理層」と書いたが、そこは「イーサネット」「無線LAN」「PPP」のいずれかが該当すると考えていただきたい。

図1　インターネットのTCP/IP 4階層モデル

図2　ホームルーターにおける基本的なパケットの流れ

　ただ、この図2の説明では具体性が見えないので、図3を描いてみた。この図は筆者がイメージを説明するために描いたものなので正確ではないが、だいたいの雰囲気はつかんでいただけると思う。説明上、LAN側にある端末から送信されたパケットが、ホームルーター内でどう処理されるかの部分だけに限定している点はご了解いただきたい。

図3　ホームルーターにおけるパケットの処理イメージ

　ここで特に見ていただきたいのは、図3にある「送信先となるIPアドレスを参照して判定」しているという部分である。

　インターネットでは、エンドツーエンド（end-to-end）で通信を行う。この仕組みでは、ネットワークは余計なことをせずに純粋にデータを目的の相手まで運ぶだけで、通信制御やエラー検知など高度な処理は「end（終端）」となるシステムで行う。このことを念頭に置いていただいたうえで説明すると、パケットの送信先となるIPアドレスを参照することで、ホームルーターは単なるネットワーク上の通過点であるのか、ホームルーター自体が終端となるのかが判定できる。つまり、自分自身が通信上の終端でなければ、入ってきたパケットの転送処理を淡々と行なえば良いのである。

　一般的に、インターネット利用者が発生させる通信のほとんどはWebアクセスによるものである。その際に入ってくるパケットの宛先は通信したい相手先のサーバーになるであろうから、ほとんどがネットワーク層の中だけで処理される（図2の薄い青の部分）。

　また、概念的には、LAN内でIPv6のグローバルIPアドレスを使用している場合、IPoE回線での通信であればプロトコル変換不要で直接転送できる。一方、プライベートIPアドレスを使用したIPv4のパケットの場合は、NATの処理や、必要に応じてカプセル化[*7]の処理が途中で加わるなど、複雑なものとなる（NATは、ネットワーク層の処理である）。

　読者の中には「それだけ？」と感じる方もいらっしゃると思うが、そもそもとしてIPというプロトコルは（特にルーターが行う）転送にかかる処理を単純化して高速化することを目的の1つとして設計されている[*8]。それがゆえに処理のハードウェア化が可能であり、実際に多くのホームルーターで専用チップが使われている。

　ちなみに、よく聞く誤解として、LAN内にある端末とホームルーター間にはセッションが張られていて、その張れるセッション数がルーターとしての性能を決めるというものがある。このような誤解が起こる理由は不明だが、通常、Webアクセスをする際に端末とホームルーターとの間にセッションが張られることはない[*9]。

　端末（のアプリケーション）がセッションを張る相手は、通信相手となるサーバーである[*10]。ホームルーターは、ただひたすら入ってきたパケットにNATやプロトコル変換など必要な処理を加えて転送するだけである。

NATにおいて管理テーブルが持つエントリー数はとても重要

　次に、NATについて簡単に説明する。多くの方がご存知のように、NATは1つのグローバルIPアドレスを複数の機器で共有するための仕組み（IPアドレス変換技術）である。初期のNATはIPアドレスのみを対象としていたが、その発展形としてポート番号もその対象とするNAPT（Network Address Port Translation）が誕生した。今では、このNAPTがNAT技術の主流である。

　NAT（NAPT）は、LAN内で使われるプライベートIPアドレスとインターネットで使われるグローバルIPアドレスをポート番号まで含めてアドレス変換する。図4はその際に使われる管理テーブルのイメージで、通信開始時に登録（エントリー）してその通信の管理を開始し、通信終了時にそのエントリーを削除して管理を終了する。

図4　NATテーブルのイメージ

　ここで考えなくてはいけないのは、NATテーブルのエントリー数には上限があるということである。例えば、その数が1024だとすると、1024という上限を超えると新規の通信ができなくなる。現代のアプリケーションは多数のポートを使用して同時に複数のセッションを張るため、想像以上にNATテーブルは消費されてしまうのである。したがって、このNATテーブルのエントリー数は多ければ多いほど良い。

　では、NATテーブルのエントリーは、いつ削除されるのであろうか。TCPの場合はプロトコル上、FINでコネクションの終了を検知することができるため、そのタイミングでエントリーを削除すれば良い。しかし、UDPの場合は通信の終了を検知することができないため、無通信時間をもとにタイマーを使用するかたちでエントリーを削除するしかない[*11]。NATにとって、UDPは扱いが難しいプロトコルなのである（DNSは、基本的にUDPを使用する）。

　余談めくが、ホームルーターにおいてNATテーブルのエントリー数は搭載するメモリの量に依存するため、ハードウェア的に決まってしまうことが多い。また、最近ではセキュリティ対策としてSPI（Stateful Packet Inspection）という機能を使用するものも出てきている。SPIとはセキュリティ機能の1つで、外部からの攻撃対策として、例えば内側から通信を開始した場合の戻りパケットのみを受け取るようにする（それ以外は弾く）ものである。SPIもNATテーブルのような管理テーブルを持つことから、そのエントリー数で通信可能な数が制限されてしまうということが起こる。

　SPIは主としてIPv6で使われるが、IPv4でもSPIは使えることから、ホームルーター側の構成によっては、IPv4使用時にはNATだけでなくSPIのテーブルエントリー数にも気を配らなければいけないとことにもなる。ホームルーターが搭載するメモリの量がますます問われることになりそうである。

　NATを使用する場合には別の視点として、例えばCGN（Carrier-Grade NAT）やIPv4アドレスの共有サービス（MAP-EやDS-Lite）などを使用する際の問題も考えなければいけない。それらサービスを使用している場合は使えるポート番号が（256とか512、1024というように）著しく少ないことから、送信元ポート番号の枯渇という問題が発生しやすい。この場合は、NATテーブルのエントリー数に余裕があってもポート番号の不足によって通信に制約が出てしまう場合もあるという点にも注意が必要であろう。NATは便利な機能であるが、デメリットも多いのである。

利用者の利便性実現とフォワーダーとしての機能で構成されるDNS機能

　DNSに詳しい方はご存知だと思うが、DNSによる名前解決は、「スタブリゾルバー」「フルサービスリゾルバー」「権威DNSサーバー」という異なる3種類の機能[*13]が連携することで実現される（図6）[*14]。

図6　DNSによる名前解決

　動作としては、利用者が使用する端末からアプリケーションがスタブリゾルバーを呼び出し、フルサービスリゾルバーに向けてクエリを送信する。この例では「www.example.jpのIPアドレスを教えてほしい」という問い合わせ内容にしてあるが、フルサービスリゾルバーはそれを受けてドメイン名をなぞるように権威DNSサーバーに問い合わせを行う。最終的には「example」のゾーンを管理している権威DNSサーバーに当該データがあるので、その結果が最初に問い合わせをしたスタブリゾルバーに戻されるという流れになる。

　では、こうした仕組みの中でホームルーターはどの位置に存在し、何をするのであろうか。それを示したのが図7である。図ではクエリの流れしか記述していないが、DNSの応答（レスポンス）では逆のことをするだけである（説明では、IPv4のネットワークであることを前提とする）。

図7　DNSの仕組みの中でのホームルーターの位置と役割

　ホームルーターはLAN内の端末に自分自身をDNSサーバーとして見せているため、端末から送信されたクエリは一度ホームルーターで終端する。その後、受け取ったクエリのヘッダを書き換えて（送信元をホームルーターのグローバルIPアドレスに書き換え、送信先をホームルーターに登録されているフルサービスリゾルバーのグローバルIPアドレスに書き換えて）フルサービスリゾルバーに送信する。フルサービスリゾルバーが得た結果は送信元であるホームルーターに送信され、ホームルーターは大元のクエリを送信した端末のスタブリゾルバーにその結果を応答する。

　分かりやすく言うならば、ホームルーターは、DNSパケットのヘッダを書き換えてクエリを転送（forwarding）[*15]しているだけなのである。そして、この機能のことを「フォワーダー（forwarder）」と呼ぶ[*16]。

　以上は、インターネット全体での名前解決の話であるが、ホームルーターのDNS機能にはインターネット上での名前解決をしない部分もある。例えば、ホームルーターの設定画面をドメイン名のようなかたちで呼び出せるようになっている（前述の図5のスライドでは「web.setup」）けれども、それを実現するためにHOSTS.TXT[*17]を使っていたりする。また、セキュリティ関連など利用者に提供するサービスとリンクするための情報も、ホームルーターのDNS機能に含まれるはずである。イメージ的には図8のような感じになるであろうか。

図8　ホームルーターが持つDNS機能のイメージ

　そういえば、先の記事では、不具合の回避策として報告にあった通り「通信に問題が出たユーザーはホームルーターのDNS機能を使わずにISPのキャッシュDNSサーバーやパブリックDNSを使うようにする」と書いたのだが、この方法をそのまま使うと、設定時は良いが、元に戻そうとするときに設定画面が従来の方法（名前で呼び出す）でできないということが起こる可能性が出てきてしまう。これは、ホームルーターのDNS機能を使うことができなくなるからである。ネットワークの仕組みが理解できていてIPアドレス直打ちでアクセスできる人もいると思うが、そうでない人は困ってしまうかもしれない。

　ホームルーターの内部や仕様に関する情報はなかなか表に出ないため、推測が多く、まとまりがないが、ホームルーターが持つDNS機能は利用者の利便性のためにあるのであって、インターネットにおけるDNSという面から見ると多くの場合でフォワーダーとしての機能しか持ち合わせていない。

　ちなみに、図3では図が複雑にならないようにそう描いたのだが、本来はトランスポート層の部分はプロトコルごとに用意されるものである（図9）。例えば、古いホームルーターでDNS機能としてのフォワーダーがTCPによるクエリを処理できなかった場合、トランスポート層でTCPがサポートされていない可能性がある[*18]。また、新しいプロトコルとしてのQUIC[*19]は、ルーターから見ると他のUDPの通信と同じように扱われる。

図9　トランスポート層の部分はプロトコルごとに用意される

DNS機能にはTCPとEDNS0のサポートが必須

　市中にあるホームルーターの中には、512バイトを超える大きさのDNSメッセージを扱えないものが存在すると言われる。おそらく、古い時代のものであったり、価格のために必要な仕様を切り落とした製品であったりするのだろうが、そのようなホームルーターを使用しているとDNSの名前解決がうまくいかず接続に問題が生じる可能性が高い。

　時期を失念してしまっている[*20]ので恐縮だが、かつてAppleのiOSの配布においてAリソースレコードのレスポンスが512バイトを超えてしまい、それを正しく処理できない環境下で接続障害が起こったことがあるはずである[*21]。また、2011年にはJPCERTコーディネーションセンター（JPCERT/CC）から、「大きなサイズのDNS応答の取り扱いの問題」という注意喚起も出ている[*22]。このように、サイズの大きなDNSメッセージ問題は古くから存在する。

　インターネット技術の標準化を推進するIETF（The Internet Engineering Task Force）では、この問題の解決策として2013年に、DNSのプロトコルを拡張する「EDNS（Extension Mechanisms for DNS）」という仕様を策定した[*23]。EDNSでは、バージョンを示すために「EDNS0」もしくは「EDNS(0)」と記述する。

　EDNS0はその名の通り、DNSのプロトコルを拡張するものである。TCPにフォールバックせずに、通信にかかる負荷が小さいUDPのまま512バイトよりも大きなDNSメッセージを扱えるようにするものだ。そして、DNSをIPv6やDNSSECに対応させる際にはこのプロトコルが必須であるとしている。

　ちなみに、DNSメッセージサイズの大きさが512バイトとなったのは、IPにおいてパケットがネットワークの経路上で分割されずに届く大きさとして決められている576バイト[*24]に、UDPヘッダとDNSのメッセージが収まるようにしたためである。

　TCPについては先の記事に書いた通り、2016年3月に発行されたRFC 7766[*25]により、UDPを使用せず最初からTCPで問い合わせしてもよいことになっている。つまり、最初からTCPを用いたクエリを出すことは何ら問題が無いのである。

　このところDNSのメッセージサイズは増加する傾向にあり、512バイトでは足りないということがまま起きるようになっている。そう考えると、TCPやEDNS0のサポートは、ホームルーターにとってすでに必須のものであろう。サポートされていないホームルーターは選ぶべきではないとさえ言える[*26]。