VPNクライアントを有効にしたままLANアドレスへpingするとGeneral failure
ルートテーブルは正しく見えるのに、Windowsはアダプターにまったく到達できないと報告します。遮断がルーティングか、フィルタリングか、クライアントかを切り分けます。
ホストルートが一本、アドレスが一つ、そしてpingは要求がタイムアウトするのではなく、すぐにGeneral failureで失敗します。この違いが診断のすべてです。タイムアウトはパケットが出て行き、何かがそれを無視したという意味です。General failureは、Windowsがそもそもパケットをどのインターフェースにも渡せなかったという意味です。
つまり、ルートテーブルが完璧に見えるのにエラーがGeneral failureのままであれば、遮断はルーティングの判断より下で起きており、そこで動いているのはプロバイダーのクライアントです。
ルートテーブルより先にエラーを読む
Windowsは送信先のインターフェースを見つけられないときにこのエラーを返し、宛先がパケットをどう扱ったかについては何も語りません。到達性、遠端のファイアウォール、サービスの可用性は、まだたどり着いていない後段の問いです。
このケースの定番構成は、一つのLANアドレスを物理ゲートウェイに向けるホストルートでトンネルを迂回させ、route addはそれを受け入れ、route printはそれを表示し、それでもpingは失敗します。フィルタードライバーがすでにパケットの外出を不許可と決めているからです。
その説明を受け入れる前に、ルートが実際に選ばれていることを確認してください(インターフェースのインデックスとメトリックを調べ、再接続後にエントリが古くなっていないか確かめます)。存在しないインターフェースを指すルートは、ずっと退屈な理由で似たエラーを出します。
三つの層、三人の別の所有者
勝つのは最後に動く層であり、この三つは多くの人が想定する順序にはなっていません。
| Layer | What it decides |
|---|---|
| Routing table | Which interface and next hop should carry the packet |
| Client filter driver | Whether this packet is permitted to leave outside the tunnel at all |
| Client feature | Whether a named feature, such as LAN blocking, is active right now |
中間の層こそ、ルートが正しいまま役に立たない理由です。プロバイダーのクライアントは、トンネルの外の通信を捨てるためにフィルターとファイアウォール規則を導入し、それがキルスイッチを実装するのと同じ仕組みです。ルートテーブルの何もその判断に関与していません。
三番目の層は、クライアントを切断した後でもローカルサブネットに到達できないという、定期的に届く奇妙な報告を説明します。サービスは動き続け、フィルターも入ったままなので、接続していないことはフィルタリングしていないことと同じではありません。何かを結論づける前に、単に切断するのではなくクライアントを終了してください。
順番に試すこと
外すのが安く、戻すのが簡単な機能から外していきます。LAN検出は、LAN上での不可視性と呼ばれることもあり、プライベートアドレス範囲への通信を遮断して、マシンを隣人から隠します。プリンターもローカルのファイルサーバーもルーター自体も、そのスイッチの向こうへ消えます。DNSをフィルタリングする脅威対策機能は独自のフックを入れ、ローカルの到達性をほぼ同じように壊すと報告されています。
両方をオフにし、クライアントを完全に終了してから、そのアドレスを試してください。この順序なら、通信を遮断する機能と、通信を誤ってルーティングするトンネルを切り分けられ、静的なルートで半日つぶす代わりに二分で済みます。
ping 192.168.1.50
tracert -d 192.168.1.50
route print -4
機能をオフにしただけでアドレスが応答すれば、故障ではなくポリシーの判断であり、機能をオフのままにするか、例外を追加するか、マシンがローカルネットワーク上で見えないままであることを受け入れるかを選びます。
クライアントの例外経路を狭く使う
機能を有効のままにしなければならない場合、クライアント自身の分割トンネリングがサポートされた逃げ道です。例外は要件が許す範囲で最小に保ちます(通常は、一台のサーバーに対して一つのホストアドレス、一つのセグメントに対して一つのプレフィックスです)。プライベート範囲全体を覆う規則は、誰も追加したことを覚えておらず、誰も削除しようとしない恒久的な穴です。
次に、まずアドレスで、そのあと名前で確認します。アドレスが物理ゲートウェイへの最初のホップで応答すれば、例外は効いています。名前がまだ失敗するなら、トンネルのリゾルバーがローカルゾーンを知らずルーティングの変更でもそれを教えられないため、DNSに移っています。
ルートか例外のどちらか一方だけを残し、どちらが仕事をしているかをメモします。重なり合う二つの仕組みは互いを隠し、次にこのマシンをデバッグする人は片方を外して、何も変わらないのを見ることになります。
クライアント自体が障害のとき
一部のビルドは、静的ルートでもクライアントの例外でも打ち勝てない方法で通信をフィルタリングします。そうだと分かった場合、正直な選択肢はバイパス機能を待つか、プロバイダー自身のプロファイルを使って素のOpenVPNクライアントで接続することであり、元の報告でベンダーサポートが勧めていたのもこれです。
その置き換えを行う前に、取引を理解してください。素のプロファイルは普通のトンネルと同じように振る舞い、自分のルートを入れ、スタックの残りを組み替えないので、狭いホストルートは期待どおりに動き続けます。失うのは、ブランド版クライアントがトンネルの周りに実装したすべてで、キルスイッチやDNSフィルタリングも含まれ、それらは意図して作り直すか、存在しないものとして受け入れる必要があります。
どちらを選んでも、どの層が遮断を持っていたかを記録してください。マシンから一度も出なかったパケットはフィルターの結果であり、ルーティングの変更でフィルターは直せません。