Global VPN Client が Acquiring IP のまま止まると、パスワードを打ち直すかクライアントを再インストールしたくなります。どちらも失敗した段階には触れていません。認証はクライアントがアドレスを要求する前に完了しているので、その行で止めているのは資格情報ではありません。そこに留めているのは完了していない DHCP のやり取りであり、三つの異なる場所で停滞し得ます。

認証とアドレス割り当ては別の段階

GVC はまずあなたが誰かを証明し、次に接続に割り当てられたポリシーに従って仮想アダプターの設定を要求します。これらは失敗の兆候が異なる連続した手順です。資格情報の誤りは通常もっと早く失敗し、アドレスの行ではなく認証やネゴシエーションのメッセージが出ます。

この順序が、パスワードのリセット、新しいローカルユーザー、再インストールがここで何も変えない理由です。クライアントはすでに承認されており、今はゲートウェイかその DHCP パートナーが供給すべきリースを待っています。ユーザーを許可してもアドレス範囲を割り当てないポリシーでも、まったく同じ画面になります。

したがって最初の有用な問いは、資格情報が正しいかではなく、どのポリシーが割り当てられ、それが仮想アダプターのアドレスについて何を言っているかです。同僚の動く画面写真ではなく、その接続の実際の構成を読んでください。

リースは実際どこから来るのか

よくあるのは二つのモデルです。ファイアウォール自身が VPN クライアント用の DHCP スコープを動かすか、内部ネットワーク上の外部 DHCP サーバーに要求を転送します。どちらかによって、どのログが重要で誰に連絡すべきかが決まります。

内部モデルでは、スコープがまだ存在し、正しいインターフェースに属し、空きリースがあることを確認します。使い切ったスコープでは、認証は完璧なのにアドレスを決して受け取らないクライアントが生まれ、ゲートウェイのログには要求だけが残ることがあります。転送モデルでは、転送先、VPN クライアント範囲への戻り経路、内部 DHCP の認可がすべて揃っている必要があります。

何かを試す前に、導入がどちらのモデルを使うかを書き留めてください。ネット上の矛盾する助言の半分はもう一方を前提にしています。

トンネルは上がっていてもリースを落とすことがある

確立した制御接続はネゴシエーションが成功したことを示すだけで、トンネル化されたデータが双方向に通ることは示していません。DHCP のやり取りは要求と応答がデータ経路を通過する必要があり、そこに暗号化設定、VPN ゾーンのポリシー、MTU の問題があります。

NAT トラバーサルの助言は、文脈が重要である最も明快な例です。有効にする必要がある経路もあれば、無効でしか動かない経路もあり、途中の NAT とネゴシエーション済みの接続がどちらかを決めます。クライアント設定も変えながら闇雲に変えると、どの変更が結果を生んだのか分からなくなります。カプセル化を変える前に、ネゴシエーション済みの経路と証拠を記録してください。

自宅ルーターの再起動も同じ範疇です。症状が消えることはありますが、リースがなぜ失敗したかは特定できず、次の接続で問題が再発します。

リースの経路を順にたどる

アダプターから外側へ進み、各手順が一つの理由でしか失敗しないようにします:

> Get-NetAdapter | Where-Object Name -like "*GVC*"
> ipconfig /all | findstr /i /c:"GVC" /c:"IPv4" /c:"DHCP"
> Test-NetConnection 10.60.0.1 -Port 443

169.254.x.x のようなアドレスは、アダプターが存在し応答をまったく受け取っていないことを意味し、リースの供給元かデータ経路を示します。VPN 範囲内の正しいアドレスで DNS エントリが誤っているのは別の障害です:リースは機能し、ポリシーが不完全な設定を渡しました。アダプターがまったく現れない場合は、クライアントがそれを作るまで至っていません。

リースが現れたら、アドレスの行で勝利を宣言するのではなく実際のリソースを試してください。ファイルやイントラネットへのアクセスがまだ失敗するなら、成功したリースを証拠として残し、名前解決かポリシーへ進んでください、元の障害はすでに置き去りにしているからです。

仮想アダプターに関する SonicWall の注記 はいくつかの別々の分岐を挙げており、古い画面写真を現在のメニュー地図として読むべきではありません。到達した段階を確認するために使い、丸ごと適用するチェックリストとして使わないでください。

関連記事