VPN 接続のトラブルシューティングに関する 15 のヒント

  • [アーティクル]

Paula Sharick

VPN は実にさまざまな方法で構築できます。最小構成の VPN は、インターネットに接続された RAS PPTP サーバー、インターネットに接続されたクライアント、そしてサーバーとクライアント間の PPTP 接続からなります。ISP サービスとインターネット接続が利用できる限り、クライアントは世界中のどこからでもサーバーや LAN に接続できます。しかし、ほとんどの VPN はサーバーとクライアントが接続するというだけの単純な構成ではありません。一般に、VPN サーバーはルーターを経由した LAN セグメント上にあり、しばしばファイアウォールの背後に設置されます。そして、クライアントの接続でもまたルーターやファイアウォールを経由した ISP ネットワークが使用されます。

PPTP サーバーはスタンドアロン サーバーとして設置できますが、いくつかの手順を踏んだ上でドメイン コントローラとして設置することもできます。これには、RAS と PPTP プロトコルをインストールし、ダイヤルアップ接続における設定と同じ方法で PPTP ポートを設定します。Windows NT クライアントのセットアップも同様に簡単です。PPTP をロードし、PPTP 接続を設定してインターネット上の PPTP サーバーの場所を指定します。このようにセットアップが簡単なため、初めのうちはこれで VPN 接続が正しく機能するだろうと思うのも当然かもしれません。しかし、VPN の接続にはしばしば調整作業が必要になることがあります。

VPN のトラブルシューティングは WAN 接続の問題におけるトラブルシューティングとまったく同様です。どちらもデータが目的の場所に届くまでに多数のリンクを経由するため、処理が複雑になります。たとえば、データは通常のケースでは、クライアントから ISP のルーターに送られ、ファイアウォールを経由し、ISP のネットワークを経由して、場合によっては他社 ISP のネットワークを経由しながら、企業のルーター、ファイアウォールまたはプロキシ サーバーを経て、最終的に目的の PPTP サーバーに到達します。

クライアントが ISP に接続すると (この接続では VPN 接続の PPP (Point-to-Point Protocol) 部が使用されます)、ISP はそのクライアントに TCP/IP アドレス、DNS サーバー アドレス、およびデフォルト ゲートウェイを割り当てます。クライアントが PPTP 接続を開始すると、その動作によって 2 番目の TCP/IP セッション (このセッションは VPN 接続のトンネル部) が作成され、1 番目のセッションの内側に埋め込まれます。これによってパケットが暗号化されカプセル化されます。クライアントが接続に成功すると、VPN サーバーはクライアントに 2 番目の IP アドレスと 2 番目の DNS サーバー アドレスを割り当て、しばしば WINS サーバーともう 1 つのデフォルト ゲートウェイを割り当てます。接続内の各リンクでは何らかの問題が発生する可能性があります。VPN の設定や接続に関する一般的な問題を理解し、それらに対処するためのトラブルシューティング手順を用意しておけば、VPN 接続の問題解決やデバッグに役立ちます。

トピック

VPN サーバーの推奨設定 VPN サーバーの推奨設定

クライアントのトラブルシューティング クライアントのトラブルシューティング

ついに準備完了 ついに準備完了

VPN サーバーの推奨設定

可能であれば、サービスの種類を極力抑えインストールした NT サーバーから始め、プロトコルを TCP/IP と PPTP に限定します。NT 4.0 の Service Packs 5 (SP5) および SP6a では、パケットの断片化に関連するパフォーマンスの問題、接続のドロップおよび拒否に関連するパフォーマンスの問題など、PPTP 接続に関する多くの問題について修正が加えられています。クライアント接続をデバッグする前に、これらのサービス パックを使用してサーバーを更新しておけば時間の節約になります。以下では、サーバーの設定をトラブルシューティング用として単純で明解なものにする際に役立つ、4 つの推奨設定について説明します。

