Una única URL de CiviCRM para usuarios de oficina y VPN: pasos de configuración

Un portátil de oficina debería abrir el mismo marcador de CiviCRM en su escritorio y de nuevo desde casa por la VPN. El diseño que sobrevive al contacto con los usuarios es una dirección canónica, por ejemplo https://crm.example.org/, con una ruta de red aprobada desde cada ubicación y un certificado válido para ese nombre. La VPN cambia cómo un cliente remoto llega al servidor. Nunca debería cambiar la identidad de la aplicación, porque en el momento en que lo hace, cada enlace generado, redirección y devolución de llamada de integración se convierte en un segundo problema que resolver.

Elija la URL antes de elegir la ruta

Anote primero la dirección prevista, incluido cualquier componente de ruta que necesite el CMS, y trátela como el punto fijo. Todo lo demás en este manual es un detalle de implementación que puede cambiar sin tocarla: qué respuesta DNS recibe cada grupo, qué regla de cortafuegos permite el receptor y si el tráfico llega por un túnel o por un puerto de conmutador local.

Registre cuatro valores juntos en el plan de acceso, porque solo funcionan como un conjunto. La URL canónica. La respuesta que debe recibir cada grupo de clientes para ese nombre. La ruta y la regla de acceso para esa respuesta. El nombre de host que el servidor web y el certificado están configurados para servir. Cuando algo se rompa más adelante, el elemento roto es uno de esos cuatro, y sabrá cuál cambió.

Paso 1: haga que el nombre se resuelva correctamente para ambos grupos

Ambos grupos deberían recibir una respuesta privada a la que realmente puedan llegar, y es legítimo que las respuestas difieran siempre que el nombre no difiera. Los clientes de LAN resuelven mediante el resolutor interno; los clientes de VPN necesitan una política de resolutor que les entregue la misma zona en lugar de filtrar la consulta a un resolutor público y obtener una respuesta pública que no pueden usar.

Pruebe el nombre desde cada contexto en lugar de suponerlo, y pruebe la ruta con independencia del DNS con la opción resolve de curl, que fija la dirección para una petición:

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

Si la primera prueba devuelve una dirección a la que el cliente no puede llegar, el problema es el enrutamiento del túnel o la lista de túnel dividido. Si la segunda prueba devuelve una redirección a un nombre de host que no esperaba, deténgase y lea el encabezado Location, porque eso es un problema de la aplicación y ningún cambio de ruta lo arreglará.

Paso 2: alinee el servidor web, el certificado y la URL base del CMS

El receptor debe estar configurado para servir el nombre canónico, y el certificado debe cubrirlo. Navegar por la dirección sin procesar no es una solución: produce una discrepancia de nombre, puede romper el ámbito de las cookies y enseña a los usuarios a pasar por alto advertencias que luego tendrá que explicar a un auditor.

Detrás de un proxy inverso, asegúrese de que la aplicación sabe que la petición llegó por HTTPS. La mayoría de las plataformas CMS generan enlaces absolutos a partir del esquema detectado, y un proxy que termina TLS sin reenviar el esquema original produce una página llena de recursos http:// que el navegador puede bloquear. Configure el proxy de confianza y los encabezados reenviados de forma explícita, en lugar de dejar que la aplicación adivine.

Después alinee la URL base del CMS y de CiviCRM. CiviCRM conserva su URL base determinada y ofrece una forma compatible de recalcularla: la acción administrativa Cleanup Caches and Update Paths, documentada en la guía de solución de problemas de instalación de CiviCRM. Ejecútela después de que coincidan el nombre canónico y el ajuste del CMS, no antes, o simplemente almacenará en caché un valor que está a punto de cambiar.

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

Paso 3: compruebe las direcciones que genera CiviCRM

Llegar a la página principal demuestra muy poco. CiviCRM se ejecuta dentro de un CMS, y las páginas que importan son las que construyen sus propias URL: la redirección de inicio de sesión, el menú de administración, los recursos de las extensiones, los enlaces a archivos subidos y cualquier devolución de llamada externa que registre una integración.

Cargue el panel, abra un registro de contacto y examine el código fuente de la página en busca de enlaces absolutos. Si apuntan a un nombre de host al que solo puede llegar un grupo de clientes, la URL base sigue siendo incorrecta aunque la página se haya mostrado. Si apuntan al nombre correcto pero al esquema incorrecto, la configuración del proxy es lo que hay que corregir.

Cuando la dirección realmente tenga que cambiar, trátelo como una migración de la aplicación y no como una edición de DNS. Revise las URL de recursos, las cachés, los enlaces publicados y cada integración externa que guarde la dirección antigua, y luego actualícelos en una sola ventana para que nadie se quede con un marcador migrado a medias.

El nombre de host de una petición no es una decisión de confianza

No seleccione una URL base privilegiada porque un encabezado de petición contenga una cadena concreta. PHP documenta configuraciones de Apache en las que el valor del nombre del servidor puede reflejar un host proporcionado por el cliente, y la variable de dirección del servidor describe el servidor, no la ubicación del visitante. Ninguno de los dos es un mecanismo de control de acceso, y construir uno a partir de ellos es como un servicio privado acaba sirviendo el contenido equivocado al host equivocado.

Si de verdad se necesitan varios nombres de host, configure una lista de permitidos explícita en el servidor web, en el CMS y en la capa de aplicación, y deje que el nombre de host de la petición elija solo entre entradas aprobadas. La entrada arbitraria nunca debería convertirse en la fuente de enlaces absolutos ni en un destino de redirección de confianza.

Termine con el mismo marcador en cada contexto aprobado: un inicio de sesión, una navegación interna ordinaria y una petición de recurso. Compare los nombres de host en las respuestas, no solo si la página se cargó. Esa comprobación de tres peticiones separa un problema de ruta de una aplicación que sigue generando la dirección incorrecta, y tarda aproximadamente un minuto por grupo de clientes.