SharePoint のリンクが公開 URL のせいで VPN 経由で切れる
VPN 経由で読み込んだ SharePoint ページでも、クライアントが解決できない名前でドキュメント リンクを返すことがあります。DNS、ルート、TLS、公開 URL を確認してください。
SharePoint ページが VPN 経由で開き、最初のドキュメント リンクがアドレス バーに一度も出てこなかった名前で失敗します。そのずれが問題のすべてです：ページはある URL から来て、サービスは次の要求を別の URL から組み立てています。公開 URL はサーバー側の決定なので、クライアント側で直すのは間違った端です。DNS やルートに触れる前に、サービスがどの名前を返すかを確認してください。
最初のページと次の要求では別の名前が使われる
アドレスでサーバーに到達したユーザーには、動作するホーム ページが表示されます。そのページのドキュメント リンクは、サービスが公開していると認識している URL から生成され、ブラウザーが入力した URL からではありません。両者が違えば、次のクリックはクライアントが一度も解決していない名前へ向かいます。
アドレスを一度入力しても生成済みのリンクすべては直らず、アドレスへのブックマークはドキュメントを開くまで問題を隠します。
この失敗はトンネルを使った後にだけ現れるため、VPN の問題と誤読されがちです。実際にはトンネルは役目を果たしており、要求を、有効な経路も一致する証明書もない名前へ運んでいるだけです。どちらかを変える前に二つの問いを分けてください。一つはパケットがどこへ行くか、もう一つはサービスがどの名前を公開することを選んだかです。
四つの制御、一つの名前
公開された名前はすべて四つの独立した制御を通る必要があります。DNS が実際のクライアントに対して解決し、ルーティングとアクセス ポリシーが経路を許可し、TLS がその名前を検証し、サービスがそれを公開するよう構成されていなければなりません。
一つの制御を変えても他の制御は行われません。証明書の警告を受け入れることは名前解決の修復ではありません。
下の表がチェックリストの順序です。後からの修正が前の欠落を補えないため、最初に失敗する行で止めてください。
| Control | Question | Where to look |
|---|---|---|
| DNS | Can the client resolve the published name? | Client resolver and split-DNS policy |
| Route and policy | Does the permitted path exist to the service? | VPN routes and firewall rules |
| TLS identity | Does the certificate match the name in use? | Certificate subject names and trust store |
| Publishing config | Which URL does the service return? | Web application settings and site model |
変更する前に公開モデルを読む
SharePoint Server の展開はさまざまです。クラシック Web アプリケーションは代替アクセス マッピングを使え、そこでは内部 URL がサーバーが受け取るもので、パブリック URL がリンクの組み立てに使うものです。ホスト名ベースのサイト コレクションは別の方式を取り、Microsoft のガイダンスによれば AAM を使えません。
Microsoft の計画ガイダンスも AAM の機能を非推奨と示し、新しい計画にはホスト名ベースのサイト コレクションを推奨しています。そのため展開モデルは所有者への問いであり、あなたが当て推量で直す既定値ではありません。
マッピングの変更を提案する前に、どのモデルが使われているかを確定してください。ホスト名ベースの展開に AAM エントリを追加しても何も起きず、クラシックな展開に一つ追加すると返されるすべてのリンクが一度に変わります。どちらも影響範囲の広い構成変更なので、段階的に用意し、ロールバックを保持してください。これはレガシーなマッピングを現代の環境に持ち込むことを勧めるものではありません。
ホーム ページではなく、失敗した操作を追う
失敗した要求が実際に使った宛先、クライアント アプリケーション、時刻、エラーを記録します。ブラウザーとデスクトップ アプリケーションは同じドキュメントへ別のプロキシ、VPN、認証の経路を取り得ます。
ブラウザーが成功して Office クライアントが失敗することがあり、その違いはどのコンテキストが名前を解決するかの手がかりです。
URL とネットワークの受け渡しがどちらも機能し、それでもサービスが操作を拒否するなら、残る問題はアプリケーション層です。ドキュメントのアクセス許可とチェックアウトの状態はサービスの所有者に属し、VPN ルートは接続性を提供するのであって許可を与えるのではありません。
受け渡しを端から端まで確認する
失敗するクライアントで順に確認します：公開された名前を解決し、その名前でページを要求し、ページのソースからドキュメントの URL を要求します。各手順が一つの制御を切り分けます。
三つのコマンドが解決、TLS、ドキュメントの経路を網羅します：
nslookup portal.hq.example
curl -sSI https://portal.hq.example/ | head -5
curl -sS -o /dev/null -w "%{http_code}" https://portal.hq.example/sites/team/Doc.aspx解決がトンネル経由だけで失敗するなら、split-DNS ポリシーが疑わしい相手です。TLS が失敗するなら、クリックして進むのではなく証明書の名前を公開名と比較してください。両方が成功してもドキュメントが失敗するなら、エラーはもはや URL の話ではありません。