動作しているスプリットトンネルの経路を変更せずに、最も具体的な双方向ルートを追加して、欠落しているNASサブネットを復元します。
ホームVPNでは、トンネルが接続されていて他のプライベートサブネットにアクセスできるにもかかわらず、1つのNASネットワークが消えることがあります。通常の原因はNASサービス自体ではなく、ルートの欠落、より広範なローカルルートの優先、重複するホームネットワークのプレフィックス、誤ったトンネルゲートウェイ、またはVPNクライアントへの戻り経路が不明なことです。最も安全な修正方法は、動作しているサブネットと隠れているサブネットを比較し、1つずつルートの決定を修正し、トンネルを広げる前に順方向と戻りの両方のトラフィックを検証することです。
欠落しているNASサブネットが1つだけであることを証明する
VPNに接続し、VPNゲートウェイ、動作している既知のプライベートサブネット、そして失敗しているNASサブネットの3つの宛先を別々にテストします。DNS、SMB検出、ホスト名がルーティング結果を曖昧にしないよう、まずは直接IPアドレスを使用してください。
スプリットトンネルは選択された宛先プレフィックスのみをVPN経由で送信し、その他のトラフィックはクライアントの通常のデフォルトルートに従います。サブネット固有のスプリットルートの実用的な説明では、クライアントがVPNネットワーク自体を到達可能とみなしながら、隣接するプライベートサブネットを誤ったゲートウェイに送ることがあると示しています。
VPNゲートウェイと他のリモートサブネットが動作している場合、トンネルと認証はすでに確立されています。診断は欠落しているNASプレフィックス、ルートの優先度、ファイアウォールポリシー、戻り経路に集中し、VPN構成全体の再構築は避けてください。
動作しているアドレスと失敗しているアドレスのルートを比較する
トンネル接続後にクライアントのルートテーブルを調べ、動作しているリモートアドレスとNASアドレスのそれぞれに選択されたルートを確認します。宛先プレフィックス、プレフィックス長、メトリック、インターフェース、次ホップを記録してください。
存在するルートが必ずしも優先されるルートとは限りません。OSは通常、最長一致プレフィックスを優先するため、ローカルの192.168.1.0/24ルートが、重複する正確なアドレスに対してより広範なVPNルート192.168.0.0/16を上書きすることがあります。
NASアドレスがローカルのWi-Fiまたはイーサネットゲートウェイに従っている場合は、NASサブネット用により具体的なVPNルートを追加または広告してください。すでにトンネルに従っている場合は、クライアントルートの重複追加ではなく、VPNポリシー、リモート転送、戻りルーティングを確認してください。
クライアントネットワークとNASネットワークの重複を解消する
リモートクライアントの現在の場所で使用されているプライベートサブネットとホームVPNの背後にあるプライベートサブネットを比較します。ホテル、オフィス、モバイルホットスポット、他の家庭では、192.168.0.0/24や192.168.1.0/24などの一般的な範囲がよく再利用されています。
現在のGlobalProtectの議論では、広範なスプリットルートがクライアントのローカルプライベートネットワークと競合する事例が説明されています。クライアントはNASアドレスが近くのWi-Fi上にあると誤認し、パケットをVPNに送らない可能性があります。
最もクリーンな長期的解決策は、ホームNAS VLANまたはリモートLANの番号をより一般的でないプレフィックスに変更することです。番号変更が不可能な場合は、翻訳されたVPNサブネット、ホスト固有ルート、アプリケーションプロキシ、または重複を明確に解決するVPN設計を使用し、曖昧なプライベートアドレスに頼らないようにしてください。
スプリットトンネルのプレフィックスとゲートウェイを修正する
サーバー側の含まれるルートまたは許可されたサブネットのリストを確認し、正確なNASネットワークと正しいマスクが含まれていることを確認してください。/25のようなタイプミスは、意図したアドレスの半分だけを隠すことがあります。
Cisco VPNの事例では、VPNアドレスプール自体は正しく見えても、誤ったルートゲートウェイでスプリットルートがインストールされていることがありました。これが、設定されたルートラベルよりも実際のクライアントルートが重要な理由です。
古いまたは重複したルートを削除し、VPNを再接続して、NASプレフィックスに対して1つの権威あるルートが表示されることを確認してください。完全トンネルが意図された設計でない限り、トンネル経由のデフォルトルートは追加しないでください。1つのサブネットの修正で全インターネットトラフィックを静かにリダイレクトすべきではありません。
転送、ファイアウォール、および戻りルートを検証する
クライアントがNASアドレスにpingを送信している間、VPNゲートウェイでトラフィックをキャプチャまたはログ記録します。パケットがトンネルに入るがNAS VLANに向かって出ていかない場合は、IP転送、インターフェース間のファイアウォールルール、およびVPNゲートウェイからそのサブネットへのルートを調査してください。
スプリットトンネルの実装ガイドでは、ルートのインストールは転送とファイアウォールポリシーの一致とペアでなければならないと強調しています。クライアント側のルートだけではVPNゲートウェイが別のVLANにトラフィックを転送することはできません。
次に、NASサブネットのルーターがVPNクライアントプールへの戻りルートを持っていることを確認してください。返信が通常のインターネットゲートウェイを使う場合は、戻りルートを追加するか、VPNゲートウェイで慎重に範囲を限定したソースNATを適用してください。返信なしで一方向のキャプチャが成功した場合は戻り経路の失敗であり、クライアントルートを変更し続ける理由ではありません。
他の経路を壊さずにNASサービスを再テストする
IP到達性が確立したら、IPおよびホスト名で実際のNASサービスをテストします。pingが成功しただけでアプリケーション経路が保証されるわけではないため、SMB、ウェブダッシュボード、または必要なアプリポートを確認してください。
ZimaSpaceのVPNからLANへの経路が欠落するケースのガイドは、トンネル接続があってもすべてのLANトラフィックタイプが同じ経路をたどるとは限らないことを示しています。
修復したNASサブネット、以前に動作していたリモートサブネット、通常のインターネットアクセスをテストして終了します。3つすべてが設計通りに動作し、ルートが再接続後も維持され、クライアントがネットワーク変更ごとに手動コマンドを必要としない場合にのみ変更を保持してください。
サポートとヒント
もっと読む

How to Reduce Plex Database Contention on a Busy Docker Host
A Plex configuration guide for busy hosts that treats the database as local application state and reduces I/O contention without inventing a shared DB...

How to Prevent Duplicate Plex Scans and Imports
A prevention guide for duplicate Plex scans and imports that removes overlapping triggers instead of disabling library updates entirely.

How to Recover Plex After Its App-Data Volume Fills Up
A recovery ladder for full Plex app-data volumes that protects the database first and avoids deleting unknown files just to make the service start.

