VPN でネットワーク共有が表示されない？検出が止まる

パスを入力すれば共有は開くのに、ネットワークブラウザには何も表示されない。この組み合わせはトンネル越しではよくあり、通常は故障ではない。検出はローカルセグメントに問い合わせ、到達性は一台のホストに問い合わせる。ルーティングされたトンネルが運ぶのは後者であり、前者ではない。

検出と到達性は別物である

参照一覧は、ローカルセグメントにサービスを告知し、その告知を待ち受けるプロトコルによって作られる。共有を名前で開くことは、一台のホストへの直接接続である。前者にはブロードキャストまたはマルチキャストのドメインが必要で、後者にはルートとポートが必要だ。

トンネル越しでは、後者が完璧に機能していても、前者が空のウィンドウを返すことがある。空のウィンドウを故障と見なすと、仕事を果たしている壊れていないトンネルを探しに行くことになる。

参照一覧が空のままなのはなぜか

Windows は Computer Browser サービスを廃止し、SMB バージョン 1 を既定で無効にしたため、古い Network Neighborhood の背後にあった仕組みが取り除かれた。WS-Discovery、SSDP、マルチキャスト DNS といった代替は、ローカルリンクにしか存在しないブロードキャストまたはマルチキャストのグループを扱う。ポイントツーポイントのトンネルにはそのようなリンクがなく、ルーターは既定でそれらのグループを転送しない。すべてのホストに到達できても、一覧は空のままでありうる。

クライアントによっては独自の検出ヘルパーを追加する。そのヘルパーが動くとき、それはクライアントの機能であり、トンネルの性質ではない。

明示的な名前を使い、そのうえでアクセスを確認する

UNC パス、割り当て済みドライブ、SMB アドレスへの Finder 接続は、名前が解決しポートが開いていればトンネル越しに機能する。解決は DNS、VPN が提供する検索サフィックス、または中央管理の hosts エントリから得られる。ドメインでは、ディレクトリ照会でコンピューターオブジェクトを一覧でき、その一覧が通常、ルーティングされたネットワークでの参照ビューに最も近い代替となる。既知のプレフィックスのポートスキャンは、自分が運用するネットワーク、または明示的に許可されたネットワークでのみ許容される。

応答するホストは、共有が開くことを約束しない。NAS は自サブネットに限定した許可リストを持ち、VPN プールのアドレスを拒否することがある。ファイルサーバーのファイアウォール規則がローカルサブネットだけを指定していることもある。共有に指定したアカウントが、そのサーバーに存在しないローカルアカウントであることもあり、VPN 経由で接続してもそれは作られない。

一部の企業向けクライアントは、トンネルが有効な間、ローカルおよび仮想マシンの通信を意図的に遮断する。その欠けたアクセスはポリシーであり、修正は管理者に属し、クライアントのルートテーブルではない。

繰り返す価値のある診断順序

層を順にたどり、アドレスに到達し、名前を解決し、ポート 445 を開き、認証し、それから共有のアクセス許可を読む。答えはそれぞれ別であり、先に飛ばすと自信のある誤った結論に至る。すべてが通ってから初めて、検出を調べる価値がある。

nslookup fileserver.example.com
nc -vz fileserver.example.com 445
smbclient -L //fileserver.example.com -U EXAMPLE/jdoe

サーバー名、共有パス、解決されたアドレス、機能したアカウントを書き残す。後でサービス再起動後に参照一覧が埋まったとしても、それは検出の気まぐれであり、以前のルートが誤っていた証拠ではない。その記録があれば、次の人は空のウィンドウを飛ばせる。