2022年8月、ホームページを全面リニューアルしました! 情報を分かりやすくお伝えできるサイト作りを目指してまいります。

社内ネットワークIP枯渇問題に挑む!

中規模企業で当初クラスC単一で構築していたネットワーク、しだいに社員数が増加して現在160名迄ふくれ上がった。IPアドレスは、192.168.0.0ネットワークセグメントで構築している。したがって、おわかりだと思うが、社内ドメインサーバやインターネットサーバを含めばそろそろクラスCセグメント上限の254台へとどくのも時間の問題である。ここでは、このような状況におかれたネットワークを改造するために調査した記録を紹介する。弊社は、Unix及びWindows混在環境で有るため、色々問題も含む。


1. 社内ネットワークの現状

1.1 現状のネットワークの説明
現在の社内ネットワークでは、各端末に対してのプライベートIPアドレス にIPアドレス・クラス「クラスC」を使用している。各端末へのIPアドレスの割振りは、DHCPサーバを使用しての動的なIPアドレスの割振りと、部門サーバ等やネットワークプリンタについては、予めIPアドレスを固定)して使用している。オプト事業部以外、全ての端末が一つのセグメントで繋がっており、セグメント内で部署ごとに( NT )ドメインで構成されており、各ユーザーと資源の管理を行っている。他部署(他(NT)ドメイン)との資源の共有は、各ドメインで互いに信頼関係 を結ぶことで解決している。さらに、使用できる全プライベートIPアドレス254個中、固定IPアドレス用に54個、DHCP用に200個で管理している(図1参照)。

ただし、現在オプト事業部は、 192.168.10.0 のネットワークで既に別セグメントになっているので今回の枯渇問題からは割愛する。

図1

2.社内ネットワークの問題点

2.1 社内ネットワークの問題点
社内で使用している端末数が年々増加傾向にあり、将来的には使用できるプライベートIPアドレス数(クラスCでの端末台数254台) の上限を超えてしまう。

2.2 具体的な問題点の説明
現在のプライベートIPアドレスの使用状況(2006年1月現在)を調査すると、

◎ 固定IPアドレスを使用しての接続は最大54台中43台使用中
◎ DHCPを使用しての接続は最大200台中約135台使用

このような結果となった。
このデータから推察すると、数値上ではDHCPを使用しての接続可能な端末台数の残りは60台前後だが、社内で使用している端末数は常に変化しているので前後20台を考慮すると約40台。さらに、4月に新入社員(10名)が加わると事実上、新規に接続できるのは30台前後となる。したがって、早い時期に何かしらの対策が必要となる。


3.対策案
■ 対策案.1(固定IPアドレス化にすることによる対策)

対策案の説明:
社内で使用する全端末に対し、全て固定IPアドレスで管理する。
全ての端末に対して固定IPアドレス化を行い、IPアドレスの利用率(使用数)を明確にして無駄なネットワークへの参加を管理する。

デメリット:
1)使用頻度が少ない端末(使っていない端末)にも、IPアドレスを割り振る必要があり、IPアドレスの無駄遣いになる。

2) 社員端末の交換時にIPアドレスの追加・削除等のメンテナンスを行わなければならず管理工数がかかる。

総評:
IPアドレス固定化することにより、IPアドレスの使用率を明確化したとしても、結果的に現状のネットワークへの接続最大端末数254台の上限が増すわけではない。したがって、今回の問題の根本的な解決にはならないと言える。

■ 対策案.2(クラスB振り替えによる対策)
対策案の説明:

プライベートIPアドレスのアドレス・クラスを現状のクラスCからクラスBに変更する。社内で使用しているプライベートIPアドレスをクラスBへ変更して使用できるIPアドレスを増やすことにより、ネットワークに接続できる端末数を増やす( 現状の最クラスCの最大254台 ⇒ 変更後のクラスBの最大:65534台 )。

デメリット:
1) クラスBへの振り替えは作業は、社内で使用しているすべての部門サーバ及びネットワークサーバのIPアドレスを一斉に変更する必要があり、さらに各サーバのIPアドレスに関する設定を全て変更しなければならない。したがって、工数もかかるが万が一の設定漏れが有った場合、ネットワーク自体が通信できなくなるばかりでなくネットワークにかなりのダメージを与えるリスクも伴う。

総評:
前述したデメリットを考えるとリスクが高く現実的ではないと言える。

■ 対策案.3(異なるセグメント分割よる対策)
対策案の説明:

各フロア単位で、ネットワークのセグメントの構築を行う。

図2