**マルチホームサーバーの設定。**PPTP サーバーに LAN 用と WAN 用合わせて 2 枚のネットワーク カードを実装している場合は、LAN アダプタ側のゲートウェイを (0 ではなく) ブランクのままにし、WAN ネットワーク インターフェイスのゲートウェイ指定フィールドには ISP によって定義された TCP/IP アドレスを入力してください。通常、ゲートウェイ アドレスは ISP のルーターを指し示しています。LAN のゲートウェイをブランクのままにするのはサーバーがネットワーク パケットをクライアントにルーティングできるようにするためです。LAN のゲートウェイをブランクのままにする方法は、複数のネットワーク アダプタを搭載したサーバーを設定する際の標準的な手順です。テスト目的のため、LAN NIC 用の TCP/IP アドレスと WINS サーバー アドレスは、DHCP による値の割り当てによらず手作業で入力することを推奨します。

**RAS の設定。**RAS をインストールするときは、アクティブなクライアント接続をサポートするために本当に必要な数の VPN ポートだけを設定してください。RAS サーバーはそれぞれ 256 個の同時接続数をサポートできますが (この活動すべてに必要な帯域幅を持っていると仮定した場合)、同時接続ユーザーのサポートに 40 個の同時接続数しか必要としない場合もあります。次に、クライアントの各アドレスを DHCP サーバーからではなく静的なアドレス プールから割り当てるようにサーバーを設定してください。このように、クライアント アドレスを静的なアドレス プールから割り当てるように RAS を設定すると、クライアントが DNS および WINS の設定を RAS サーバーから受け継ぐようになります。RAS サーバーでネットワークを参照できる場合には、クライアントでも同じ設定でネットワークを参照できるはずです。

どうしても DHCP のほうを使用する場合には、DHCP のスコープ オプション 44 (WINS/NetBIOS ネーム サーバー) が WINS サーバーを、スコープ オプション 6 が DNS サーバーのアドレスを、それぞれ指し示していることを確認してください。これらのオプションを定義しないとほとんど確実にクライアントのネットワーク参照問題が発生します。

**PPTP フィルタリングの有効化。**ファイアウォールの外側に常駐している VPN サーバーの設定とテストは、ファイアウォールの内側にあるサーバーの場合よりも簡単です。これは、ファイアウォールを避けることによって、テストおよびデバッグのチェーン内のリンクが 1 つ取り除かれるためです。サーバーを高度に安全な環境で稼動しているのでなければ、サーバーを安心してファイアウォールの外側に設置し、受信する VPN トラフィックを PPTP パケットだけに制限できます。[コントロール パネル] ウィンドウから PPTP のフィルタリングを有効にするには、[ネットワーク] を選択し、[プロトコル] をクリックして、[TCP/IP プロトコル] を選択し、[WAN アダプタ] の [詳細] を順に選択します。そして、 [PPTP のフィルタリングを行う] チェック ボックスをオンにします。PPTP のフィルタリングが有効になると、サーバーが PPTP 以外の要求をすべて拒否するようになります。筆者はこの機能を既にテストしていますが、受信するセッションを VPN 接続に制限する効果的な方法といえます。ただし、PPTP のフィルタリングには重大な副作用が 1 つあります。それは、フィルタリングを有効にした場合、送られてくる HTTP および FTP のトラフィックがフィルタリングによって無効になるため、LAN クライアントにおいて RAS サーバーの WAN 接続を使用したインターネットの参照ができなくなることです。

VPN サーバーで送られてくるパケットを PPTP に制限し、そのサーバーをインターネットにアクセス可能な Web サイトのホストにしたい場合には、フィルタリングされたインターフェイスを通じて送られてくるそのほかのパケットをローカル システムだけに通すように、レジストリを修正できます。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RASPPTPF\Parameters というレジストリ キーのパスに移動し、REG_DWORD データ型 1 の AllowPacketsForLocalMachine という値を追加します。この修正を行うと、RAS サーバーはインターネットに公開されますが、受信する接続は VPN サーバーに制限されます。そのため、リモート クライアントからはネットワーク上のほかのリソースにはアクセスできません。

