Share via

代替アクセス マッピングを理解する

  • Article

こんにちは SharePoint サポートの森　健吾 (kenmori) です。

今回の投稿では、 SharePoint  Server オンプレミス版の代替アクセス マッピングによるアドレス調整の動作をご説明し、この設定の意味を理解するためのご説明をいたします。

代替アクセス マッピングは、複数サーバーによるファーム構成の Web サーバー、様々なネットワーク環境への展開の想定、開発者向けの API など、様々な状況を考慮した上で作成されております。
代替アクセス マッピングは、SharePoint が要求を受信した際や、指定されたアドレスをどう扱うかについての機能です。DNS などサーバーに到達するまでのルーティング設定とは異なりますので、ネットワーク側の構築は別途行う必要があります。

すでに SharePoint に本機能が組み込まれてから長い期間が経過しますが、理解し難しいというコメントをよく寄せられます。本投稿では代替アクセス マッピングを設定することで、どのような動作が行われるかという観点でまとめ、実際に構成する際やトラブルシューティングなどを行うことが必要となった際に、シンプルに考えられるようにまとめております。

なお、代替アクセス マッピングは SharePoint Server 2013 から導入されたホスト名付きサイト コレクションには対応していません。本投稿ではホスト名付きサイト コレクションには言及しません。

1 : 画面構成について

代替アクセス マッピングの設定画面にアクセスするためには、サーバーの全体管理にアクセスし、"システム設定" 配下にある [代替アクセス マッピングの構成] をクリックします。

少し古いですが、関連記事として下記があります。具体的な設定手順等について記載されておりますが、画面構成は 2007 の時から大きく変更されていません。

タイトル : 代替アクセスマッピングの設定方法
アドレス : https://blogs.technet.com/b/sharepoint_support/archive/2009/11/25/3296232.aspx

2 : キーワード

代替アクセス マッピングを正確に理解する上で、最初に意識しておきたいキーワードを記載いたします。

1. 領域
2. パブリック URL
3. 内部 URL

1.     領域
Web アプリケーションは、同じコンテンツに対し、ネットワーク構成などに合わせて複数のIIS Web サイトを公開先とすることができます。これらを領域と呼び、各ネットワーク領域 (イントラネット、インターネット等) に合わせて異なるアドレス (NetBIOS 名、FQDN) や認証設定 (Windows 認証, フォーム認証, フェデレーション認証) を持つことができます。

 2. パブリック URL

パブリックURL は、ブラウザーが SharePoint サーバーに要求する URL です。リバース プロキシなどの中継機器が存在し、内外でアドレスを変換する場合は、外部ネットワークでブラウザーから中継機器に対して要求するアドレスです。

[パブリック URL の編集] をクリックすることで編集画面に遷移します。領域ごとに 1 つのパブリック URL のみ保持できます。

3. 内部 URL

内部 URL は、SharePoint サーバーが実際に受信する URL です。リバース プロキシなどの中継機器が存在し、内外でアドレスを変換する場合は、内部ネットワークにおいて中継機器から SharePoint サーバーに要求されるアドレスです。

[内部 URL の追加] をクリックすることで編集画面に遷移できます。領域ごとに 1 つだけ登録されるパブリック URL に対し、複数の内部 URL を追加することができます。ただし、内部 URL は必ずユニークである必要があり異なる領域間で同じものを登録することはできません。

補足 : インターネット領域における内部 URL とパブリック URL 設定例

上記のキーワード説明を踏まえ、インターネット領域において実際に内部 URL とパブリック URL を設定します。

3 : 代替アクセスマッピングの主な作用

代替アクセス マッピングの設定が適切かどうかを判断するためには、代替アクセス マッピングにおける以下の 3 つの目的を把握しておくことで判断が可能となります。

目次

1. SharePoint のアドレスを管理することで、URL からサイト リソースを特定できるようにします。
2. ユーザーのアクセス元のネットワーク領域を判断し、適切なリソース アクセスを実施します。
3. リバース プロキシなどを想定し、内部 URL からパブリック URL にアドレスを変換します。

詳細

1. SharePoint のアドレスを管理することで、URL からサイト リソースを特定できるようにします。

SharePoint では、ネットワークを経由しなくても URL とリソースを紐づける必要があります。SharePoint には、開発者向けのサーバー サイド オブジェクト モデルがあり、SharePoint 製品自体もこのオブジェクト モデルを使用して開発されております。

