サイト VPN 経由のマップ済みドライブ:DNS、SMB、UNC パス
ネットワーク探索はルーティングされたリンクを越えませんが、名前付きの UNC パスは越えます。DNS をサーバーに向け、SMB を両方向で開き、それからドライブをマップします。
エクスプローラーの「ネットワーク」ページに表示されるのは、ローカルセグメントで自分を告知したデバイスだけであり、ルーティングされたトンネルはその告知を一切運びません。だからこそ、サーバーには完全に到達できるのに、ユーザーの目の前のウィンドウは空のままになります。名前付きの UNC パスは探索にまったく依存せず、解決策は名前を解決させ、ポートに応答させることです。空のウィンドウは壊れた共有ではなく、層が違うという症状です。
探索と到達性は同じではない
Windows はブロードキャストドメイン向けに設計されたプロトコルで近くのマシンを見つけ、見つかったものを利便性のための一覧として表示します。その一覧の内容は SMB のファイルアクセスには一切必要ありません。サーバー名を知り TCP 445 に到達できるクライアントは、そのマシンが「ネットワーク」に現れるかどうかに関係なく共有を開きます。
二つの層は独立して失敗するので、「見えない」と「開けない」は別々にテストする価値があります。一覧を見ることは探索を語り、パスを開くことはサービスを語ります。
共有をマップする前にサーバーに名前を付ける
ファイルサーバーを、向こう側で持つアドレスとともに DNS に公開し、クライアントサイトをそのゾーンに応答できるリゾルバーに向けます。完全修飾名にすれば、ローカルのサフィックス検索リストへの依存を避けられます。短い名前がある拠点では機能し、別の拠点では失敗する通常の理由がこれです。
環境が Active Directory を使っている場合、名前解決は認証の一部でもあります。クライアントは Kerberos のためにドメインコントローラーに到達する必要があり、時計が大きくずれているとチケット交換が失敗します。これは SMB の到達性とは別の問題で、資格情報エラーのように見えます。パスワードを打ち直す前にドメインコントローラーをテストしてください。
| Layer | What it needs | Symptom when missing |
|---|---|---|
| Name resolution | A DNS answer for the server name | Path cannot be found, ping by IP still works |
| Transport | TCP 445 open in both directions | Connection times out or is refused |
| Authentication | A reachable domain controller and correct clock | Access is denied after the port connects |
| Authorization | Share permission and filesystem permission | The share opens but the folder is inaccessible |
両方向のルーティングとフィルタリング
サイト間トンネルには、ローカルのルートテーブルに遠隔プレフィックス、遠隔のテーブルにローカルプレフィックスが必要で、両側のファイアウォールが到着するトラフィックを許可しなければなりません。片方向の設定では、開くのに決して応答しない接続が生まれ、ユーザーは共有が遅いと表現します。まずトンネル自身のカウンターを確認します。パケットが出て何も戻らないなら、戻りルートか遠隔側のフィルターを調べます。
WireGuard では、ピアの許可 IP と OS のルートがその設計と一致している必要があります。トンネルはパケットを運ぶだけで、DNS レコードも共有のアクセス許可も提供しませんどちらの側でも。
ファイアウォールのルールは、実際に接続してくる送信元ネットワークに基づけて作り、例外を書き留めます。設計が経路上のどこかでアドレスを変換するなら、ルールは変換後の送信元を使う必要があり、元のクライアントアドレスはログに残りません。
認証してからドライブをマップする
エクスプローラーのウィンドウではなくコマンドで層を下っていきます。
Resolve-DnsName -Name files.corp.example -Type A
Test-NetConnection -ComputerName files.corp.example -Port 445
net use Z: \\files.corp.example\Projects /persistent:no
二つ目のコマンドが証明するのは TCP の経路であり、何かを読む権利ではありません。三つ目が認証と承認を実際に試す場所で、そこで失敗したらルーターではなく共有とファイルシステムのアクセス許可を見るべきです。
SMB 署名と既存の認証ポリシーはそのままにします。明示的なパスに SMB1 の再有効化や探索ブロードキャストのトンネル越えは不要で、TCP 445 はインターネット向けの転送ではなくプライベートな経路に留めるべきです。承認済みの名前に向けた管理されたショートカットかマップ済みドライブを配れば、空の「ネットワーク」ページは問題でなくなります。