Один 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 і на рівні застосунку та дозвольте імені хоста із запиту вибирати лише серед схвалених записів. Довільний ввід ніколи не повинен ставати джерелом абсолютних посилань або довіреним місцем переспрямування.

Завершіть тією самою закладкою в кожному схваленому контексті: вхід, звичайна внутрішня навігація і один запит ресурсу. Порівнюйте імена хостів у відповідях, а не лише те, чи завантажилася сторінка. Ця перевірка з трьох запитів відокремлює проблему шляху від застосунку, який усе ще генерує неправильну адресу, і займає близько хвилини на групу клієнтів.