VPN接続でプリンターがオフライン？ルートテーブルを確認しよう

ノートパソコンが社内VPNに参加すると、二メートル先のプリンターが応答しなくなります。プリンター側は何も変わっておらず、ローカルネットワークも落ちていません。変わったのはルートテーブルです。トンネルアダプターがプリンターのアドレスを覆う経路を持つようになったため、そのパケットはVPNを通って、あなたのフラットなネットワークがどこにあるか知らないゲートウェイに届きます。以下の四つの確認を順番に行い、最初に失敗したところで止めてください。

ステップ一: プリンターがLAN上でまだ到達可能であることを証明する

ルーティングに触れる前に、VPNを使わない何かに対してデバイスが生きていることを確認します。同じWi-Fi上のスマートフォンでプリンターのWebページを開くか、フラットなネットワーク上の別のマシンからアドレスにpingを送ります。プリンターがそこでも応答しない場合、VPNは偶然であり、原因はプリンター、そのWi-Fi接続、またはアクセスポイントのクライアント分離にあります。

このノートパソコン以外のすべての場所で応答するなら、ノートパソコン内に住むルーティングまたは名前解決の問題があり、次のステップでどちらなのかが分かります。

ステップ二: Windowsが実際に選ぶルートを突き止める

テーブルを上から順に読んで推測してはいけません。気にしている正確なアドレスに対してWindowsがどのエントリを選ぶかを尋ね、同時にインターフェースインデックスを取得します。

Find-NetRoute -RemoteIPAddress 192.168.1.50
route print -4
tracert -d 192.168.1.50

Find-NetRoute は勝者ルートとそのインターフェースを出力し、残りのすべてはこの二つの事実に依存します。route print -4 は周囲のエントリを表示し、フルトンネルクライアントがインストールする二つのハーフデフォルトも含まれます。0.0.0.0/1 と 128.0.0.0/1 は合わせてIPv4空間全体を覆い、0.0.0.0/0 を決して置き換えません。/1 は /0 より長いですが、あなたの 192.168.1.0/24 はさらに長く、だからこそ欠けているLANルートはトンネルの主張そのものより重要なのです。

答えを決めるのは二つの規則です。最も長く一致するプレフィックスが最初に勝ち、同じプレフィックスのエントリ間では合計メトリックが低い方が勝ちます。合計はルートメトリックとインターフェースメトリックを組み合わせたものです。選択されたインターフェースがトンネルなら続行します。物理アダプターなのに通信がまだ失敗するなら、ここで止めてください。問題は名前解決かプリンター自身のアクセスリストであり、VPNルートではありません。

ステップ三: ゲートウェイとインターフェースを指定する最も狭いルートを追加する

修復は、プリンターのアドレスをローカルアダプター上のローカルルーターに向けるエントリ一つです。昇格したコマンドプロンプトで実行し、たった今読んだ値に置き換えてください。

route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 if 12 -p

if の値は物理アダプターのインターフェースインデックスです。これを省略することが、コマンドが成功したように見えて何も変わらない最も一般的な理由です。同じネクストホップに到達できるアダプターが二つあると、Windowsは望まない方を選ぶ自由があるからです。-p フラグはエントリを永続化するので、セッションとともに消えるのではなく再起動後も残ります。

単一デバイスには、192.168.1.0/24 全体へのルートよりもホストルートを優先してください。サブネットルートはタスクが必要とするより広く、社内側も同じプレフィックスを使う瞬間に衝突します。一つのプレフィックスに二人の所有者ができ、どちらのエントリが勝つかで実際に到達できるネットワークが決まります。

逆方向として、LANを守るためにVPN接続で デフォルトゲートウェイのオプションを消去した 場合、リモートのプライベートプレフィックスも解決されなくなります。それらへのルートも同じ方法でVPNインターフェース経由で追加してください。さもなければトンネルは何も運ばないリンクになります。

ステップ四: 例外を次の接続後も生き残らせる

多くの社内クライアントは接続のたびにルートセット全体を再インストールし、その際にインターフェースメトリックを再計算するため、昨日機能したルートが今日は負けることがあります。再接続後にプリンターに対して Find-NetRoute を繰り返し、インターフェースがまだ物理アダプターと一致するか確認します。エントリが消えているなら、何かが削除しています。永続ルートはテーブルを掃除するエージェントからあなたを守りません。VPN接続後にルートを再追加するスケジュールタスクが通常の回避策で、ドックやドライバー更新の後にアダプターインデックスが変わると壊れるのも同じ回避策です。

IPv6は別に見てください。IPv4のデフォルトだけを主張するクライアントは、IPv6のデフォルトルートを物理アダプターに残すことがあり、IPv6で到達できるプリンターはIPv4が失敗している間も動き続けます。またはその逆です。ルートテーブルが無実だと判断する前に、ping -4 と ping -6 で試してください。

ローカルの近道があなたに払わせるもの

トンネルを迂回するルートはすべて、トンネルの約束に開いた穴です。そのアドレスへの通信は社内ゲートウェイを通らなくなり、検査もログもポリシー適用も受けません。管理されたデバイスでは、それは好みではなくコンプライアンスの問題になり得ます。手動で一つ追加する前に、公式のスプリットトンネル例外があるか尋ねてください。自分のルートはタスクに必要なだけ狭く、状況が許すだけ短命に保ちます。

変更後にプリンターが応答するなら、修正が保たれたと決めつけず、次に再接続した後に四つの確認を繰り返してください。応答しないなら、接続の前後で Find-NetRoute の出力を取得してください。違いを見れば、クライアントがエントリを削除したのか、順位を付け直しただけなのかが分かります。