前章では無線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の上でサービスを動かして実行する場合が多いです。

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

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

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

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

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

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

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

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

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

CONBUのネットワークの進化：二期網

二期網では図2のように、一部機能をクラウドサービス上の仮想サーバ（以下、リモートサイト）で動作させる構成にしています。理由は、一期網の設営時に発生したような問題を避ける方法を検討していたからです。しかし、リモートサイトだけに機能を持たせることに不安があったため、会場内とクラウドサービスの仮想サーバの両方に同じような機能を持たせています。一期網には存在しなかったリモートサイトができたため、会場内からリモートサイト内のサーバにアクセスできるようにする必要があります。二期網では、簡単な設定でサイト間のVPNを構築できるOpenVPNを利用して接続をしています。

それ以外の違いとしては、一期網に比べて参加者が接続されるセグメントが増えています。また、サーバ類がユーザセグメントに直接足を出していた構成をやめて、サービス提供用のサーバ専用セグメントにしています。これは、リモートサイトと会場とで切り替えを簡易化するためにこのような構成となっています。

ほかは一期網とほぼ同じ構成で二期網を構築しています。DNSのフルリゾルバをNAPTしているネットワーク内に設置せずに済んだことが一番効果がありました。フルリゾルバは名前を解決するために複数のサーバにクエリが投げられます。CNAMEやNSを外部名で指定しているドメインの名前解決は通常よりも多くのクエリが投げられるため厄介です。そのような通信がNAPTのセッションを消費しなくなるのでリソースに余裕が生まれます。また、DNSを利用した名前解決のリスクを軽減することにつながりました。

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

この二期網では、大きな問題は発生せずにカンファレンスネットワークを提供することに成功しています。しかし二期網の課題として、リモートサイトと会場の2つのサーバを構築する必要があり手間がかかります。また、持ち込み機材は一期網と変わらない状態です。さらに、OpenVPNを利用しているため会場内のサーバ内で仮想ルータを設定する必要がありました。その結果、複雑になり、運用する人間が苦労することになりました。

一期網から二期網と構成が変わったことで結果は良くなりましたが、我々の負担も同様に増加してしまいました。このときから、省力化を目指して次のネットワークを検討するようになります。

CONBUのネットワークの進化：三期網

三期網のネットワークでは過去の2つの設計から大きく変更しています（図3⁠）⁠。前回の二期網の課題だった、構築にかかる手間を最小限にすることを目指してネットワークを設計しています。また、今まではイベントごとに構築を行っていましたが、三期網の構成はほかのカンファレンスネットワークでも再利用できるようにしています。

手間を最小限にして再利用することにした理由は、CONBUという団体として活動をするようになったためです。イベントごとにネットワークを設計して構築し、検証を行い設営をするのはとても大変なため、少しでも楽にできれば良いと考えています。

そのための解決策としてすべての機能をリモートサイト側で行うことによって、会場側のネットワークがシンプルになるように設計しています。結果として、会場内にはリモートサイトと会場をつなぐための「VPNルータ」と「スイッチ」と「無線アクセスポイント（AP⁠）⁠」のみとなり、サーバ類を持ち込む必要がなくなります。

サーバ類を持ち込まないことによって、運搬する装置も多少減らすことが達成できています。それ以外にも、NAPTを行うためのソースアドレスを複数個用意することでスケールをさせることが可能になります。二期網で改善されていたフルリゾルバに、グローバルアドレスを直接割り当てることが可能なことも引き継がれています。

リモートにネットワークを構成する機能の大半を置くことによって、ホットステージも遠隔で効率的に行えるようになります。また、設定後に検証などを行う時間も以前に比べて多く使うことができるようになります。

三期網の詳細

会場側のネットワークは一期網や二期網に比べて簡易になりました。しかし、リモートサイトの構成は図3を見ると複雑になっているように見えます。1台のルータにまとめることも可能でしたが、あえて役割を分割することによって後の構成変更に備えた結果です。NAPTをしてインターネット接続を提供している層と、プライベートアドレス空間のルーティングをしている層、会場とのVPNを終端している層の三層構造になっています。

NAPTをしてインターネット接続をしている層はボトルネックになりやすいため、スケールしやすいように分離をしています。たとえば秒間の新規セッション開始数がルータの性能上限を上回ってしまった場合は、他の実装に変更したり新しく追加しなければなりません。そのときに複数台のNAPTする装置にトラヒックを分散させることが可能になります。

また、CONBUのリモートサイトに接続できるように設計しているため、リモートサイトに接続する方法を用意しています。LL DiverやYAPC::Asia 2014のときは、インターネット経由や研究用の網などから会場とリモートサイト間の接続が可能でした。そこで接続方式や網の違いを吸収するために、会場とのVPNを終端している層を分けています。

サイト間接続で用いられている技術

