今回の記事では、システム管理者や企業の情報システム部門の担当者向けの記事として、「初めて社内ネットワークを設計したり構築したりする際に頭に入れておきたい少しニッチなポイント」を紹介していきます。
ネットワークはITにおけるインフラであり、そのインフラの上で業務アプリケーションは動き、クライアント端末は社内外と通信をします。
無くてはならない重要な基盤です。
今回の記事では、その使えることが当たり前の「ネットワーク」を安定して稼働させて、セキュリティも考慮した環境を設計、構築していくための必要な知識やポイントを、私の実体験も交えながら広く紹介していきます。
当記事で前提とするネットワーク知識
当記事では、多少のネットワークに関する予備知識があることを前提として解説していきます。
具体的には以下の知識です。
- TCP/IPに関する基本的な知識
- ITパスポートレベルのIT全般の知識
- 企業内でのシステム管理、運用経験やそれに付随する知識
もちろん上記の知識や経験が無くてもわかりやすくかみ砕いて説明するように努力させていただきます。
社内ネットワークを設計・構築する場合のポイント
当項では、今回の記事の主題である、「社内ネットワークを設計・構築する場合のポイント」を紹介していきます。
サーバとクライアントはセグメントを分離するべし
今回の記事で一番お伝えしたいのはこの項の内容です。
御社のネットワークはサーバーを配置しているネットワークセグメントと社員が使用しているパソコンなどを配置しているネットワークセグメントを同じセグメントに配置してはいないでしょうか？
そのネットワーク設計では適切なセキュリティは担保できません。
もしこれからネットワークを設計、構築しようとされている場合は、是非セグメントの分離、分割を強く推奨します。
念のため、「セグメント」についても簡単に紹介しておきます。
プライベートIPアドレスでは、サブネットマスクの値を調整することで、IPアドレスを「ネットワーク部」と「ホスト部」に分割できます。
皆さんもよく開く「インターネットプロトコルバージョン4のプロパティ」を見てみましょう。
この設定項目のなかの「サブネットマスク」は 255.255.255.0 と設定されていますね。
また、IPアドレスは 192.168.1.1 です。
このサブネットマスクからIPアドレスをネットワーク部とホスト部に分ける場合は以下のイメージです。
サブネットマスクを2進数に変換し、1がネットワーク部で0がホスト部です
そしてのこのネットワーク部のことを「セグメント」と呼んでいます。
よって、192.168.1 までがセグメントになります。
IPネットワークでは、このセグメントが異なるIPアドレスは相互に通信をすることはできません。
逆言えば、IPネットワークのなかで相互に通信をしたい場合は、ホスト部の番号に重複させないようにしつつ、同じセグメントの数字を指定する必要があります。
通信可能〇：192.168.1.1 → 192.168.1.2
通信不可×：192.168.1.1 → 192.168.2.2
このように、セグメントでIPアドレスを分けることで、論理的にネットワークを分離することができます。
なぜサーバーセグメントとクライアントセグメントを分離するのか
当項の主題である、サーバーセグメントとクライアントセグメントを分離しないといけないのか？について解説していきます。
私の以前に勤めていた会社や、今の会社でもそうですが、本社の建物内にサーバールームがあり、以下のようなネットワーク構成になっていました。
192.168.1.0/24 のセグメントにサーバーやクライアント、プリンターなどのすべての機器が配置されています。
さすがにサーバーとクライアントのIPアドレスをまったく区分けせずに適当に採番する訳ではなく、例えばサーバー用としては192.168.1.200より大きい番号を設定し、クライアントは 192.168.1.200以下の番号で設定するなどの、最低限の採番ルール的なのは有ったりします。
ただ、それはあくまで人がIPアドレスを管理し易くするために割り振る番号のルールを決めているだけであり、システム的には大した意味はありません。
このネットワーク構成の場合は、以下の問題が発生します。
- クライアントからサーバーへの通信を遮るものが何も無い。
- 不必要なブロードキャストパケットがネットワークに流れて帯域を圧迫する。
- ネットワーク障害などのトラブル時に影響がネットワーク全体に及ぶ。
上記の問題のなかでも重要視したいのが、一つ目の「通信を遮断できない」部分です。
例えばDBサーバーやファイルサーバーのような重要度の高いサーバーに対してクライアントからの通信を通す場合、そのサーバーで提供しているサービスで使用するポート番号に限定したいところですが、同一のネットワークにクライアントとサーバーが配置されている場合は、クライアントとサーバー間の通信を仲介する機器は存在せず、クライアントはサーバーに対して直接通信できてしまいます。
直接通信ができてしまうことで以下のようなリスクが発生します。
- 本来一般のクライアントには許可していないサーバー側サービスへの通信ができてしまう。
- クライアントがランサムウェアなどのコンピューターウィルスに感染した場合にサーバーにも感染が広がる
よって、クライアントから直接通信を通すことはセキュリティにおける大きなリスクになります。
それでは、セグメントを分割したさいにネットワークの構成例を紹介していきます。
ルーターの配下にファイアーウォールを配置しています。
当構成では、クライアント用のセグメントを 192.168.1.0/24 とし、サーバー用のセグメントを 192.168.2.0/24 としています。
このようにネットワークを分けるにあたって、ファイアーウォールやルーターには以下の設定が必要になります。
- ファイアーウォールのポート1に 192.168.1.254 のIPアドレスを設定
- ファイアーウォールのポート2に 192.168.2.254 のIPアドレスを設定
- ルーターのLAN用ポートに 192.168.3.254 のIPアドレスを設定
- ファイアーウォールのポート1には 192.168.2.0/24 と 192.168.3.0/24 やその先のネットワーク宛ての通信のルーティング追加
- ファイアーウォールのポート2には 192.168.1.0/24 と 192.168.3.0/24 やその先のネットワーク宛ての通信のルーティング追加
- ファイアーウォールのポート1にフィルタリングのルールを追加
この構成を作ることで、クライアントセグメントからサーバーセグメントへは必ずファイアーウォールを介することになり、ファイアーウォール側でルーティングを追加しない限りお互いのセグメントへの相互通信はできなくなります。
ブロードキャストの通信は自セグメント内のみに限定されます。
また、ファイアーウォール内でパケットのフィルタリングルール(ポリシー)を設定することで、特定のサーバーはSQL Serverで使用するポートしか通さないとか、特定のサーバーには特定のIPアドレスからの通信しか通さないといった細かい通信制御を加えることができます。
ネットワーク内で稼働する機器が増えた後にセグメントを分離することは非常に大変です。
新しくネットワークを構築する場合は最初から適切にネットワークを分離したネットワーク構成を作っておきましょう！
「島HUB」は極力減らすべし
物理ネットワークを構築する際にはスイッチングハブは必要不可欠ですが、ユーザーの席の近くなどに設置して、その周辺の席一帯の端末をネットワークに繋ぐ目的で使用される、物理ネットワークの末端に位置するスイッチングハブを通称「島HUB」と呼んだります。
この島HUBは、オフィスのレイアウト変更や端末台数の変更が必要になる度に追加したり外したりして運用しますが、島HUBの管理が不十分だとシステム管理者なら誰もが一度は経験する「ネットワークループ」の原因になります。
例えば、貴方のオフィスのLANは以下にように作られているとします。
場当たり的に島HUBを追加した感がありありですね。
さて、総務部のやる気だけは人一倍ある山田君が、総務部の島HUBに挿してあるLANケーブルのなかに、どこにも繋がっていないLANケーブルが1本あるのを発見しました。
山田君はすぐ近くにあった人事部の島HUBにそのLANケーブルを挿しました。
総務部、人事部、経理部の島HUBで「ブロードキャストストーム」が発生し、しばらくすると総務部、人事部、経理部のパソコンはすべて通信できなくなりました。
また、営業部のパソコンもコアスイッチに接続していることでやはり通信は不安定です。
ネットワークループを回避するポイント
社内ネットワークには付き物の「ネットワークループ」ですが、ループを起こさないようにするポイントがあります。
具体的に言えば、上記のネットワーク構成の場合、コアスイッチ配下の繋がっている島HUBを全部無くしてしまい、代わりにコアスイッチから各島まで長いLANケーブルを端末の台数分延ばし、各端末はコアスイッチと直結させます。
ほら、これなら総務部の山田君が間違って島HUBの空きポートにLANケーブルを挿してしまうことはありません。
ただ、現実問題として、接続する端末台数分のポート数を持つコアスイッチが必要になりますし、どうしてもLANケーブルを直接結線できないケースも多いです。
そのため、島HUBを完全に無くすことはやはり難しいのですが、それでも可能な限り島HUBを無くし、ループが起こる要因を排除する考え方を意識して社内LANを構築することはとても重要です。
近くにポートの空いているHUBがあればLANケーブルを挿したくなるのが人の心情です
安易にHUBを継ぎ足しせず、可能な限り必要最低限のHUBで構築できるように工夫していきましょう！
アクセスポイントは複数台で分散するべし
企業のネットワークにおいて、タブレット端末の業務利用の増加やオフィス内のフリーアドレス化など様々な要因もあり無線LANは利用は増える一方ですが、無線LANは従来の有線LANのネットワークとは注意するべきポイントが異なります。
当項では、無線LANを社内に構築する場合に注意するべきポイントを紹介していきます。
無線LANでアクセスポイントと各端末を接続する場合、有線LANのように物理的なポート数の制約を受けません。
その為、アクセスポイント側で接続台数に対しての上限が設定されていない限り、幾らでも同じアクセスポイントに端末を接続することができます。
例えば以下の構成です。
ただ、無線LANの場合、一つのアクセスポイントにたくさんの端末を接続する構成は可能な限り避ける必要があります。
その理由は以下。
有線LANは「全二重通信」、無線LANは「半二重通信」ですが、簡単に両者の違いを説明すると以下です。
半二重通信：同じAPに接続している端末同士は同時に通信できない。
ネットワークを流れる通信データのパケット同士が衝突することを「コリジョン」を呼びますが、有線LANではコリジョンが発生した場合は再送します。
無線LANではコリジョンを検出できないため、コリジョンを発生させないように同じアクセスポイントに接続している端末は同時には通信できず、通信をしている1台の端末以外は待機します。
以下のようなイメージです。
実際に複数の端末が同時に通信をする場合は、短時間で通信中の端末を切り替えていることで、あたかも同時に通信ができているように見せています。
そのため、一つのアクセスポイントに接続する端末が増えれば増えるほど、通信時の待ち時間も増えていき、通信速度がどんどん遅くなります。
複数のアクセスポイントに分散する
前項では、一つのアクセスポイントにたくさん端末を接続することで、無線LANの通信速度が遅くなることを紹介しました。
では、多くの端末を無線LANに接続させたい場合はどうすれば良いでしょうか？
それは「アクセスポイントを増やす」ことで改善します。
アクセスポイントを増やすことで、アクセスポイント一台に接続する端末数も減り、同時通信時の通信待ち時間が減少することになります。
以下のようなイメージです。
このように、アクセスポイントごとに接続する端末が適切に分散されている限り、ユーザーは快適に無線LANでの通信を利用できます。
ただ、この対策にも実は問題はあります。
具体的には以下のケースが発生した場合はやはり通信は遅くなります。
アクセスポイントに接続する端末数が偏り、均等に分散されていない場合。
ケース2：
アクセスポイントに接続する端末が場所を移動することで距離が遠くなる場合。
アクセスポイントごとに異なるSSIDを設定している場合は、接続するアクセスポイントは固定されますが、同じSSIDを異なるアクセスポイント間で共有して使用している場合は、接続を開始した時点で最も電波感度の強いアクセスポイントへ接続します。
その為、アクセスポイントごとに接続されている端末台数に偏りが生まれることも多く、また、無線LANに接続したままの端末が物理的に場所を移動することで、接続しているアクセスポイントから遠ざかり、移動した先にはより電波感度の強いアクセスポイントが存在している場合であっても、完全に電波が途切れない限りは元のアクセスポイントに繋がり続けます。
当然その場合も通信は不安定になり、遅くなります。
コントローラー付きアクセスポイント
複数のアクセスポイントを効率よく活用するためには、「無線LANコントローラー」が必要になります。
この「無線LANコントローラー」は、複数のアクセスポイントと常時通信を行い、一元的にアクセスポイントの状態を管理し、各アクセスポイントの設定もコントローラー側の管理画面から行える仕組みです。
また、この無線LANコントローラーでは、各アクセスポイントに接続している端末の接続状態も管理しており、必要によってその端末にとって最適なアクセスポイントへ繋げ直してくれるといった機能を持ちます。
この無線LANコントローラーも、最近ではクラウドサービス化されている製品も多く、こういった製品は比較的安価に利用できます。
以下のようなイメージです。
アクセスポイントを同じ拠点や同じフロア等で複数台で運用する場合は、これらの機能は非常に効果的です。
尚、今回解説した無線LANにおける半二重通信による特性や、それ以外にも無線LANの社内に導入する場合のポイントについて、過去に別の記事でまとめております。
もし興味があればこちらもご一読頂けるとよいかもしれません。
無線LANは半二重通信で同時通信ができないのはCSMA/CAと呼ばれる通信規格上の仕様であり仕方がない
そこは適切に理解したうえで上手く無線LANを活用していきましょう！
拠点間VPNでは距離ではなく経路に注意するべし
社内ネットワークを語るうえで欠かせない、拠点間VPNでも注意すべきところを紹介しておきます。
企業の本社や各地域の支社や営業所などの拠点のネットワークを、IP-VPNを利用して相互に接続して広域のプライベートネットワークを構築することを「拠点間VPN」と呼んだりしますが、拠点間VPNにおいて非常に重要な要素になるのが「通信速度」です。
通常、同じ拠点内のネットワークであれば、1Gbps以上のNICを持つネットワーク機器で相互に接続し、パソコンやサーバーなどの各端末は高速に通信をすることができますが、一般的なVPNではインターネット上で仮想的に拠点間を繋げる技術であり、実際に通信でやり取りするデータはインターネットに出ていきます。
インターネットでは目的の宛先まで通信データが到達するまでに様々な経路を通ることにより、拠点内のプライベートなネットワークのような通信速度は見込めません。
拠点内のプライベートなネットワークと比較すると非常に遅い場合が大半です。
その為、拠点間VPNを新しく構築する場合には、その拠点間の通信速度や通信の安定性などの通信品質が非常に重要になります。
遠隔地との通信において、通信速度を決める要素の一つが「物理的な距離」です。
現在の情報通信技術において、最も速いデータの伝達方法は「光ケーブル」を介した通信です。
光ケーブルでは名前の通り光信号をケーブルに載せて通信します。
その為、論理的には伝達スピードは光速と同じです。
光の速さを人間の感覚で測る場合、沖縄から北海道へ到達する時間も、大阪から東京へ到達する時間もどちらも一瞬の出来事です。
ただ、コンピューターの世界では、ミリ秒、マイクロ秒、ナノ秒といった、人間が認識できる時間の感覚よりもはるかに小さい時間の単位で動いています。
また、同様にコンピューターの世界では、一秒の間に何十万回、何百万回の命令を実行できます。
よって、距離による拠点間通信の到達時間の差は一つ一つは微小であっても、大量にその処理が繰り返されることで大きな差となります。
拠点間の物理的な距離と通信経路の距離は違う
私が過去に経験して知りましたが、広域な拠点間の通信に関してお伝えしておきたいのは「拠点間の物理的な距離と通信経路の距離は違う」場合が多いということです。
例えば、以下のように、福岡にあるデータセンターと、沖縄にある拠点とでVPNを構築するとします。
皆さんが普通にイメージする通信経路としては以下だと思います。
福岡と沖縄であれば物理的な距離はそれほど離れておらず、極端な通信遅延は起こらないイメージです。
ですが、実際にその拠点間でVPNを構築した際に発生した通信経路は以下でした。
思いっきり遠回りをしているおかげで想定より大きく通信の遅延が発生しました。
この遠回りの通信経路が発生した理由の一つとして、日本国内における大手の「インターネットエクスチェンジ」の多くが東京に集中している問題があります。
参考情報として、Wikipediaの記事のリンクも紹介しておきます。
インターネットエクスチェンジ（Internet Exchange point）とは、インターネットの中核を成す施設であり、プロバイダ(ISP)、インターネットデータセンター(IDC)や、国家間の通信を交換するための相互接続ポイントである。略称 IXまたはIXP。インターネット相互接続点とも呼ばれる。
安全保障上の理由から、その所在地等の詳細はあまり公になっていないが、日本国内では十か所前後、全世界では数百か所の大規模なIXが存在する。
インターネットエクスチェンジ -Wikipedia-
インターネットエクスチェンジについては紹介したリンク先のWikipediaをご覧ください。
インターネットで通信をする場合、このインターネットエクスチェンジに様々なISPが接続して隣接したネットワークを相互に通信しながら目的のアドレスまでパケットを運びます。
ただ、日本国内のネットワークでは東京に大手インターネットエクスチェンジや通信事業者が集中しており、上記のイメージのように、福岡から沖縄へ最短の経路で通信ができずに、東京を経由せざるを得ないケースも発生します。
必ず東京を経由する訳ではなく、通信元と通信先が使用するISPによって経由の有無や経路は異なりますし、互いの地域によっても異なります。
これらの通信経路は公開されているものではなく、ISPなどの通信事業者に問い合わせても開示されません。
且つ、常に同じ経路を通るとも限りません。
よって、こういった通信経路の迂回が有り得ることを知ったところで、事前にその検証ができたり確認ができるものでは無いのですが、社内のシステム管理者としてネットワークを設計する場合に、知識としては持っておいた方が良いと考えます。
例えば、BCP対策の一環ととしてDR環境を構築する場合に、メイン環境からなるべく遠方のデータセンターなどにDR環境を構築する構成が一般的ですが、もし東京を経由地点とした通信経路の迂回が有り得るなら、東京から大きく離れていない場所の方が通信遅延のリスクが小さいということが言えます。
まず接している海が、東京などは太平洋、富山は日本海と異なります。
その為、大規模な津波による影響を同時に受ける可能性は低いと思われます。
また、富山は大きな山脈で東京などとは分断されており、台風などの気候的な問題で大規模な被害が同時に発生し難い。
北アメリカプレートとユーラシアプレートの境目に位置しておりそこはリスク要因ですが、東京と同時に大規模地震によって被災する可能性は低いのではないかと思っています。
拠点間VPNでは通信速度は重要であり、想定以上に通信速度が低下した場合に、社内の業務効率低下やシステム障害を誘発するなど深刻な影響が起こり得ます。
そのため、今回紹介した通信経路の迂回なども想定しつつ、最も合理的な構成や立地を選定するように心掛けましょう！
最後に
今回の記事では、企業のシステム管理者が社内ネットワークを構築する際に知っておくと良いポイントを紹介しました。
ネットワーク設計、構築の入門系の専門書や技術ブログなどで紹介されている内容と被らないような記事にしてみたつもりです。
今回の記事が貴方のお役に立てれば幸いです。
今回も長々と読んでいただきましてありがとうございました。
それでは皆さまごきげんよう！
