3.11 日常的な運用管理
PacketiX VPN Server 2.0
は一度インストールと設定を行うと、基本的には頻繁な管理や動作状況の確認などの管理作業を行わなくても連続して動作し続けます。ただし、VPN
ユーザーに対してより良いサービスを提供し続けるためには、ここで解説しているような日常的な運用管理を行ったほうが良い場合もあります。ここでは管理者の視点から見た
Tips のような形式で、日常的な運用管理の方法やノウハウについて解説します。
3.11.1 サーバーログの監査
VPN Server の管理者は、日常的に VPN Server
が書き出す「サーバーログ」を確認することによってサーバーの動作状況の監査を行うことができます。サーバーログは通常コンピュータが書き出すような難解なデータ形式ではなく読みやすい日本語の形式で書かれるため、毎日サーバーログに目を通すことはそれほど難しくありません。
また、VPN Server のログだけでなく VPN Server
を動作させているオペレーティングシステムのログや、コンピュータが接続されているネットワークの機器 (ルータなど)
のログも定期的に検査したほうが良い場合もあります。
これらのログを頻繁にチェックすることによって、たとえば下記のようなことを早期に発見することができます。
- 普段はあまり発生しない VPN 接続時のユーザー認証の失敗が多く発生している場合は、VPN
サーバーに不正侵入を試みようとしている者がいることがわかります。このような場合は「IP
アドレス制御リスト」機能を使用してそのユーザーの接続元 IP アドレスからの VPN 接続を拒否するように設定することができます。
- 見覚えのない VPN クライアントから接続が行われている場合は、ユーザーのパスワードが破られるなどして VPN
サーバーに不正侵入があった可能性があることがわかります。
- 仮想 HUB のセキュリティログで通信上のイベントが多数発生している場合は、VPN
ネットワーク内で何らかの異常が発生している可能性があります。
- ログファイルを機械的に処理する (たとえば grep などのツールを用いて必要な行を切り出し Perl などでパースするなど)
ことによって、各ユーザーの接続時刻や接続頻度などをデータベース化することができます。
-
パケットログの内容は簡単に機械的に処理することができます。パケットログをデータベースに格納しヘッダ部分をインデックス化しておくことによって、あとで何らかの追跡作業が必要になった場合にパケットログを素早く検索することができます。
3.11.2 各種使用状況のチェック
VPN Server や仮想 HUB では様々なオブジェクトに対して統計情報を自動的に記録し管理しています (詳しくは 「3.3.10 統計情報の管理」
をお読みください)。VPN サーバーや仮想 HUB の管理者はこれらの統計情報をチェックすることにより、どのユーザーや仮想 HUB
の通信量が多いのかといった VPN サービスの使用状況に関する情報を得ることができます。
3.11.3 構成情報のバックアップ
VPN Server の管理者は、定期的に vpn_server.config
ファイルをバックアップしておくことをお勧めします。このファイルには VPN Server の動作に必要なすべての情報が記載されています。もし
VPN Server を動作させているコンピュータにハードウェア障害が発生したときのために vpn_sever.config
ファイルは外部の別のコンピュータなどに自動的にバックアップするようにしておけば最適です。
また、可能であればすべてのログファイル (サーバーログ、セキュリティログおよびパケットログ)
については外部メディアなどの安全なデバイスにバックアップしておくことをお勧めします。なお、ディスク容量が不足しそうな場合には新しいログファイルを優先して書き出す必要があるため古いログファイルは
VPN Server によって自動的に消去されてしまいますのでご注意ください (詳しくは 「3.3.11 ディスク容量不足時の自動調整機能」 をお読みください)。
3.11.4 障害発生時の復旧
VPN Server を動作させているコンピュータが物理的に故障するなどの障害が発生した場合は、直ちに別のコンピュータを用意するなどして
VPN Server をインストールし、バックアップしておいた最新の vpn_server.config
ファイルを読み込ませることによって障害発生前の構成情報で運用を継続することができます。
3.11.5 コンフィグレーション内容のロールバック
管理者が明示的にバックアップ作業を行わない場合でも、コンフィグレーションファイルに変更があった場合は原則として 1 時間に 1
回コンフィグレーションファイルの履歴が保管されています (詳しくは 「3.3.9 コンフィグレーション履歴」
をお読みください)。もしコンフィグレーションファイルを誤って破損してしまったり、ディスク障害や停電などによって消えてしまった場合、または間違って重要な設定を消去してしまいもう一度同じ設定をするのが困難な場合などは、自動バックアップシステムによってバックアップされた以前の任意の時点のコンフィグレーション内容にロールバックすることが可能です。
具体的な方法については、「3.3.7 コンフィグレーションファイル」 の「コンフィグレーションファイルの置換」をお読みください。
3.11.6 ハードディスク空き容量の確認
VPN Server
に限らず、どのようなサーバーサービスを運用している場合でもコンピュータのハードディスクの空き容量には気を配ってください。特に多くのログを保存する
VPN Server
では、ハードディスクの空き容量が不足してくると古いログファイルから順番に自動的に削除されていってしまいます。これを防ぐためには、古いログファイルは必ずバックアップしてから削除しておいてください。
もし VPN Server
以外の他のサーバーソフトウェアが同一コンピュータで動作している場合は、別のソフトウェアによって書き出されるログなどのデータファイルの容量によっても
VPN Server が影響を受ける場合がありますのでご注意ください。
3.11.7 ネットワーク管理支援ソフトウェアの援用
VPN Server
を動作させているコンピュータを、市販またはフリーのネットワーク管理支援ソフトウェアによってより簡単に管理することができる場合があります。
たとえば SNMP (簡易ネットワーク管理プロトコル) に対応したユーティリティを使用すると、VPN Server
が動作しているコンピュータの CPU 使用率やネットワークトラフィックなどのグラフを簡単に描画して、わかりやすい形で表示してくれます。
また統合管理ソフトウェアを使用すると VPN Server
やその他のサービスを稼動させているサーバーコンピュータをまとめて管理し、定期的なファイルのバックアップやサーバーの再起動、オペレーティングシステムのパッチの適用などを行うことができます。
3.11.8 必要なリソースが足りているかどうかのチェック
VPN Server の動作パフォーマンスは、サーバーコンピュータの CPU
速度、メモリの速度および空き容量、ハードディスクの残り容量と断片化率、およびネットワーク帯域によって変化します。
- VPN サーバーとして使用するコンピュータの CPU
には、予算の範囲内で使用することができるできるだけ高速なものを使用することを推奨します。CPU の速度は、VPN
通信における暗号化や復号化、RSA 演算、カプセル化およびカプセル化解除などに大きく影響します。キャッシュのサイズが大きく、また
Hyper Threading やマルチコアなどの技術が利用可能で並列処理に強い CPU を選択してください。
- VPN Server は大量のデータ処理を瞬時に行いますが、この際多くのデータはメモリ上に一時的に保存されます。したがって
VPN
サーバーとしての性能はメモリの速度によっても大きく影響されます。また物理メモリの空き容量が少なくなるとオペレーティングシステムによってスワップが発生しますが、スワップ処理の間はメモリにアクセスするコードは停止してしまい、VPN
Server の動作に大変な悪影響を及ぼす可能性があります。VPN Server
を使用する場合で特に大量の同時接続を処理したり、多くの種類のパケットについてパケットログを書き出したりするような場合は、事前にサーバーコンピュータに十分な量のメモリを装着しておいてください。
- VPN Server
は多くのログをハードディスクに書き出します。もしハードディスクの空き容量が少なくなり断片化が激しくなると、これらのログの書き出しの際にも時間がかかるようになり好ましくありません。
- PacketiX VPN は通信を行うソフトウェアですので、特に VPN
サーバーは広帯域で低遅延のネットワークに接続することをお勧めします。
大量の同時接続を処理するような場合など、十分なハードウェアリソースを 1 台の VPN
サーバーコンピュータで満たすことができないような場合があります。そのような場合は VPN Server
によるクラスタリング機能の使用を検討してください。
3.11.9 実効スループットの測定
VPN Server を管理している場合は、定期的にその VPN Server を使用するユーザーの立場に立って VPN
接続を行い、実効スループットを測定してみることをお勧めします。実効スループットの測定方法としては、2
台のクライアントコンピュータを用意して普段ユーザーがアクセスに使用するような回線を経由して同一の仮想 HUB
に接続し、「通信スループット測定ツール」を用いて通信スループットを測定してみるのが最も簡単で確実な方法です。詳しくは 「4.8 実効スループットの測定」
をお読みください。
もし実効スループットを測定した結果予想したよりも大幅に低速な結果が出た場合は、ネットワーク上の原因やサーバーコンピュータのハードウェアリソースの原因などを疑ってみてください。
|