図2のように、3F・5F・7Fで別のプライベートIPアドレス( 3F:[192.168.3.*]、5F:[192.168.5.*]、7F:[192.168.7.*] )で現在使用している「192.168.0.*」のセグメントとは別に「192.168.3.*」「192.168.5.*」「192.168.7.*」の各セグメントを作る。しかし、フロア単位でネットワークのセグメントを作る場合、以下の問題点(1)(2)(3)が考えられる。

◎ 問題点(1)
問題点とは:

ドメインコントローラと異なるセグメントにある(プライベートIPアドレスに192.168.3.*、192.168.5.*、192.168.7.*を使用している)端末から、対象となるドメインへのログオンが行えない。

原因:
ドメインログオンには、ドメイン名(NetBIOSドメイン名)、プライマリドメインコントローラのコンピュータ名、IPアドレス、コンピュータ名の解決が必要で、コンピュータ名の解決にNetBIOS名が必要になる。NetBIOS名は、NetBEUI、NBTプロトコルによるブロードキャストで解決が行われるが、ルーターを超えての通信は行われず、他のセグメントにあるドメインコントローラを見つけることができないために名前解決が行えない状態になりドメインログオンが行えない。

回避策:
各端末が異なるセグメントにあるドメインコントローラの情報(LMHOSTSファイル、又はWins Server)を参照することで、ドメインへの登録、ログオンが行える。

◎ 問題点(2)
問題点とは:

異なるセグメントにある端末のブラウズが行えない。

原因:
コンピュータ・ブラウジングを行うためには、ブラウズリストが必要である。ブラウズリストは、NetBIOS over TCP/IPでのブロードキャストを行いマスタブラウザから取得する。しかし、この場合ブロードキャストは異なるセグメントに対して行えず、そのためブラウズリストを取得できない。したがって、端末の表示が行えない。


回避策:
ドメイン構成を行っている場合、必ずドメインコントローラが、そのドメインのドメインマスタブラウザになる。また、異なるセグメントにある端末からでも、ドメインコントローラとの通信が可能ならば(問題点(1)への対応を行えば)、ドメインコントローラがあるセグメント( [192.168.0.*] )のブラウズリストが取得できる。したがって、[192.168.3.*]、[192.168.5.*]、[192.168.7.*]のセグメントからは、[192.168.0.*]にある端末のブラウズは行える。
但し、[192.168.0.*]以外の異なるセグメントのブラウズについては、各セグメント間でブラウズリストの取得ができない為、コンピュータ・ブラウジングは行えない。(例として、[192.168.0.*]にある端末から、[192.168.3.*]、[192.168.5.*]、[192.168.7.*]にある端末のブラウジング、[192.168.3.*]にある端末から、 [192.168.5.*]、[192.168.7.*]のセグメントにある端末のブラジングは行えない。)

◎ 問題点(3)
問題点とは:

異なるセグメントにある端末同士で共有ファイルの参照が行えない。(但し、[192.168.3.*]、[192.168.5.*]、[192.168.7.*]から[192.168.0.*]の端末にある共有ファイル、同一セグメント内での共有ファイルの参照は可能。)

原因:
異なるセグメント間で、ホスト名からIPアドレスの名前解決が出来ない為、共有ファイルの参照が行えない。

回避策:
[192.168.0.*]にある部門サーバを経由することで、ファイルの共有を行うことは可能である。しかし、業務の都合上、どうしても異なるフロア間の端末同士、直接共有ファイルの参照を行わなければならない場合は、一時的に互いの端末を0のセグメント上に乗せることで対処する。

デメリット:
[192.168.0.*]以外の異なるセグメント同士のコンピュータ・ブラウジングが行えない。
[192.168.0.*]以外の異なるセグメント同士で共有ファイルの参照が行えない。

総評:
[192.168.0.*]以外の異なるセグメントのコンピュータ・ブラウジング、異なるセグメントにある端末同士で共有ファイルの参照が行えないデメリットはあるが、各フロアで最大254個のプライベートIPアドレスが使用できるようになり、さらに移行作業が各フロア単位で部門サーバ等の設定変更もなく移行が簡単に行える為、リスクが少ない。また、現状のネットワークと比べると、自由度は低くなるがセグメント単位の管理となるため、セキュリティ的には高くなると考える。


4.各対策案の比較と情報システム室としてのアプローチ
4.1 情報システム室のアプローチ

IPアドレス枯渇問題を解決するに当たり、情報システム室としては、作業時のリスクが低い対策案3(異なるセグメントによる対策)を対策として施行する。
ただし、8Fは人数が少ないため、現状の[192.168.0.*]のネットワークとする。

4.2 作業内訳
■ 各フロアにルータを一台設置
■ 各フロアにWinsServerを一台設置
■ 各フロアにSwitchingHubを一台設置

全て、ネットワーク機器は情報システム室支給。
以上

コメント