Адзін адрас 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

Калі першы тэст вяртае адрас, да якога кліент не можа дасягнуць, праблема ў маршрутызацыі тунелю або ў спісе раздзеленага тунелю. Калі другі тэст вяртае перанакіраванне на імя хоста, якога вы не чакалі, спыніцеся і прачытайце загаловак Location, бо гэта праблема праграмы, і ніякае змяненне маршруту яе не выправіць.

Крок 2: узгадніце вэб-сервер, сертыфікат і базавы URL CMS

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

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

Затым узгадніце базавы URL CMS і CiviCRM. 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, у якіх значэнне імені сервера можа адлюстроўваць хост, прадастаўлены кліентам, а зменная адрасу сервера апісвае сервер, а не месцазнаходжанне наведвальніка. Ні адно з гэтага не з'яўляецца механізмам кантролю доступу, і пабудова такога з іх — гэта шлях, якім прыватная служба пачынае аддаваць няправільны кантэнт няправільнаму хосту.

Калі некалькі імёнаў хостаў сапраўды неабходны, наладзьце яўны белы спіс на вэб-серверы, у CMS і на ўзроўні праграмы, і дазвольце імені хоста запыту выбіраць толькі сярод зацверджаных запісаў. Адвольны ўвод ніколі не павінен станавіцца крыніцай абсалютных спасылак або давераным пунктам прызначэння перанакіравання.

Завяршыце адной і той жа закладкай у кожным зацверджаным кантэксце: уваход, звычайная ўнутраная навігацыя і адзін запыт рэсурсу. Параўнайце імёны хостаў у адказах, а не толькі тое, ці загрузілася старонка. Гэтая праверка трох запытаў аддзяляе праблему шляху ад праграмы, якая ўсё яшчэ генераваць няправільны адрас, і займае каля хвіліны на кожную групу кліентаў.