VPN経由でNASに到達できない：アドレス、戻り経路、それともサービス？
プライベートトンネルにはNASへの経路、応答経路、許可されたサービスが必要です。認証情報を変更する前に、三つのうちどれが失敗したのかを判断してください。
トンネルは上がり、クライアントはアドレスを受け取り、NASはまったく応答しません。この一つの症状には三つの無関係な障害が隠れており、どの順で切り分けるかが復旧までの時間を決めます。まずアドレッシングです。重複したサブネットは、あなたの要求を別の機器へ送ってしまうからです。次に戻り経路です。応答が返らない要求は、閉じたサービスとまったく同じに見えるからです。サービスと権限は最後で、最初の二つが証明されてから確認します。
どれも到達不能に見える三つの障害
アドレスの選択、戻りルーティング、サービスの認可は、どれも同じ見え方のメッセージを生みます。何も起きない、というメッセージです。証拠も担当も対処も異なるので、これらを切り分けることが作業のすべてです。失敗したpingだけではほとんど何も証明できず、TCPの拒否が返るのはむしろ良い知らせです。
| Observation | Most likely conclusion |
|---|---|
| Route to the NAS address leaves the wrong interface | Overlapping or missing private route |
| Request visible on the server, no reply seen | Return path, gateway forwarding or translation |
| TCP connection refused rather than dropped | Reachable host, service not listening or filtered |
| TCP works, login or file access fails | Share permission, account or protocol version |
表は原因の一覧ではなく、検査の順序として読んでください。拒否が返った時点でアドレッシングと戻り経路は動いていると証明済みなので、各行は次の行を制約します。経路がどのインターフェースを選んだかを確認する前にファイアウォール規則の中で二十分を費やすのが、午後を失う最も一般的な道です。上から下へ進み、最初に一致した行で止めてください。
条件その一：そのアドレスは正しい機器か？
NASのサブネットと、VPNがクライアントに渡す範囲を書き出し、両方をいま自分のノートPCが接続しているネットワークと比べてください。この手順ではNASは10.40.7.25にあり、VPNプールは10.40.9.0/24です。一つの拠点計画の中の別々のプライベート範囲であり、192.168.0.0/24や10.0.0.0/24を使う家庭はどちらかと衝突する確率がはるかに高くなります。
ローカルネットワークとNASのネットワークが重複すると、クライアントはその通信を自分のゲートウェイへ送り、たまたま同じアドレスを持つ無関係な機器に届いてしまうことがあります。応答する何かに認証情報を入力する前に、経路を確認してください。
ip -4 route get 10.40.7.25
traceroute -n -m 5 10.40.7.25最初のコマンドはカーネルが使うインターフェースとゲートウェイを示し、二つ目は実際に応答する最初のホップを表示します。両者が食い違うなら、経路検索を信じてください。パケットはそちらを通るからです。NASの一つ手前で止まるホップ一覧も、失敗ではなく発見です。トンネルではなく物理アダプターに解決されるなら、その時点で調査は終わりです。
条件その二：応答は戻ってくるか？
クライアントにはNASへの経路が必要で、NAS側のネットワークにはVPNプールへの戻り経路が必要です。ゲートウェイの転送、ファイアウォール規則、意図的なアドレス変換は、それぞれこの組に影響します。strongSwanの転送に関する注意書き はゲートウェイ背後のプライベートサブネットについて、戻り経路と変換の選択肢を説明しています。
要求が届き、応答が別のゲートウェイから出ていく場合、DNSの変更では非対称性は直りません。両側でのキャプチャが一度で決着をつけ、変換がNASの応答先アドレスを書き換えたかどうかも示します。管理者はその境界の責任者です。必要なサービスとVPNクライアントの範囲だけを許可し、ルーティングと変換のどちらを選んだかを記録してください。
条件その三：サービスはそこにあり、許可されているか？
管理ページとファイル共有サービスは同じ筐体の別の端点であり、片方が接続を受け付けている間に、もう片方がホストのファイアウォール、サービスの設定、共有権限で塞がれていることがあります。拒否を返す機器はすでに最初の二条件を証明しており、三つ目はかなり絞り込まれます。
セットアップで使った管理者アカウントではなく、実際にファイルを必要とするアカウントで試してください。管理者権限は欠けた経路を直せませんし、経路は共有権限を与えられません。名前もここに含まれ、自宅で見つかるNAS名はローカルマルチキャストに依存することが多くてルーティングされたトンネルでは運ばれないため、ベンダーが文書化したプライベートなホスト名かアドレスそのものを試して名前解決とアクセスを切り分けてください。
NASのネットワークの外から試し、それから少しずつ広げる
同じLANで行う試験は、遠隔経路の未完成な部分をすべて隠します。だからこそ最初の成功した遠隔の試行は変更記録に残す価値があります。NASにトンネル経由でしか届かないクライアントから検査を実行し、各試行の元のエラーテキストを保存してください。
nc -vz 10.40.7.25 445
smbclient -L 10.40.7.25 -U guest経路が動いたら、無害なファイルを転送し、実際に必要な読み書きの挙動を確認してください。大きな転送が止まり小さな転送が通るなら、残る問題はパケットサイズの扱いか接続の安定性で、アドレッシングではありません。
説明のつかない不具合を避けるために、ファイル共有や管理のポートをインターネットへ公開しないでください。プライベート経路を直し、NASのソフトウェアをサポートされた状態に保ち、そのバックアップに頼る前に、そこを通して取るバックアップの復元を試験してください。