**ファイアウォールポートの使用。**VPN サーバーをファイアウォールの背後に設置する際は、あらかじめ使用するファイアウォール ソフトウェアが PPTP パケットを受け入れることを確認してください。ファイアウォール ソフトウェア パッケージ (Check Point Software Technologies の FireWall-1 など) によっては、しばしば NAT (ネットワーク アドレス変換) 機能を持つファイアウォールの設定時に PPTP 接続を受け入れないものがあります。このような場合、クライアントが RAS サーバーに接続しようとすると 「Event ID 721 PPP remote peer not responding」 というエラー メッセージが出ます。VPN サーバーをファイアウォールの背後に設置するときは、必ず IP プロトコル 47 (GRE-Generic Routing Encapsulation) と TCP ポート 1723 を有効にしてください。PPTP 接続では、PPTP トンネルの作成、保守および終了といった汎用的な作業の際にポート 1723 を使用します。ポート 47 は、トンネリングされたデータをクライアントとサーバー間で転送します (GRE プロトコルも含まれます)。また、RAS のサーバー間 VPN 接続をサポートする場合には、 TCP ポート 1723 の確立も必要です。

VPN クライアントへの接続を試みる際は、あらかじめ両方のサーバーの NIC の TCP/IP 設定を確認し、RAS サーバーが一般的なネットワーク操作 (LAN のネットワーク参照、LAN リソースへの接続、インターネットへの接続、インターネットの参照) をすべて実行できることを確かめてから、テスト アカウント用のダイヤルアップ権限を有効にしてください。初回のテストで PPP のログ作成を有効にすることもできます。

クライアントのトラブルシューティング

PPTP クライアントを正常に運用するためには、2 組の TCP/IP スタック設定を正しく管理する必要があります。その 1 つは ISP とインターネットの接続用で、もう 1 つは VPN サーバーの接続用です。また、クライアントのルーティング テーブルにも、インターネットを参照するための ISP へのネットワーク パケットを指すものと、LAN を参照するための VPN サーバー インターフェイスを指すものの 2 つのエントリが必要です。これらのスタック設定が正しくないとクライアントで数多くの問題が起こります。一般に、NT のクライアントは TCP/IP のスタック設定を別々に保持していますが、Windows 95 のクライアントでは一般に、ネットワーク カードとモデムを備えている場合にスタック設定に関するトラブルが発生します。Win9x のデフォルト ゲートウェイは PPTP 接続の確立後も ISP を指し示していることがあり、そのためにクライアントから LAN を正しく参照することができなくなります。ここでは、クライアントの接続で頻繁に起きている 5 つの問題について説明します。

**クライアントから PPTP サーバーに接続できない。**1 つ目は、クライアントから PPTP サーバーに接続できないという問題です。この問題の原因については次の 3 つの可能性を調べる必要があります。

  1. VPN サーバーのインターネット接続の確立。クライアントの設定後、VPN サーバーがインターネットに接続していることを確認する必要があります。このための最も簡単な方法は、サーバーの TCP/IP アドレスを指定してクライアントからサーバーに ping を実行することです。ただし、PPTP サーバーがファイアウォールの背後にあり、ファイアウォールによって ICMP-Internet Control Message Protocol- の ping メッセージがブロックされている場合には、この方法は使用できません。ping で 「request timed out 」 というメッセージが表示された場合は、サーバーのインターネット接続に何らかの不具合があります。サーバーがアドレスで応答した場合には、DUN （ダイヤルアップ ネットワーク）エントリの電話番号フィールドにその TCP/IP アドレスを入力することで PPTP セッションを確立できます。この方法は FQDN (完全修飾ドメイン名) よりもわかりにくいですが、サーバーのアドレスがわかっているときには有効な方法です。 ダイヤルアップ接続を備えたサーバーでは、サーバーが ISP に接続するたびに違うアドレスが返される可能性が高いので注意が必要です。アドレスで接続するためには、サーバーからダイヤルアップ接続を行うたびに ISP からサーバーに割り当てられたアドレスを知る必要があります。より一般的には、RAS サーバーに固定アドレスを持たせ、それによって接続処理における 1 個の小さな変数が不要になります。

    サーバーがアドレスで応答した場合は、サーバーを名前で ping します。サーバーが名前で応答しない場合には、サーバーが登録済みのドメイン名を持っていないか、あるいは ISP の DNS サーバーがダウンまたは正常に動作していないかの、2 種類の状況が考えられます。

  2. PPTP のフィルタリングの確認。サーバー上で PPTP のフィルタリングが有効であると、「Error 678: There is no answer」、または 「Error 650: The Remote Access Server is not responding 」 というメッセージが表示されることがあります。サーバーの PPTP のフィルタリングを無効にし (Net Stop RASPPTPF)、フィルタなしの接続を確立できるかどうかを確かめます。

    フィルタリングが無効の状態で接続できる場合には、サーバーのフィルタ設定を確認します。UDP ポート 137 および 138、または TCP ポート 139 を無効にしていると、NetBIOS のパケットがネットワークを往来することができません。また、クライアントとサーバー間にあるユニキャスト (ポイント ツー ポイント) トラフィック用のすべてのファイアウォールとルーターについても、それらのポートを有効にすることが必要です。

  3. GRE プロトコルのフィルタリング。サーバーがアドレスと名前で応答したにもかかわらず依然として接続できない場合には、ISP のルーター、または社内のルーターやファイアウォールが GRE パケットをフィルタリングしている可能性があります。PPTP トンネルを確立するため、クライアントとサーバーでは GRE パケットを交換しますが、ISP によってはルーター管理用に GRE を内部的に使用しているため外部の GRE パケットを無効にしていることがあります。GRE のフィルタリングはあまり一般的ではありませんが、PPTP 接続を妨げることになるため、VPN 接続の両端において IP プロトコル 47 (GRE) と TCP ポート 1723 が有効になっていることを確認します。GRE のフィルタリングは、Microsoft ネットワーク モニタその他のネットワーク監視ツールで特定できます。