この三期網で会場とリモートサイト間を接続しているのは、IPsecを用いたトンネルです。二期網のOpenVPNから変更しています。よくトンネルに用いられるプロトコルを比較した表1を見ながら、その理由を説明します。

二期網で利用していたOpenVPNは、Unix/LinuxやWindowsなどのOSで動作させるのは簡単にできます。しかし、ルータという装置での実装を見たときに利用できるケースはごく稀まれです。そのため、OpenVPNのためにサーバを動かさなければなりません。三期網は先述のとおり、可能な限り運搬する装置を減らすことを目指しているため条件に合わないと考えました。

GREは実装としては多くありますが、IPのプロトコル番号として47を利用するためNAPTを配下で利用することができない環境があります。

IPsecは、ルータやUnix/Linux系OSにも実装があります。また、NAT Traversal（NAT越え）機能を用いることでNAPT配下にいる場合でもトンネルを確立することが可能です。

このようにして適切なプロトコルを選んだ結果、会場とリモートサイト間はIPsecでトンネルを張ることにしました。安全に暗号化用の鍵を交換するためにIPsecで用いられるIKE（Internet Key Exchange）には、IPアドレスも認証に含めるMainモードと、IPアドレスは認証に含めないAggressiveモードがあります。CONBUではAggressiveモードを採用しています。会場によって左右されるIPアドレスに依存しない設計にするためにも選択せざるを得ませんでした。また、NAPT配下のネットワークしかないような環境でもカンファレンスネットワークの提供を可能にするために、NAT Traversalも有効にしています。

三期網の設営準備と結果

カンファレンスネットワークの設営は通常、事前に設営を完全に行うことは難しく、何かしらの不確定要素を抱えたまま当日の設営にのぞむことになります。CONBUでは一期網以後、不確定要素を徐々に減らしていきました。一期網では、すべてのサーバ、ネットワーク機器を現地に持ち込んでいたところを、三期網では基本的に無線APとVPNルータを接続するだけの構成になりました。

ここまで不確定要素を削った三期網ですが、どうしても事前にはっきりとしない部分が残りました。カンファレンスネットワークではカンファレンスだけのために存在する建物に構築することはほとんどなく、何らかの組織のネットワークの一部を借用して会場の隅々までネットワークを提供します。ここで難しいのが、対外ネットワークと会場、サーバ設置場所で一意に設計しなければならない要素の扱いです。IPアドレスだけではなく、VLAN番号についてもケアが必要になります。付加的に会場のネットワークを借用する場合、そのポートがいわゆるTag VLAN[1]となっているのか、それともPort VLAN[2]で、後で何らかのVLAN番号が付加されるのか、など会場ごとに調査・調整が必要になってきます。とくに、ある建物とある建物を接続する場合、組織ごとにVLAN番号を重複しないようにケアをして、全体としてVLAN番号の重複などが発生しないようにしなければなりません。

ここまでVLANに関する準備をしても、ネットワークの疎通がなかなかうまくいかなかったというのが三期網の当初の設営結果となりました。少しぼやかした言い方になりますが、三期網の提供開始時に時間を要したのは、このような低いレイヤでのトラブルが複数発生したため解析を行っていたからです。とはいえ、三期網の構成はVPNルータを接続して無線APを予定の設置場所へ設置するのみで設営が完了するため、運搬時の故障・紛失などの大きなリスクを回避することができ、短時間の設営が可能であることが実際にわかりました。

三期網のデメリット

三期網の構成にすることによって、設営や設計の時間を大幅に減らすことができました。しかし、メリットばかりではなくデメリットもあります。

暗号化や復号化を経た後にリモートサイトを経由してインターネットに接続しているため、直接ISPなどを通してインターネットをするよりも通信遅延が発生します。そのため、TCPを用いた通信であればウィンドウサイズの制限により1セッションでの通信速度の低下が考えられます。これはデメリットでもありメリットであるとも言えます。カンファレンスネットワークでは、1人のユーザに帯域を独占されるようなことを防ぐことになります。よって、ほかの参加者への影響を軽減することにつながっています。

ほかにも、リモートサイトにすべての機能を置いているため、会場とリモートサイト間を接続できなければすべての機能が止まってしまうという問題があります。そのため、事前の接続検証を確実に行う必要がありました。LL DiverやYAPC::Asia 2014ではこの部分に起因したトラブルは発生しませんでした。しかし、その後の他イベントで別の装置を使ってIKEをフィルタしていたことが原因で、通信できない問題が発生して肝を冷やしたこともあります。

ルータにとって暗号化を行うのは高負荷な処理です。そのため装置の性能も必要になります。この点に関しては、VPNの性能を高めた小型のルータなども比較的手に入れやすくなっているため大きな課題とはなりませんでした。

取得するべきログ

カンファレンスネットワークの運用でも、ログは確実に取得するようにしています。参加者がネットワークに接続するPCがウィルスなどに感染して、不正アクセスの踏み台などになっている可能性もゼロではありません。

