Один URL CiviCRM для офисных и VPN-пользователей: шаги настройки

Офисный ноутбук должен открывать одну и ту же закладку CiviCRM за рабочим столом и снова из дома через VPN. Схема, которая выдерживает контакт с пользователями, — это один канонический адрес, скажем https://crm.example.org/, с утверждённым сетевым путём из каждого места и сертификатом, действительным для этого имени. VPN меняет то, как удалённый клиент попадает на сервер. Он никогда не должен менять идентичность приложения, потому что в тот момент, когда это происходит, каждая сгенерированная ссылка, перенаправление и обратный вызов интеграции становятся второй проблемой, которую нужно решить.

Выберите URL до того, как выберете маршрут

Сначала запишите предполагаемый адрес, включая любой компонент пути, необходимый CMS, и рассматривайте его как неподвижную точку. Всё остальное в этом руководстве — детали реализации, которые можно менять, не трогая его: какой ответ DNS получает каждая группа, какое правило брандмауэра разрешает слушателю и приходит ли трафик через туннель или через локальный порт коммутатора.

Запишите четыре значения вместе в плане доступа, потому что они работают только как набор. Канонический URL. Ответ, который должна получать каждая группа клиентов для этого имени. Маршрут и правило доступа для этого ответа. Имя хоста, которое настроены обслуживать веб-сервер и сертификат. Когда позже что-то сломается, сломанный элемент — один из этих четырёх, и вы будете знать, какой именно вы изменили.

Шаг 1: добейтесь, чтобы имя правильно разрешалось для обеих групп

Обе группы должны получать приватный ответ, до которого они действительно могут добраться, и вполне допустимо, чтобы ответы различались, если само имя не различается. Клиенты LAN разрешают через внутренний резолвер; клиентам VPN нужна политика резолвера, которая выдаёт им ту же зону, а не утекает запрос в публичный резолвер и не возвращает публичный ответ, которым они не могут воспользоваться.

Проверяйте имя из каждого контекста, а не предполагайте, и проверяйте путь независимо от DNS с помощью опции resolve у curl, которая закрепляет адрес для одного запроса:

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

Если первая проверка возвращает адрес, до которого клиент не может добраться, проблема в маршрутизации туннеля или в списке split-tunnel. Если вторая проверка возвращает перенаправление на имя хоста, которого вы не ожидали, остановитесь и прочитайте заголовок Location, потому что это проблема приложения, и никакое изменение маршрута её не исправит.

Шаг 2: согласуйте веб-сервер, сертификат и базовый URL CMS

Слушатель должен быть настроен на обслуживание канонического имени, а сертификат должен его покрывать. Просмотр по необработанному адресу — не обходной путь: он даёт несовпадение имени, может сломать область действия cookie и учит пользователей проходить через предупреждения, которые позже придётся объяснять аудитору.

За обратным прокси убедитесь, что приложение знает, что запрос пришёл по HTTPS. Большинство CMS-платформ генерируют абсолютные ссылки из обнаруженной схемы, а прокси, который завершает TLS, не передавая исходную схему, создаёт страницу, полную http:// ресурсов, которые браузер может заблокировать. Настройте доверенный прокси и передаваемые заголовки явно, а не позволяйте приложению угадывать.

Затем согласуйте базовый URL CMS и CiviCRM. CiviCRM сохраняет определённый базовый URL и предлагает поддерживаемый способ его пересчитать: административное действие «Очистить кэши и обновить пути», описанное в руководстве по устранению неполадок установки CiviCRM. Запускайте его после того, как каноническое имя и настройка CMS совпадут, а не до, иначе вы просто закэшируете значение, которое собираетесь изменить.

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

Шаг 3: проверьте адреса, которые генерирует CiviCRM

Добраться до главной страницы доказывает очень мало. CiviCRM работает внутри CMS, и важны те страницы, которые строят собственные URL: перенаправление при входе, меню администрирования, ресурсы расширений, ссылки на загруженные файлы и любой внешний обратный вызов, зарегистрированный интеграцией.

Загрузите панель, откройте запись контакта и посмотрите исходный код страницы на предмет абсолютных ссылок. Если они указывают на имя хоста, до которого может добраться только одна группа клиентов, базовый URL всё равно неверен, хотя страница и отрисовалась. Если они указывают на правильное имя, но неправильную схему, исправлять нужно конфигурацию прокси.

Там, где адрес действительно должен измениться, рассматривайте это как миграцию приложения, а не как правку DNS. Проверьте URL ресурсов, кэши, опубликованные ссылки и каждую внешнюю интеграцию, которая хранит старый адрес, а затем обновите их в одном окне, чтобы никто не остался с полумигрированной закладкой.

Имя хоста в запросе — не решение о доверии

Не выбирайте привилегированный базовый URL только потому, что в заголовке запроса есть определённая строка. PHP документирует конфигурации Apache, в которых значение имени сервера может отражать хост, предоставленный клиентом, а переменная адреса сервера описывает сервер, а не местоположение посетителя. Ни то, ни другое не является механизмом контроля доступа, и построение такого механизма из них — это путь, которым частный сервис начинает отдавать неверное содержимое неверному хосту.

Если действительно требуется несколько имён хостов, настройте явный список разрешений на веб-сервере, в CMS и на уровне приложения и позвольте имени хоста из запроса выбирать только среди одобренных записей. Произвольный ввод никогда не должен становиться источником абсолютных ссылок или доверенным местом перенаправления.

Завершите одной и той же закладкой в каждом одобренном контексте: вход, обычная внутренняя навигация и один запрос ресурса. Сравнивайте имена хостов в ответах, а не только то, загрузилась ли страница. Эта проверка из трёх запросов отделяет проблему пути от приложения, которое всё ещё генерирует неверный адрес, и занимает около минуты на группу клиентов.