**クライアントから接続はできるがログオンができない。**2 つ目は、接続後のクライアントからログオンできないという問題です。この問題の原因については次の 3 つの可能性を調べる必要があります。

  1. ドメイン アカウントとサーバー アカウントの設定。 RAS サーバーはドメイン コントローラまたはスタンドアロン システムとして設定できます。サーバーをドメイン コントローラとして設定している場合には、ユーザーのドメイン アカウントがダイヤルイン権限を持っていることを確認します。サーバーがドメイン コントローラでない場合、既定では RAS はクライアントの資格証明をローカルの SAM (セキュリティ アカウント マネージャ) に対して認証します。ユーザーは 2 つの方法でスタンドアロン サーバーへの認証を行うことができます。1 つは RAS サーバーのローカル アカウントを使用する方法であり、もう 1 つはレジストリを編集し、ドメインの SAM に対する資格証明を強制的にサーバーに認証させる方法です。いずれの場合でも指定するアカウントがダイヤルインの権限を持っている必要があります。

  2. コンピュータ アカウントの設定。クライアントが NT のワークステーションまたはサーバーである場合、コンピュータにはドメイン内のアカウントが必要です。クライアントが新規のシステムの場合には、接続テストを行う前にサーバー マネージャで新しいコンピュータ アカウントを作成します。クライアント システムがネットワーク上のアカウントを既に持っていて、1 週間以上切断された状態である場合には、そのコンピュータ アカウントのパスワードとサーバーのパスワードとが同期していない可能性があります。すべてのコンピュータ アカウントは隠し属性のパスワードを持っており、システムが長期間オフラインにされるとアカウント パスワードが PDC (プライマリ ドメイン コントローラ) とクライアントとで一致しなくなる可能性があるため、このパスワードは PDC によって自動的にリセットされます。通常はアカウントをいったん削除して追加し直すことでこの問題を解決できます。

  3. クライアント認証のネゴシエート。RAS サーバーは、3 つの異なる認証プロトコルを使用して PPTP ユーザーを認証できます。これらをセキュリティが高くなる順に並べると、クリア テキストである PAP (パスワード認証プロトコル)、暗号化とハッシュ処理を行う CHAP (チャレンジ ハンドシェイク式認証プロトコル)、暗号化とチェックサム付き二重ハッシュ処理を行う MSCHAP (Microsoft チャレンジ ハンドシェイク式認証プロトコル)、となります。クライアントとサーバーがログオンの際にネゴシエートする認証プロトコルは、サーバーの受信 VPN ポートとクライアントの PPTP 接続の各ネットワーク設定を行うときに選択する、それぞれの暗号化設定によって決まります。次に示すオプションがサーバー上およびクライアント上で使用できます。

    • クリア テキストを含むすべての認証を許可する。サーバーはクライアントが要求するプロトコル (PAP、CHAP、MSCHAP など) を使用してクライアントを認証します。
    • 暗号化認証を必要とする。サーバーは、MSCHAP、DES (データ暗号化規格)、または SPAP (Shiva PAP) を使用して認証を行います。
    • 暗号化認証を必要とする。サーバーは、MSCHAP、DES (データ暗号化規格)、または SPAP (Shiva PAP) を使用して認証を行います。

