CONBUの無線LAN構築術―カンファレンスネットワークの作り方

第3章 構築・運用時のトラブルリスクを下げるクラウド活用―機材搬入~配線~撤去までを配慮するからわかること

この記事を読むのに必要な時間:およそ 8.5 分

前章では無線LANの接続品質を高める取り組みを述べましたが,本章では,無線APからインターネットへつながる有線ネットワークの設計と構築について紹介します。限られた時間のなかで最高のパフォーマンスをあげるために試行錯誤してきた経験を,これまで設営してきたネットワークの変遷を通してお伝えします。

カンファレンスネットワークで考慮すべきこと

一般的なカンファレンスネットワークで提供されている機能は,一般家庭のホームネットワークと大きく変わりません。一番大きな違いはネットワークに接続される端末の数や同時に利用する人数です。一般家庭で同時に接続する端末の数は,多くて数台から10台程度になるかと思います。しかし,IT系のイベントであれば数百人単位の端末がネットワークに接続されることになります。そのように規模が大きい場合,一般家庭用と同じ装置や構成でネットワークを提供することは非常に難しいです。

難しい理由として,一般家庭向きのブロードバンドルータでは性能や機能の限界値に達してしまうためです。具体的に性能が不足しがちな機能としては,1つのIPアドレスを複数のユーザで共有をして通信を行うNAPT(Network Address Port Translation:コラム参照)というしくみです。一般家庭で利用されるようなブロードバンドルータであれば,NAPT可能なセッション数が数千という装置が多いです。NAPTのセッションは,ユーザが1つのWebページを開いただけでも数十セッション利用されることもあります。ほかにもさまざまなアプリケーションが通信を行っています。とくにIT系のイベントに参加する層はコアなユーザが多いため,一人あたり利用するセッション数が多くなりがちです。そのため,NAPTのリソースは容易に枯渇してしまいます。このNAPTのリソースがなくなると,ユーザが新しい通信を始めることができなくなります。ですので,機器選定の際にはNAPT可能なセッション数を確認することが多いです。

ほかにも,ネットワークに接続をしてきた端末にIPがアドレスを払い出すしくみのDHCPも,規模が大きくなるとルータに内蔵されている払い出し機能では対応できなくなる場合があります。すると,ネットワークに端末をつなぐことはできるがIPアドレスを取得できずに通信ができない状態になります。しかし,ルータなどで動作するDHCPサーバ機能の詳細な性能が表示されていることは少ないです。そのため,CONBUが構築するカンファレンスネットワークでは,別にサーバ機器を用意してUnix/Linux系OSの上でDHCPサーバを動作させている場合が多いです。

また,今日のインターネットを利用するうえで欠かせないDNSによる名前解決も,ルータのNAPTのセッションを枯渇させる要因の1つです。一般的にルータがフルリゾルバ(p.40のコラム参照)となることはなく,ISPのフルリゾルバに転送をしています。その際にもルータのリソースを消費してしまいます。そのため,フルリゾルバはNAPTが必要ないネットワーク上に設置して,名前解決が行えるようにすることが望ましいです。CONBUが構築するカンファレンスネットワークではフルリゾルバも,DHCPと同様にUnix/Linux系OSの上でサービスを動かして実行する場合が多いです。

Column NAPTのしくみ再入門

1対1で通信を行うときは,重複しないユニークなIPアドレスを用いる必要があります。しかし,家庭にあるPCやスマートフォンすべてに対してインターネット上でユニークなIPアドレスを割り当てるだけのリソースがIPv4には存在しません。そのため,インターネット上でユニークな1つのIPアドレスを家庭内や企業内で共有するしくみとしてNetwork Address Port Translation(NAPT)があります。

家庭内や企業内のネットワークはRFC 1918で定義されているプライベートアドレスを用いて構築し,インターネットへの通信はNAPTをしているケースが多いです。

PC(192.168.0.2)からインターネット上のサーバ(198.51.100.3)に対して通信する場合の動作の例を図Aに示します。

図A 通信時のNAPTの動作

図A 通信時のNAPTの動作

まず,PCが送出するパケットは①です。このときはPCに割り当てられているプライベートアドレスである「192.168.0.2」がソースアドレス(src IP)となります。その後PCに設定されているデフォルトゲートウェイである192.168.0.1に転送されます。

そのときにルータでNAPTを行います。PCから送出されたパケットの送信元IPアドレス(src IP)⁠送信先IPアドレス(dst IP)⁠送信元ポート(src Port)と,NAPT後に利用する送信元アドレス,送信元ポートを対応させる表に追加します。実装によっては利用するパラメータが少ない場合もあります。

変換した後のパケットが②です。このパケットがサーバまで到達します。②のパケットを受信したサーバは応答を返します。サーバからはルータのインターネット側のIPアドレス(203.0.113.28)を宛先IPアドレスとした③を転送します。③のパケットを受信したルータは①を②に変換する際に記録したデータを元にパケットを変換し,PCに④のパケットを転送します。

上記のような動作をすることで1つのIPアドレスを複数の端末で共有することができます。しかし,変換前と変換後のパラメータを保存しておくためにルータのリソースを消費します。

CONBUのネットワークの進化:一期網

CONBUの前身のLLNOCとして,2013年のLLまつりの際に構築したネットワークを紹介します。このネットワークは図1のようにシンプルな構成です。本特集内では,このネットワークを一期網と呼ぶことにします。一期網では,参加者が接続するネットワークとスタッフが接続するネットワーク,そして管理用のネットワークの3面のみのネットワークです。

図1 一期網(LLまつり)

図1 一期網(LLまつり)