そのような不正アクセスが行われた場合は、発信元IPアドレスによって発信者を特定することになります。しかし、NAPTをしているため発信したユーザの情報は攻撃された被害者が知ることはできずに、CONBUが利用しているIPアドレスから攻撃を受けていることまでしかわかりません。そのため会場内とインターネットの通信記録を保存しておく必要があります。

たとえば、会場内で利用しているIPアドレスとグローバルIPアドレスを変換しているNAPTのログの取得は必須です。このログによって、どのIPアドレスから不正アクセスが行われているのかを確認することができます。その中でも必要な情報としてセッションのオープンとクローズ、そして宛先とポート番号を取得することによって、通信していた時間を特定することが可能です。

NAPTのログだけではIPアドレスしかわからず個人の端末にかかわる情報を知ることはできません。DHCPでIPアドレスを払い出したときのログと突き合わせを行う必要があります。そのためにも、端末固有のMACアドレスと払い出したIPアドレスを記録しています。このログによって、NAPTのログの送信元IPアドレスからMACアドレスを特定することができます。MACアドレスは端末固有となっているため、それを元に調査を行うことができます。

さらにスイッチでDHCP Snoopingを利用することで、DHCPで割り当てられたIPアドレス以外からの通信を規制することによって、確実な発信元特定を可能にできます。そのためには装置やサーバの時刻同期が行われていることが前提です。もしもNAPTのログとDHCPの払い出しのログの時刻がずれていると、ログの突き合わせに時間がかかり、発信元の特定が難しくなります。トラブルなどが発生した場合も、時系列がわからないと原因を特定するのに時間を要することになります。ですので装置やサーバの時刻を常に同期させておくことはとても重要です。時刻同期もすべての装置から外部のNTPサーバを指定するよりも、NTPサーバを網内に用意して時刻マスターとしたほう良いです。世界の時刻と正確に合わせることも大切ですが、同じポリシーで運用している網内で時刻を統一するほうが重要度が高いです。

ユーザの通信ログ以外にもルータやサーバのエラーなども同様に取得しており、トラブルを解析するための材料にしています。ほかにはDNSのクエリログも取得しています。不信な通信を行う端末がいた場合、その端末の前後の動きを追うことが可能です。また、統計として活用することもできます。たとえば、GitHubへのアクセスが多いという傾向や、Google、Akamaiなどのハイパージャイアンツへの通信が多い傾向といったインターネットの利用のされ方などを知る材料にもなります。

ユーザの行動を記録する以外にも、全体のトラヒックを監視して装置の限界を超えないか確認しています。今後の装置の増強などの目安としています。

取得ログとIPv6

LLとYAPCのカンファレンスネットワークではIPv6に対応しませんでしたが、カンファレンスネットワークをIPv6に対応させるための課題はまだまだ多いです。前述のログ取得はIPv4での話を前提で書いています。IPv6ではしくみが異なるのでログの取得方法にも違いが出てきます。とくに、端末とIPアドレスを結びつけるしくみと、NAPTをしなくても通信できることが課題となります。

IPv4ではDHCPサーバがステートフルに端末とIPアドレスを管理していたのに対して、IPv6ではRA（Router Advertisement）によってステートレスにIPアドレスが設定されるしくみが用いられることが多いです。そのため、端末のMACアドレスとIPv6アドレスのマッチングはIPv4と比べると複雑で管理しづらいです。DHCPv6によってステートフルにIPv6アドレスを設定することも可能ですが、RA＋DHCPv6に比べると装置の対応や端末の実装がこなれていない部分も多いです。

またNAPTをしないため、IPv6を利用した通信をログに記録することが簡単にはできなくなります。ログを取得するためにセキュリティゲートウェイなどを挟む必要があり手間になってしまいます。

カンファレンスネットワークにおいてIPv6の対応はまだまだ課題が多い状況です。今後IPv6が利用されていく中で改善されていくことに期待をしたいです。

機器間接続は基本1本

一般的にアクセスポイントには1本のUTP（Unshielded Twisted Pair：非シールドより対線。平たく言えばイーサネットケーブル）しか接続できません。また、カンファレンスネットワークでは、ケーブルの敷設にあまり手間をかけていられないため、スイッチ間の接続もUTP1本の場合が多いです。しかし、ネットワークは管理用やスタッフ用、参加者用を分ける必要があるため、VLANを利用しています。VLANは難しい技術ではなく最近では低価格のスイッチでも利用できるようになってきています。

運用データの解析

カンファレンスネットワークを設計する場合に、どれくらいの負荷に耐えられる必要があるのかを知る必要があります。あくまでLLDiverやYAPC::Asia 2014での例ですが、秒間の最大瞬間リクエスト数を出してみます（表2⁠）⁠。

この結果から、LLやYAPCのスタイルのイベントでは余裕をもたせた設計で、来場者数の1.5倍～2倍の収容能力にするべきだと言えます。