このオブジェクト モデルは、Web を経由したライブラリではありません。コンソールアプリケーションでも使用でき、SharePoint コンテンツにアクセスする際には、Web アプリケーションやサイトなどの URL を使用して各オブジェクトをインスタンス化します。つまり、SharePoint では Web アクセスを経由してルーティングされることなく URL 自体よりリソースを特定することができる必要があります。

SharePoint は各 Web アプリケーションの URL をリスト化して管理しており、本来 SharePoint にアクセスする際にはいずれかの領域に登録されたパブリック URL または内部 URL を使用することが前提となります。ただし、リソースが特定できない場合、指定された URL をもとに内部的に Web サービス アクセスを実施して、適切な代替アクセス マッピングへの登録 URL に修正する動作などもあり、実際には動いてしまう場面が多々あります。結果的に動作したとしても、この変換処理を動作させることは効率的ではありませんので、代替アクセスマッピングに登録した URL を使用する必要があります。

 
2. ユーザーのアクセス元のネットワーク領域を判断し、適切なリソース アクセスを実施します。

SharePoint には、ユーザーが接続してくる領域を判断し、同じ領域へのアクセスを保つような動作が実装されております。

例えば、https://sharepoint.contoso.com でアクセスを受信した場合には、ブラウザーが別の領域である https://spserver1:10000 経由で CSS や JavaScript 画像やページなどのリソースへアクセスしないように、現在の領域のパブリック URL でページ コンテンツを返します。

SharePoint では、ユーザーがリッチテキスト エディターなどを使用し、ユーザーが自由に入力でき、コンテンツにリンクすることや、画像を貼り付けることができます。ユーザーが自由に入力できるが故に、これらのコンテンツに埋め込まれたリンクはユーザーが接続しているネットワーク領域に応じて変化しなければ、たちまちリンク切れを起こしてしまいます。

 なお、InfoPath Forms Services などで、SharePoint の Web サービスに対してデータ接続する際においても、HTTP 要求を受信した領域のアドレスに変換した上で Web サービスに対しデータ接続する動作となります。

このような制御は、様々な機能の各所で確認できるものとなります。

 

3. リバース プロキシなどを想定し、内部 URL からパブリック URL にアドレスを変換します。

上記 2. の説明だけでは、単純に要求された URL にそのまま変換するだけで良いのではないかと考えがちですが、それだけでは、不十分なシナリオがあります。

リバース プロキシなどの機器を介してアクセスを受けるインターネット公開の場合を例にご説明します。

下記の例では、SharePoint サーバーは、ブラウザーからはパブリック URL (https://sharepoint.contoso.com) で要求されるものの、ネットワーク機器からは https://sharepoint というアドレスに変換されて要求を受けます。

もし、要求されたアドレス (https://sharepoint) をそのままブラウザー側に返してしまうと、リダイレクト先やハイパーリンク先などを https://sharepoint で送り返してしまいます。この https://sharepoint というアドレスは、社内ネットワークのみで使用できるアドレスですので、インターネットから接続しているブラウザーからはその内部 URL (https://sharepoint) には到達できないため、404 エラー (Not Found) となってしまいます。

SharePoint には、製品としてこの問題を回避するために、HTTP 応答を返す際に内部 URL をパブリック URL に変換する動作があります。上図の通り https://sharepoint として要求を受けても、コンテンツ上の URL としてはパブリック URL である https://sharepoint.contoso.com として返します。これこそが、内部 URL とパブリック URL の存在意義となります。

内部 URL とパブリック URL は n:1 の関係となります。ただし、これは単なる主従関係ではありません。内部 URL 自身は複数の領域間でも必ず一意である必要があります。同じ内部 URL が複数の領域に登録されて一意性が崩れた場合、SharePoint ServerはHTTP 要求された内部 URL をどの領域のパブリック URL として返していいかが判断できなくなります。

また、パブリック URL = 内部 URL の組み合わせは必ず保持しておく必要があります。パブリック URL がどこかの領域の内部 URL で使用されるという状況は運用の観点でもあり得ないため、パブリック URL を登録するとパブリック URL と同じ内部 URL がセットで登録される動作となります。

注意点として領域 (例. インターネット領域) で内部 URL として使用されているアドレスを別の領域 (例. イントラネット領域) のパブリック URL に指定すると、内部 URL の一意性を保つため、領域 (例. インターネット領域) に前から登録されていた内部 URL のエントリーは削除されます。誤って本作業を実施してしまうと、ネットワーク機器経由で SharePoint サーバーにアクセスできなくなります。

このようなアドレス変換を実施するネットワーク機器を介した環境においては、代替アクセス マッピングの構成は不可欠となります。後で編集する場合においては、十分ご注意ください。

今回の投稿は以上となります。