暗号化認証を必要とする。サーバーは、MSCHAP、DES (データ暗号化規格)、または SPAP (Shiva PAP) を使用して認証を行います。 Microsoft では SP3 の後に、MSCHAP V2 と呼ばれるさらにセキュリティの高いバージョンの MSCHAP を導入しました。サーバー上および Windows クライアント上でレジストリを編集することにより、クライアントで強制的に MSCHAP V2 だけを使用して認証するようにできます。ただしこの変更を行うと、Windows の専用プロトコルである MSCHAP V2 をサポートしていないクライアントが正常にログオンできなくなり、その結果 UNIX システムや Macintosh システムから VPN サーバーにログオンできなくなる可能性があります。

ログオン障害に関するトラブルシューティング情報を入手するには、ユーザー マネージャでログオン監査を有効にしてから再度接続を試みてください。NT イベント ビューアのセキュリティ ログに記録されたレコードを見れば障害の状況を詳しく調べることができます。たとえば、ユーザー名が無効である、パスワードが間違っている、パスワードが期限切れである、コンピュータに有効なアカウントがない、利用可能な VPN ポートがない、などを確認できます。

ユーザーが正常にログオンしていれば、ログオンの日付と時刻がアプリケーション イベント ログに記録されます。このほか、このイベント ログにはユーザーのログオフ時刻とセッション時間を記録したイベントも含まれています。

**クライアントからログオンはできるが LAN を参照できない。**クライアントからログオンしたにもかかわらず LAN を参照できない、という状況に陥ることもあります。この問題のトラブルシューティングを行うには、まずすべての Win9x クライアント上で、ワークグループを対象の NT ドメイン名に設定していることを確認してください。次に、大規模なネットワークを低速のダイヤルアップ接続で参照すると処理が極度に遅くなるので、15 個から 20 個を超えるノードが表示される場合には、クライアントに対して参照をさせないようにすることもできます。PPTP セッションの確立後に、必要な共有およびリソースへの UNC (汎用名前付け規則) 接続のマッピングをあらかじめ定義しておくか、または手動で行うと、状況が大幅に改善されます。最後に、4 つの TCP/IP 設定についてそれぞれがネットワーク接続にどのような影響を与えるかを理解する必要があります。これらの TCP/IP 設定の詳細については、下の補足 「クライアントの重要な TCP/IP 設定」 を参照してください。固定の高速な接続回線が利用できる在宅作業のユーザーをサポートするときは、LAN をリモートに参照する機能が、実現可能な選択肢の 1 つとなります。これらの構成要素や TCP/IP 設定を確認した後、次に示すサーバーやゲートウェイを使用してネットワーク参照問題のトラブルシューティングを行うことができます。

補足 1: クライアントの重要な TCP/IP 設定

VPN セッションにおける TCP/IP 設定の作用は LAN 接続における TCP/IP 設定の作用と同じです。実装されている VPN のトラブルシューティングを行うには、次の 4 つの TCP/IP 設定について、ネットワークの接続と参照にどのような影響を与えるかを理解する必要があります。

**DNS サーバー。**このサーバーは、FQDN (完全修飾ドメイン名、例 : www.win2000mag.com) をその TCP/IP アドレス (例 : 207.54.25.03) に変換します。DNS サーバーがあり、それが正しく動作していれば、コンピュータからほかのコンピュータの検索と接続を名前で行うことができます。DNS サーバーがない場合、またはサーバーが動作していない場合には、名前によるコンピュータへの接続はできず、接続先コンピュータの TCP/IP アドレスを代わりに使用して接続する必要があります。

