Eén CiviCRM-URL voor kantoor- en VPN-gebruikers: installatiestappen

Een kantoorlaptop moet op het bureau en thuis via de VPN dezelfde CiviCRM-bladwijzer openen. Het ontwerp dat contact met gebruikers overleeft, is één canoniek adres, zeg maar https://crm.example.org/, met een goedgekeurd netwerkpad vanaf elke locatie, en een certificaat dat geldig is voor die naam. De VPN verandert hoe een externe client de server bereikt. Hij mag nooit de identiteit van de applicatie veranderen, want op het moment dat hij dat doet, wordt elke gegenereerde link, redirect en integratie-callback een tweede probleem om op te lossen.

Kies de URL voordat je de route kiest

Schrijf eerst het beoogde adres op, inclusief elk padonderdeel dat de CMS nodig heeft, en behandel het als het vaste punt. Al het andere in dit draaiboek is een implementatiedetail dat kan veranderen zonder dat adres aan te raken: welk DNS-antwoord elke groep krijgt, welke firewallregel de listener toestaat, en of het verkeer via een tunnel of via een lokale switchpoort binnenkomt.

Leg vier waarden samen vast in het toegangsplan, want ze werken alleen als een set. De canonieke URL. Het antwoord dat elke clientgroep voor die naam hoort te krijgen. De route en toegangsregel voor dat antwoord. De hostnaam die de webserver en het certificaat moeten bedienen. Als er later iets stukgaat, is het kapotte element een van die vier, en weet je welke je hebt gewijzigd.

Stap 1: zorg dat de naam voor beide groepen correct resolveert

Beide groepen horen een privéantwoord te krijgen dat ze echt kunnen bereiken, en het is legitiem dat de antwoorden verschillen zolang de naam niet verschilt. LAN-clients resolven via de interne resolver; VPN-clients hebben een resolverbeleid nodig dat hun dezelfde zone geeft in plaats van de query naar een publieke resolver te lekken en een publiek antwoord te krijgen dat ze niet kunnen gebruiken.

Test de naam vanuit elke context in plaats van aan te nemen, en test het pad onafhankelijk van DNS met de resolve-optie van curl, die het adres voor één verzoek vastzet:

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

Als de eerste test een adres oplevert dat de client niet kan bereiken, is de tunnelroutering of de split-tunnel-lijst het probleem. Als de tweede test een redirect naar een hostnaam oplevert die je niet verwachtte, stop dan en lees de Location-header, want dat is een applicatieprobleem en geen routewijziging lost dat op.

Stap 2: lijn de webserver, het certificaat en de CMS-basis-URL op elkaar uit

De listener moet geconfigureerd zijn om de canonieke naam te bedienen, en het certificaat moet die dekken. Browsen via het ruwe adres is geen workaround: het levert een naamverschil op, kan het cookiebereik breken, en leert gebruikers door waarschuwingen heen te klikken die je later aan een auditor moet uitleggen.

Zorg er achter een reverse proxy voor dat de applicatie weet dat het verzoek via HTTPS binnenkwam. De meeste CMS-platforms genereren absolute links op basis van het gedetecteerde schema, en een proxy die TLS beëindigt zonder het oorspronkelijke schema door te sturen, levert een pagina vol http:// bronnen op die een browser kan blokkeren. Configureer de vertrouwde proxy en doorgestuurde headers expliciet in plaats van de applicatie te laten gissen.

Lijn daarna de CMS- en CiviCRM-basis-URL op elkaar uit. CiviCRM houdt zijn bepaalde basis-URL vast en biedt een ondersteunde manier om die opnieuw te berekenen: de administratieve actie Caches opschonen en paden bijwerken, gedocumenteerd in de CiviCRM-installatieprobleemoplossingsgids. Voer die uit nadat de canonieke naam en de CMS-instelling overeenkomen, niet ervoor, anders cache je gewoon een waarde die je op het punt staat te wijzigen.

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

Stap 3: controleer de adressen die CiviCRM genereert

De voorpagina bereiken bewijst heel weinig. CiviCRM draait binnen een CMS, en de pagina's die ertoe doen, zijn de pagina's die hun eigen URL's opbouwen: de login-redirect, het administratiemenu, extensiebronnen, links naar geüploade bestanden en elke externe callback die door een integratie is geregistreerd.

Laad het dashboard, open een contactrecord en bekijk de paginabron op absolute links. Wijzen ze naar een hostnaam die slechts één clientgroep kan bereiken, dan is de basis-URL nog steeds fout ook al werd de pagina weergegeven. Wijzen ze naar de juiste naam maar het verkeerde schema, dan is de proxyconfiguratie het ding dat je moet repareren.

Waar het adres echt moet veranderen, behandel dat als een applicatiemigratie en niet als een DNS-wijziging. Loop de bron-URL's, caches, gepubliceerde links en elke externe integratie die het oude adres opslaat na, en werk ze dan in één venster bij zodat niemand met een half gemigreerde bladwijzer blijft zitten.

Een hostnaam in een verzoek is geen vertrouwensbeslissing

Kies geen bevoorrechte basis-URL omdat een verzoekheader een bepaalde string bevat. PHP documenteert Apache-configuraties waarin de servernaamwaarde een door de client aangeleverde host kan weerspiegelen, en de serveradresvariabele beschrijft de server, niet de locatie van de bezoeker. Geen van beide is een toegangscontrolemechanisme, en daar een van bouwen is hoe een privédienst uiteindelijk de verkeerde inhoud aan de verkeerde host serveert.

Als meerdere hostnamen echt nodig zijn, configureer dan een expliciete allowlist op de webserver, in de CMS en in de applicatielaag, en laat de hostnaam van het verzoek alleen kiezen uit goedgekeurde vermeldingen. Willekeurige invoer mag nooit de bron worden van absolute links of een vertrouwde redirectbestemming.

Eindig met dezelfde bladwijzer in elke goedgekeurde context: een login, een gewone interne navigatie en één bronverzoek. Vergelijk de hostnamen in de reacties, niet alleen of de pagina laadde. Die controle met drie verzoeken scheidt een padprobleem van een applicatie die nog steeds het verkeerde adres genereert, en kost ongeveer een minuut per clientgroep.