オフィスと VPN ユーザー向けの単一 CiviCRM URL：設定手順

オフィスのノート PC は、自席でも自宅から VPN 経由でも同じ CiviCRM ブックマークを開けるべきです。ユーザーとの実際の運用に耐える設計は、一つの正規アドレス、たとえば https://crm.example.org/ を定め、各拠点からの承認済みネットワーク経路と、その名前に対応する有効な証明書を用意することです。VPN はリモートクライアントがサーバーに到達する方法を変えます。しかし、変えた瞬間に生成されるすべてのリンク、リダイレクト、連携のコールバックが解決すべき二つ目の問題になるため、アプリケーションの同一性を変えてはいけません。

経路を選ぶ前に URL を選ぶ

まず意図するアドレスを、CMS が必要とするパス要素も含めて書き出し、固定点として扱います。この手順書の他のすべては、どのグループがどの DNS 応答を受け取るか、どのファイアウォール規則がリスナーを許可するか、そして トラフィックがトンネル経由かローカルスイッチポート経由か という、それを触らずに変更できる実装の詳細です。

四つの値をまとめてアクセス計画に記録するのは、これらが一つの組としてしか機能しないからです。正規 URL。各クライアントグループがその名前に対して受け取るべき応答。その応答に対する経路とアクセス規則。Web サーバーと証明書が提供するよう設定されているホスト名。後で何かが壊れたとき、壊れた要素はこの四つのうちの一つであり、どれを変更したかがわかります。

ステップ 1：両方のグループで名前が正しく解決されるようにする

両方のグループが実際に到達できるプライベートな応答を受け取るべきであり、名前が異ならなければ応答が異なっても問題ありません。LAN クライアントは内部リゾルバーで解決しますが、VPN クライアントには、クエリをパブリックリゾルバーに漏らして使えないパブリック応答を得るのではなく、同じゾーンを渡すリゾルバーポリシーが必要です。

想定せずに各コンテキストから名前をテストし、DNS とは独立に、一回の要求に対してアドレスを固定する curl の resolve オプションで経路をテストします:

dig +short crm.example.org
curl -sSI --resolve crm.example.org:443:10.10.5.20 https://crm.example.org/ | head -5

最初のテストがクライアントから到達できないアドレスを返す場合、問題はトンネルのルーティングか分割トンネルの一覧にあります。二番目のテストが想定外のホスト名へのリダイレクトを返す場合、それはアプリケーションの問題であり経路の変更では直らないため、いったん止めて Location ヘッダーを読んでください。

ステップ 2：Web サーバー、証明書、CMS のベース URL を揃える

リスナーは正規の名前を提供するよう設定し、証明書はその名前をカバーする必要があります。生のアドレスで閲覧するのは、名前の不一致を生み、Cookie のスコープを壊すことがあり、後で監査人に説明しなければならない警告をユーザーにクリックさせることになるため、回避策になりません。

リバースプロキシの背後では、要求が HTTPS で届いたことをアプリケーションが認識できるようにします。ほとんどの CMS プラットフォームは検出したスキームから絶対リンクを生成するため、元のスキームを転送せずに TLS を終端するプロキシは、ブラウザーがブロックする可能性のある http:// リソースだらけのページを生成します。アプリケーションに推測させるのではなく、信頼するプロキシと転送ヘッダーを明示的に設定します。

次に CMS と CiviCRM のベース URL を揃えます。CiviCRM は決定されたベース URL を保持し、それを再計算するサポートされた方法として、管理操作の Cleanup Caches and Update Paths を提供しており、これは CiviCRM インストールのトラブルシューティングガイド に記載されています。正規の名前と CMS 設定が一致してから実行するのが正しく、それより前だと、これから変更する値をキャッシュするだけになります。

cv flush
# then Administer > System Settings > Cleanup Caches and Update Paths

ステップ 3：CiviCRM が生成するアドレスを確認する

フロントページに到達できることだけでは、ほとんど何も証明できません。CiviCRM は CMS の中で動作し、重要なのは、ログインのリダイレクト、管理メニュー、拡張機能のリソース、アップロードしたファイルへのリンク、連携が登録する外部コールバックなど、自分で URL を組み立てるページです。

ダッシュボードを読み込み、連絡先レコードを開き、絶対リンクがないかページのソースを確認します。一つのクライアントグループしか到達できないホスト名を指しているなら、ページが表示されていてもベース URL はまだ間違っています。正しい名前だが誤ったスキームを指しているなら、修正すべきはプロキシの設定です。

アドレスを本当に変更しなければならない場合は、DNS の編集ではなくアプリケーションの移行として扱います。リソース URL、キャッシュ、公開済みのリンク、古いアドレスを保存しているすべての外部連携を確認し、一つの作業枠でまとめて更新して、中途半端に移行されたブックマークが残らないようにします。

要求のホスト名は信頼の判断ではない

要求ヘッダーに特定の文字列が含まれているからといって、特権的なベース URL を選んではいけません。PHP は、サーバー名の値がクライアント提供のホストを反映しうる Apache 設定を文書化しており、サーバーアドレス変数はサーバーを表すもので、訪問者の位置ではありません。どちらもアクセス制御の仕組みではなく、それらから一つを作ることが、プライベートなサービスが誤ったホストに誤ったコンテンツを提供してしまう道です。

複数のホスト名が本当に必要な場合は、Web サーバー、CMS、アプリケーション層で明示的な許可リストを設定し、要求のホスト名が承認済みの項目だけから選ぶようにします。任意の入力が絶対リンクの生成元や信頼できるリダイレクト先になってはいけません。

承認済みの各コンテキストで、ログイン、通常の内部ナビゲーション、そして一つのリソース要求という同じブックマークを使って終えます。応答内のホスト名を比較し、ページが読み込まれたかどうかだけを見ないようにします。この三要求の確認で、経路の問題と、まだ誤ったアドレスを生成しているアプリケーションを切り分けられ、クライアントグループあたり約一分で済みます。