**WINS サーバー。**このサーバーは、NetBIOS 名をその TCP/IP アドレスに変換します。Windows NT 4.0 ネットワークでは、すべてのコンピュータが NetBIOS 名を WINS サーバーに登録するか、または利用できる WINS サーバーがない場合はローカルのブラウザに登録します。また、すべてのコンピュータは、公開されている個々のファイルと印刷共有ごとに NetBIOS 名を登録します。クライアントが割り当て済みの WINS サーバーを持っている場合は、必要なセキュリティ資格証明を持っていることを条件に、ネットワーク上の印刷共有を表示して接続できます。クライアントが割り当て済みの WINS サーバーを持っていない場合には [近くのコンピュータ] を参照することはできませんが、UNC 名を手動で入力すれば、共有リソースへのアクセスを許可するセキュリティ資格証明を持っていることを条件に、ファイルと印刷共有に接続できます。

**DHCP サーバー。**このサーバーは最低限の TCP/IP アドレスを、スタートアップ時に LAN クライアントに、また RAS クライアントへの接続時に RAS クライアントに、それぞれ割り当てます。ほかの TCP/IP スタック設定を割り当てるように DHCP サーバーを構成するには、ドメイン名やデフォルト ゲートウェイ、DNS サーバー、WINS サーバーなどに対するスコープ オプションを定義します。

**デフォルトゲートウェイ。**このゲートウェイは、データの送信先がローカル サブネット上に存在しないシステムであるときに、コンピュータに、特定のコンピュータまたはルーターにデータを送信するよう指示します。ゲートウェイの経路は Route Print コマンドで表示されるテーブルの一番上の行に表示されます。

  1. ネットワーク参照の確認。ふつうはネットワークを参照するとき、または特定のサーバーを参照するときにも、「System error 53 has occurred. The network path was not found.」 というメッセージが出ます。このような参照の失敗は、ほとんどの場合クライアントが NetBIOS 名を解決できていないことを意味します。クライアントに WINS サーバーが静的に (PPTP 接続の [ネットワークの設定] で)、または動的に (すべてのクライアントに Ipconfig を使用して、または Win9x クライアントでは Winipcfg を使用して) 割り当てられていることを確認してください。クライアントが WINS サーバーのアドレスを持っていない場合は、アドレスを手入力して再度接続し、もう一度参照を試みてください。

  2. デフォルト ゲートウェイのセットアップ。PPTP 接続のデフォルト ゲートウェイの設定を調べるか、または Route Print コマンドを使用して経路テーブルを印刷してください。ゲートウェイが依然として ISP を示している場合は、すべてのクライアントによる LAN 参照のための要求が VPN 接続ではなく ISP に送られており、ISP 側で NetBIOS 名のブロードキャストに必要なポートをブロックしている可能性があります。UDP ポート 137 および 138、そして TCP ポート 139 においてユニキャスト トラフィックが有効でないと、ルーターやファイアウォールで NetBIOS 名の転送が妨げられることがあるので注意してください。NetBIOS 名は Microsoft 専用の名前であり、ISP によっては ISP 自身のインフラを経由したこのデータの流れを禁止している場合もあります。

    経路テーブルから経路を手作業で削除し、静的な経路を VPN サーバーの仮想インターフェイスに手作業で追加することができます。サーバーの仮想インターフェイスとは、VPN インターフェイスに割り当てられたアドレスのことです。このアドレスは、アドレス プール内の最初のアドレスか、または RAS サーバー設定内で最初に利用可能な DHCP アドレスのどちらかになります。

  3. NetBEUI の有効化。TCP/IP だけしか使用しないというユーザーでなければ、ほとんどの場合において RAS サーバー上およびリモート クライアント上に常に NetBEUI をインストールすることで、クライアントのネットワーク参照問題を解決できます。サーバーの VPN ポートに送られてくる接続に対して NetBEUI を有効にし、クライアントの PPTP 接続で [NetBEUI プロトコル] チェック ボックスをオンにします。これ以降、クライアントは TCP/IP 経由の NetBEUI を使用してサーバーに接続します。ただし現状では、NetBIOS ベースの NT 名前空間に固有の制限を回避することができません。この NetBEUI オプションによる方法は、第三者に技術的な影響を与える可能性もありますが、完全なネットワーク参照を可能にする LAN を実現するための最も簡単な方法であるといえるでしょう。

    以上の措置を講じても依然としてクライアントでネットワーク参照ができない場合は、クライアントからネットワーク共有への接続を試みてください。たとえば、net use z: \\myserver\myshare コマンドなどを使用します。共有への手動接続は、トラブルシューティング作業の間もユーザーがファイルやプリンタにアクセスできるため、しばしば有効な問題回避手段として使用されます。

    この段階でもまだ参照できないという場合には、VPN サーバーの設定を再確認する必要があります。クライアントのネットワーク参照に影響を与えるサーバー関連の問題は数多くありますが、潜在的なものを含めてその問題と解決の説明には多大な紙面を必要とするため、この記事では触れていません。マイクロソフトサポート技術情報で各トピックを検索すれば、参考となる有益な情報が多数見つかります。このサイトでは、マルチホーム サーバーとネットワーク参照に関する問題 (個々の NIC 上のブラウザが参照 リストを交換しないなど) をはじめ、PPTP 接続や WINS サーバーの設置場所などに関する問題が取り上げられており、検索によってそれらの記事や文書の一覧が得られます。