一期網では,先述のカンファレンスネットワークで気をつけるべきポイントを押さえた装置の選定と設定を行っています。NAPTのセッション数は60,000セッション以上保持できるように設定しています。しかし,NAPTを60,000セッション以上保持できるようにしても,500人ほどの参加者が見込まれるイベントではリソースが枯渇してしまうことも十分にあります。そのため,NAPTセッションのタイムアウトを短く設定する必要がありました。

NAPTのセッションタイムアウトの時間を短くすることで,リソースが枯渇してしまうことを避けることができます。しかし,さまざまな通信やアプリケーションに影響を及ぼします。たとえば,スマートフォンのIP電話アプリやIMAP IDLEでメールサーバと接続しているメーラーなどです。NAPTする装置がパケットの内部まで識別するようなファイアウォール製品でもない限り,セッションが異常終了して残留しているのか,通常状態でセッションを維持しているのか判別することができないからです。

この一期網のNAPTの動作はTCP/UDP/ICMPすべて30秒でタイムアウトという比較的短い時間の設定をしています。それでも,ピーク時にはNAPTの限界値の約半分である30,000セッションを越えるような状態を観測しています。様子を見てNAPTのエントリのタイムアウトを変更するようなことも考えていましたが,とくに参加者からの申告などがなかったため,すべてのタイムアウトを30秒のままで運用を終えています。

一期網でのトラブルや課題

イベント本番に向けて,事前にホットステージと呼ばれる仮組みをして,装置類の設定や動作確認をする期間を設けます。ホットステージで装置を設定済みの状態にして,会場に持ち込んで設置をするだけでネットワークを提供できるようにしていました。しかし,装置を会場で動作させてみるとサーバが動作しないという問題が発生しました。このままではIPアドレスを参加者の端末に割り当てられずにインターネットへアクセスができない状態になってまうため,急遽,現地でほかのサーバに構築をしなければなりませんでした。

ビジネスで利用されるようなネットワークであれば冗長構成を組み,片系の障害であれば回避できるように設計をすることが多いと思います。しかし,カンファレンスネットワークを運用する期間はイベント開催中の数日のみです。さらに,装置類をホットステージ会場からイベント会場まで輸送しなければなりません。運搬コストや現場での設営の時間を考えると,装置の台数や複雑なネットワークは無駄になってしまいます。そのため,複数台で冗長構成にすることがすべて正しいとは言えません。

また,イベント開催日の直前まで設定などを見直したいときもあります。しかし,仮組みしたネットワークはイベント本番に向けて一度解体し,運送の準備をしてしまいます。そのため,短期間のホットステージ中にすべての設定を完了させなければならないことが,我々にとってとても負荷が高いことでした。

Column DNSのフルリゾルバとNAPT

CONBUの一期網では,DNSのフルリゾルバ注AがNAPT配下にいました。この構成は好ましいものではありません。NAPTのリソースを多量に消費するだけではありません。業界一般的に⁠毒入れ⁠と呼ばれる正しい応答に偽装したDNSのパケットを受け入れてしまう確率が増えます。DNSの毒入れは,正しい応答がサーバからフルリゾルバに到達する前に,正しい応答に偽装した偽装パケットが受け入れられてしまうことによって発生します。

通常,偽の応答を受け付けないようにするためのしくみがあります。図Bのようにsrc Portとtransaction IDで応答を認証しています。どちらも16bitのため655352通り注Bの組み合わせになります。しかし,ネットワークの大容量化や高速化によって偽の応答をつかまされやすくなっています。

図B 偽装パケットをチェックするしくみ

図B 偽装パケットをチェックするしくみ

NAPTの配下にDNSのフルリゾルバを置くと,DNSのクエリもNAPTされます。NAPTをすることによって,図B中の網かけ部分のsrc IPアドレスとsrc Portが変換されます。このときNAPTの実装によって変換のパターンが異なります。一部の実装ではsrc Portをランダムに選択せず,パターンが存在するものもあります。NAPTのsrc Port選択に一定のパターンが存在すると,DNSのフルリゾルバがsrc Portをランダマイズして送出した効果が薄れてしまいます。NAPT後のsrc Portが推測可能だとすると,TransactionIDだけの認証となってしまうため,毒入れ攻撃を受ける確率が上がります。

DNSの毒入れを防ぐために,UDPの代わりにTCPを利用する方法やDNSSECで認証を行う方法がありますが,利用されるケースはまだまだ少ないです。ですのでDNSのキャッシュに毒を入れられにくくするためにも,NAPT配下のネットワークにDNSのフルリゾルバは置かない構成にするべきです。

注A)
フルサービスリゾルバ,あるいはDNSキャッシュサーバとも呼ばれます。名前解決を行うためにドメインツリーをたどりIPアドレスのレコードを見つけ,要求元にレコードを返す動作を行います。
注B)
厳密には使えないポート番号などもあるため,655352よりも少なくなります。

著者プロフィール

高橋祐也(たかはしゆうや)

大学在学中よりイベントネットワークの構築を何度か経験し,2013年からは国内電気通信事業者にてネットワークサービスのエンジニアをしながらも,イベントネットワークの構築に何度か携わっている。


岡田雅之(おかだまさゆき)

情報系学科にて学内NW構築管理などを経て低レイヤーないろいろに目覚める。その後大規模なNWの管理・構築を経て2004年から現職(JPNIC)。IPアドレスの分配管理システムを手がけつつインターネット経路制御に関心を持つ日々。過去Vyattaユーザ会運営委員なども。2014年東邦大学研究員兼務,2016年 JANOG運営委員。なんと博士(工学)。

コメント

コメントの記入