Windows の VPN がローカルプリンターを殺す理由と止め方
フルトンネルのクライアントはデフォルトルートを所有するため、プリンターと NAS が応答しなくなります。そのルートを外し、必要な業務プレフィックスを追加し直します。
VPN に接続するとプリンターが消え、NAS 共有が開かなくなり、隣のマシンへのリモートデスクトップセッションがタイムアウトします。壊れたものは何もありません。クライアントがデフォルトルートを追加し、今やノート PC が名前を挙げられるすべての宛先を、三メートル先のものも含めて所有しています。これが仕組みのすべてであり、これを VPN の障害と呼ぶことが、一行の修正をサポート案件に変えてしまうのです。
まずルートテーブルを読む
何かを変える前に、route print -4 で IPv4 テーブルを取得し、出力を保存します。接続し直して取得し、0.0.0.0 の行を比較します: アクティブなデフォルトルートがインターフェースを示しており、そのインターフェースがトンネルなら、ローカルの印刷と閲覧はまずオフィスへ送られています。
二列目のインターフェース番号は、永続ルートが後で参照する値なので、トンネルが上がっている間に控えておきます。これはアダプターが作り直されると変わる値でもあり、そのためそこに固定したルートは静かに役目を終えることがあります。
デフォルトルートを外す、三つの方法
組み込みの Windows プロファイルでは、コントロールはチェックボックスです。接続のプロパティを開き、IPv4、次に詳細設定と進んで、Use default gateway on remote network のチェックを外します。新しい設定アプリでは同じダイアログが一段深くに隠れていますが、昇格したコマンドプロンプトからなら同じ変更は一つの cmdlet です:
Set-VpnConnection -Name "Corp" -SplitTunneling $true
OpenVPN プロファイルは動作が異なり、チェックボックスを期待する人を戸惑わせます。その redirect-gateway def1 ディレクティブはデフォルトルートをまったく置き換えず、代わりに半区間のルートを二本、0.0.0.0/1 と 128.0.0.0/1 を入れ、この二本が合わさってデフォルトに勝ちます。元のデフォルトが残るので、net_gateway を指すプレフィックスを加えると、そのプレフィックスだけがローカルルーターへ戻ります。この詳細が、def1 プロファイルの修正が誰も見つけられないチェックボックスではなくプレフィックスルートである理由を説明します。
業務に属するものだけを戻す
デフォルトルートが消えるとトンネルは何も運ばないため、業務プレフィックスは明示的に指定する必要があり、プレフィックスを接続に結び付ける cmdlet は永続ルートより安全です。その接続が上がっている間だけインストールされ、インターフェース番号に依存しないからです:
Add-VpnConnectionRoute -ConnectionName "Corp" -DestinationPrefix 172.20.0.0/16
古い方法もまだ機能し、まだどのチェックリストにもあります: route -p add 172.20.0.0 mask 255.255.0.0 172.20.0.1 if 14、トンネル自身のインターフェースインデックスとゲートウェイアドレスを添えて。再起動をまたいで残るのが利点であり危険でもあり、次の起動ではインデックスが別のものの所有になっているかもしれません。
残りはメトリックが決めます。物理アダプターとトンネルアダプターの両方が同じプレフィックスのルートを主張する場合、低いメトリックが勝ち、トンネルのメトリックを上げるのはハックではなくクライアント側の正当な制御です。
サーバーが代わりに決めるとき
チェックボックスを無視するクライアントは通常、ポリシーに従っています。Cisco プロファイルには Allow Local LAN Access 設定があり、ヘッドエンドはクライアントの希望を上書きする tunnel-all ポリシーを push できます。強制トンネルの配備では切り替えるローカルスイッチがなく、同じダイアログを再確認するのではなく、push されたルートとポリシー行についてクライアントログを読みます。
次に、ルーティングとは別のスイッチである名前解決を見ます。分割トンネルでも内部リゾルバーと検索サフィックスを受け取ることがあるため、DNS 側も直るまで、ローカル機器はアドレスでは届いても名前では見つかりません。
重複は別の問題
自宅の LAN とオフィスの LAN が 192.168.0.0/24 のようなプレフィックスを共有していると、どのルートでも区別できません。その範囲の各パケットは検索結果が一つしかなく、修正は片側を振り直すか、プールから変換されたアドレスでオフィスに到達することです。より具体的なルートを足しても、ネットワークのどちら半分が壊れるかが変わるだけです。
五つではなく一つの検証で終えます: 接続してから tracert を内部ホストと公開ホストに対して実行します。最初のホップは異なるはずで、そうでなければクライアントが何を報告しても分割は効いていません。push されたルートはセッションごとに戻ってくるため、その後にもう一度接続し直して繰り返します。