Eine CiviCRM-Adresse für Büro- und VPN-Nutzer: Schritte zur Einrichtung

Ein Büro-Laptop sollte dasselbe CiviCRM-Lesezeichen am Schreibtisch und von zu Hause über das VPN öffnen. Das Design, das den Kontakt mit Nutzern übersteht, ist eine kanonische Adresse, etwa https://crm.example.org/, mit einem freigegebenen Netzwerkpfad von jedem Standort und einem Zertifikat, das für diesen Namen gültig ist. Das VPN ändert, wie ein entfernter Client den Server erreicht. Es sollte niemals die Identität der Anwendung ändern, denn in dem Moment, in dem es das tut, wird jeder erzeugte Link, jede Weiterleitung und jeder Integrations-Callback zu einem zweiten Problem, das zu lösen ist.

Wählen Sie die URL, bevor Sie die Route wählen

Schreiben Sie zuerst die beabsichtigte Adresse auf, einschließlich aller Pfadkomponenten, die das CMS benötigt, und behandeln Sie sie als festen Punkt. Alles andere in diesem Runbook ist ein Implementierungsdetail, das sich ändern kann, ohne sie anzutasten: welche DNS-Antwort jede Gruppe erhält, welche Firewall-Regel den Listener zulässt und ob der Datenverkehr über einen Tunnel oder einen lokalen Switch-Port ankommt.

Notieren Sie vier Werte gemeinsam im Zugangsplan, weil sie nur als Satz funktionieren. Die kanonische URL. Die Antwort, die jede Clientgruppe für diesen Namen erhalten soll. Die Route und die Zugriffsregel für diese Antwort. Der Hostname, den Webserver und Zertifikat bedienen sollen. Wenn später etwas kaputtgeht, ist das defekte Element eines dieser vier, und Sie wissen, welches Sie geändert haben.

Schritt 1: Sorgen Sie dafür, dass der Name für beide Gruppen korrekt aufgelöst wird

Beide Gruppen sollten eine private Antwort erhalten, die sie tatsächlich erreichen können, und es ist legitim, dass sich die Antworten unterscheiden, solange der Name es nicht tut. LAN-Clients lösen über den internen Resolver auf; VPN-Clients brauchen eine Resolver-Richtlinie, die ihnen dieselbe Zone liefert, statt die Abfrage an einen öffentlichen Resolver zu leaken und eine öffentliche Antwort zu erhalten, die sie nicht nutzen können.

Testen Sie den Namen aus jedem Kontext, statt ihn anzunehmen, und testen Sie den Pfad unabhängig vom DNS mit der resolve-Option von curl, die die Adresse für eine Anfrage festnagelt:

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

Wenn der erste Test eine Adresse zurückgibt, die der Client nicht erreichen kann, liegt das Problem beim Tunnel-Routing oder in der Split-Tunnel-Liste. Wenn der zweite Test eine Weiterleitung auf einen Hostnamen zurückgibt, den Sie nicht erwartet haben, halten Sie an und lesen Sie den Location-Header, denn das ist ein Anwendungsproblem, und keine Routenänderung wird es beheben.

Schritt 2: Bringen Sie Webserver, Zertifikat und CMS-Basis-URL in Einklang

Der Listener muss so konfiguriert sein, dass er den kanonischen Namen bedient, und das Zertifikat muss ihn abdecken. Das Surfen über die rohe Adresse ist kein Ausweg: Es erzeugt eine Namensabweichung, kann den Cookie-Bereich brechen und bringt Nutzern bei, Warnungen wegzuklicken, die Sie später einem Auditor erklären müssen.

Stellen Sie hinter einem Reverse-Proxy sicher, dass die Anwendung weiß, dass die Anfrage über HTTPS kam. Die meisten CMS-Plattformen erzeugen absolute Links aus dem erkannten Schema, und ein Proxy, der TLS beendet, ohne das ursprüngliche Schema weiterzugeben, erzeugt eine Seite voller http://-Ressourcen, die der Browser blockieren kann. Konfigurieren Sie den vertrauenswürdigen Proxy und die weitergeleiteten Header explizit, statt die Anwendung raten zu lassen.

Bringen Sie dann die Basis-URL von CMS und CiviCRM in Einklang. CiviCRM behält seine ermittelte Basis-URL und bietet einen unterstützten Weg, sie neu zu berechnen: die administrative Aktion Cleanup Caches and Update Paths, dokumentiert im Leitfaden zur Fehlerbehebung bei der CiviCRM-Installation. Führen Sie sie aus, nachdem kanonischer Name und CMS-Einstellung übereinstimmen, nicht vorher, sonst cachen Sie nur einen Wert, den Sie gleich ändern.

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

Schritt 3: Prüfen Sie die Adressen, die CiviCRM erzeugt

Die Startseite zu erreichen beweist sehr wenig. CiviCRM läuft innerhalb eines CMS, und die Seiten, auf die es ankommt, bauen ihre eigenen URLs: die Login-Weiterleitung, das Administrationsmenü, Erweiterungsressourcen, Links zu hochgeladenen Dateien und jeder externe Callback, den eine Integration registriert.

Laden Sie das Dashboard, öffnen Sie einen Kontaktdatensatz und sehen Sie im Seitenquelltext nach absoluten Links. Wenn sie auf einen Hostnamen zeigen, den nur eine Clientgruppe erreichen kann, ist die Basis-URL immer noch falsch, obwohl die Seite gerendert wurde. Wenn sie auf den richtigen Namen, aber das falsche Schema zeigen, ist die Proxy-Konfiguration zu korrigieren.

Wo die Adresse wirklich geändert werden muss, behandeln Sie das als Anwendungsmigration und nicht als DNS-Bearbeitung. Prüfen Sie Ressourcen-URLs, Caches, veröffentlichte Links und jede externe Integration, die die alte Adresse speichert, und aktualisieren Sie sie dann in einem Wartungsfenster, damit niemand ein halb migriertes Lesezeichen hält.

Ein Anforderungs-Hostname ist keine Vertrauensentscheidung

Wählen Sie keine privilegierte Basis-URL, nur weil ein Anforderungs-Header eine bestimmte Zeichenkette enthält. PHP dokumentiert Apache-Konfigurationen, in denen der Servername-Wert einen vom Client gelieferten Host widerspiegeln kann, und die Variable für die Serveradresse beschreibt den Server, nicht den Standort des Besuchers. Keines davon ist ein Zugriffskontrollmechanismus, und eines daraus zu bauen, ist der Weg, auf dem ein privater Dienst den falschen Inhalt an den falschen Host ausliefert.

Wenn mehrere Hostnamen wirklich erforderlich sind, konfigurieren Sie eine ausdrückliche Positivliste auf dem Webserver, im CMS und in der Anwendungsschicht und lassen Sie den Anforderungs-Hostnamen nur unter genehmigten Einträgen auswählen. Beliebige Eingaben sollten niemals die Quelle absoluter Links oder ein vertrauenswürdiges Weiterleitungsziel werden.

Schließen Sie mit demselben Lesezeichen in jedem genehmigten Kontext ab: ein Login, eine gewöhnliche interne Navigation und eine Ressourcenanfrage. Vergleichen Sie die Hostnamen in den Antworten, nicht nur, ob die Seite geladen wurde. Diese Prüfung mit drei Anfragen trennt ein Pfadproblem von einer Anwendung, die noch die falsche Adresse erzeugt, und dauert etwa eine Minute pro Clientgruppe.