**接続後のクライアントからインターネットを参照できない。**筆者は、ネットワーク カードとモデムの両方を備えている Win95 クライアントで何度かこの問題に遭遇したことがあります。クライアントは VPN セッションがアクティブである間、インターネットにアクセスすることができません。この問題の原因としてはよくある 2 つのシナリオが考えられます。1 つは、リモート クライアントが接続しているときに VPN サーバーがリモート クライアントからインターネットへのアクセスを許可しない場合です。この場合は、VPN 接続を閉じた時点でデフォルト ゲートウェイが ISP で定義された元のゲートウェイに戻るため、その時点でクライアントからインターネットを参照できるようになります。もう 1 つは、Win95 がクライアントの接続時に ISP のゲートウェイを VPN サーバーで定義されたゲートウェイに書き換えてしまい、クライアントでインターネットへのパス情報がなくなってしまう場合です。この場合には、2 つの段階を踏んで静的経路を ISP のデフォルト ゲートウェイに手動で追加する (つまり、最初に VPN のゲートウェイを試み、次に ISP のゲートウェイを試みる) ことで、問題を解決できます。

**接続後のクライアントが [近くのコンピュータ] に表示されない。**筆者が作業をともにしたネットワーク エンジニアが、VPN クライアント接続が完璧に機能していたにもかかわらず LAN 側の [近くのコンピュータ] にクライアントが表示されない、という問題に直面したことがあります。クライアントの PPTP 接続は TCP/IP だけを使用して設定しており、VPN サーバーへの接続と認証が完了した後、クライアントからすべての LAN リソースを参照できるようになります。リモート クライアントで [近くのコンピュータ] を展開表示すると、その参照 リストに [近くのコンピュータ] それ自身とほかのクライアントが表示されますが、リモート システムが LAN 上の [近くのコンピュータ] に表示されることは決してありません。リモート クライアントを LAN の参照 リスト上に表示したい場合は、RAS サーバー上と各 RAS クライアント上に NetBEUI をインストールする必要があります。このような特異な現象は RAS 関連の問題として知られていますが、執筆時点ではその解決方法はわかっていません。

ついに準備完了

以上で、VPN の設定と接続に関する一般的な問題のほとんどについて説明しました。今ではトラブルシューティングに役立つ多くのヒントがツールキットに収められています。これらの手法は非常に魅力的できわめて人気が高く、Windows 2000 (Win2K) のトンネリング プロトコルや IPSec (インターネット プロトコル セキュリティ) の標準的な実装を活用する管理者に広く採用されると推測します。必ず簡単なことから作業を始め、一度に 1 つずつ手順を実行するようにしてください。

著者について

Paula Sharickは『Windows 2000 Magazine』の編集者兼オンライン コラムニストであり、Windows NT ネットワークの設計、実装、および相互運用を専門とするコンサルタントでもあります。