Introducción
Este artículo aborda un caso de uso básico como el que podría tener en un entorno de preproducción. Todos los componentes de ArcGIS Enterprise (Portal, Server y Data Store) existen en una sola máquina en una red interna. El proxy inverso BIG-IP permite que el sistema se presente a otra red (podría ser una red interna de clientes o una red pública) con todo el tráfico de clientes dirigido a través del dispositivo BIG-IP.
Este artículo está dividido en tres secciones principales. La primera sección está destinada a los administradores de ArcGIS Enterprise y los orienta en sus tareas con el lenguaje y términos que entienden. La segunda sección está destinada al administrador de BIG-IP, esperando hablarles en el lenguaje y términos que comprenden. La sección final aborda opciones adicionales y detalles apropiados para ambos conjuntos de administradores.
El objetivo de este artículo es ayudar a los administradores de ArcGIS y F5 a trabajar juntos describiendo un conjunto probado de procedimientos alrededor del cual colaborar. Este artículo no busca habilitar a los administradores de ArcGIS para configurar F5 por sí mismos (o viceversa). Se asume que los administradores de ArcGIS son expertos en ArcGIS y dependen de la documentación de Esri para los detalles. De manera similar, se asume que los administradores de F5 son expertos en BIG-IP y dependen de la documentación de F5 para los detalles.
Aunque el caso de uso es "básico", la tarea no es "simple". El éxito requiere integrar tecnología y conocimiento de varios dominios especializados (tecnología Esri, tecnología F5, redes, certificados, etc.). Si los procedimientos en este artículo no son lo suficientemente claros para actuar en su contexto organizacional, puede ser una indicación de que sería beneficioso contar con apoyo consultor externo.
Este artículo se basa en las siguientes especificaciones del caso de uso:
- Uso del BIG-IP de F5 como un "OSI Layer 7" o "proxy completo"
- Uso de ArcGIS Enterprise donde el Web Adaptor se implementa con IIS en el sistema operativo Windows
Instrucciones para Administradores de ArcGIS
El enfoque del administrador de ArcGIS es desplegar ArcGIS Enterprise para que esté listo para ser proxyado por el proxy inverso BIG-IP. El objetivo del despliegue se muestra en el diagrama a continuación.
Dependiendo de los requisitos específicos, puede que no sea necesario desplegar Web Adaptors cuando se usa un proxy inverso. Sin embargo, se recomienda hacerlo por las siguientes razones:
- Usar Web Adaptors reduce la complejidad de configuración en el proxy inverso BIG-IP.
- Los Web Adaptors permiten validar la corrección del sistema ArcGIS Enterprise independientemente del proxy inverso; esto puede ser muy valioso en caso de solución de problemas.
- Aunque los Web Adaptors pueden desplegarse en sistemas basados en Linux usando un servidor web Java, la frecuencia del despliegue en Windows con IIS es la razón por la cual esta guía inicial se centra en ese patrón.
Paso Uno: Decisiones de Diseño y Comunicación con Administradores F5
En esta configuración, los clientes accederán a ArcGIS Enterprise a través del proxy inverso. El proxy inverso presenta un CNAME ("alias DNS", mostrado en verde en el diagrama abajo) que termina las sesiones HTTPS desde los clientes. Luego reinicia nuevas sesiones HTTPS desde sí mismo hacia el servidor web que aloja los web adaptors. El servidor web usualmente presenta un certificado con el nombre sujeto del registro A (el nombre del host, mostrado en rojo en el diagrama) que termina las sesiones HTTPS entrantes desde el proxy inverso BIG-IP.
Antes de desplegar su sistema, debe tomar las siguientes decisiones:
- ¿Cuál es el CNAME ("Alias DNS") bajo el cual el proxy inverso representará al sistema ArcGIS Enterprise?
- ¿Cuáles son los "contextos" ("nombres Web Adaptor", mostrados en azul en el diagrama) para Portal for ArcGIS y sitios ArcGIS Server?
Probablemente necesite cooperar con sus administradores F5 para acordar el CNAME y asegurarse de que tengan un certificado TLS apropiado para terminar las comunicaciones HTTPS en ese CNAME. Al mismo tiempo, puede compartir con los administradores F5 el nombre (el REGISTRO A) de la máquina donde operará su servidor web y a la cual deben enviarse las solicitudes.
Paso Dos: Desplegar un Servidor Web con Certificado TLS
Es útil desplegar su servidor web y configurarlo con un certificado TLS para tráfico HTTPS antes de hacer cualquier cosa directamente con ArcGIS Enterprise. Esto le permite asegurarse que HTTPS funciona con su servidor web, y permite a los administradores F5 configurar temprano el proxy inverso para el servidor web. Esto permite una validación temprana del certificado TLS y las rutas HTTPS.
Configurar HTTPS en su Servidor Web
Los pasos para habilitar HTTPS con servidores web varían según la marca del servidor web. Dado que IIS es un servidor web muy común, Esri ha proporcionado instrucciones sobre cómo configurarlo para HTTPS como parte de su guía de instalación del Web Adaptor: https://enterprise.arcgis.com/en/web-adaptor/latest/install/iis/enable-https-on-your-web-server-server-.htm.
Cuando habilite HTTPS en su servidor web, necesitará proporcionar un certificado TLS. Entre otros atributos, los certificados tienen Sujetos y Nombres Alternativos del Sujeto (SANs). El Sujeto del certificado debe coincidir con el nombre que usará el proxy inverso BIG-IP para dirigirse al servidor web. Esto suele ser el REGISTRO A (machine1.domain.local en el diagrama). El SAN es una lista de nombres alternativos. Una buena práctica para SANs es incluir:
- El nombre Sujeto (por ejemplo, machine1.domain.local)
- La versión corta del nombre sujeto (por ejemplo, machine1)
- El CNAME que presentará el proxy inverso (por ejemplo, gis.domain.com), si es posible
Dependiendo de la autoridad certificadora y políticas de su organización, puede o no poder incluir el CNAME en el SAN. El beneficio de hacerlo es que le permite mayor capacidad para validar ArcGIS Enterprise independientemente del proxy inverso.
Validar
Una vez configurado su servidor web para HTTPS, debe validar su configuración. Primero, debe validar navegando directamente a su servidor web desde un navegador usando el protocolo HTTPS. Segundo, si sus administradores F5 han configurado el proxy inverso BIG-IP para reenviar tráfico a su servidor web, entonces puede navegar al punto final del servidor virtual del proxy inverso también usando HTTPS. En cada caso, desea confirmar que no recibe advertencias sobre certificados y que la página objetivo se carga correctamente.
Típicamente, los servidores web tienen una página predeterminada que se devuelve cuando accede a la raíz del servidor web. Esa es una buena opción. Una mejor opción es desplegar una página web que le permita ver más sobre lo que está ocurriendo. Las páginas showHeaders (una para ASPX/IIS y otra para JSP: https://github.com/dannykrouk/showHeaders) devolverán muchos detalles útiles como se muestra abajo:
Considere desplegar y usar la página showHeaders en su servidor web y usarla como objetivo tanto para sus pruebas al servidor web como al proxy inverso. Si despliega la página en la raíz de su servidor web, puede probar con estas solicitudes:
Paso Tres: Desplegar y Configurar ArcGIS Enterprise
El despliegue de ArcGIS Enterprise aquí es una "implementación base en máquina única" (https://enterprise.arcgis.com/en/get-started/latest/windows/base-arcgis-enterprise-deployment.htm#ESRI_SECTION1_690F8D4A3ABE4FB8AE926C118E9F8299).
Instalar y Configurar lo Básico
La documentación para guiarte a través de los pasos de instalación está disponible en el sitio web de Esri: https://enterprise.arcgis.com/en/documentation/install/.
En este artículo, el nombre del Web Adaptor de Portal for ArcGIS ("contexto") es "/portal" y el nombre del Web Adaptor del Hosting Server es "/server". Cuando federas tu Hosting Server Site con tu Portal for ArcGIS, puedes usar el Web Adaptor tanto para la URL de Servicios como para la URL de Administración (https://enterprise.arcgis.com/en/portal/latest/administer/windows/configure-servers.htm), siempre que no estés usando autenticación Web Tier. Si estás usando autenticación Web Tier, tu URL de Administración debería seguir este patrón: https://machine1.domain.local:6443/arcgis.
Validar lo Básico; "Chequeo de Confianza del Sistema"
Una vez que tengas configurados tus Web Adaptors y federado tu Hosting Server, deberías realizar un breve "chequeo de confianza del sistema" para asegurarte de que las funciones principales funcionan correctamente.
Un chequeo típico de confianza del sistema incluiría:
- Iniciar sesión en /portaladmin
- Validar Federación
- Publicar un servicio
- Compartir el servicio
La "confianza" que se establece con estos pasos es que el sistema desplegado no tiene ningún fallo fundamental de configuración que impida la operación básica.
Cualquier cosa que crees (por ejemplo, un servicio publicado) en el chequeo de confianza del sistema debe ser eliminada antes de continuar.
Configuración Final para el Proxy Inverso
El paso final de configuración es configurar el WebContextURL para el Portal y el Hosting Server. Esta propiedad es cómo cada servidor Esri sabe el nombre por el cual los clientes lo direccionarán a través del proxy inverso BIG-IP.
Portal for ArcGIS: https://enterprise.arcgis.com/en/portal/latest/administer/windows/using-a-reverse-proxy-server-with-portal-for-arcgis.htm#ESRI_SECTION1_7C753FB1F19349A398E5FFCC6079A821
{
"WebContextURL": "https://gis.domain.com/portal"
}ArcGIS for Server: https://enterprise.arcgis.com/en/server/latest/deploy/linux/using-a-reverse-proxy-server-with-arcgis-server.htm#ESRI_SECTION1_13680C9069E14B1F8AE5793BE1ED25A6
{
"WebContextURL": "https://gis.domain.com/server"
}Paso Cuatro: Validación del Sistema
El cuarto y último paso para el administrador de ArcGIS es la "validación del sistema", independiente del proxy inverso BIG-IP. Si validas de esta manera, y algo no funciona cuando las solicitudes pasan por el proxy inverso, entonces la configuración del proxy inverso es lo que necesita atención. Si no validas así, puede ser mucho más complicado establecer la fuente del problema.
Cambiar Temporalmente la Resolución de Nombre en la Máquina del Servidor Web
El truco para esta validación es convencer temporalmente al sistema que el CNAME (gis.domain.com) está en la máquina ArcGIS Enterprise (machine1.domain.local). Si tienes permisos de administrador local en la máquina machine1.domain.local, puedes editar el archivo hosts. Si machine1.domain.local tiene la dirección IP 10.0.0.10, entonces la entrada en el archivo hosts se vería así:
10.0.0.10 gis.domain.com
Esto dice, "gis.domain.com puede encontrarse en 10.0.0.10".
Cuando completes tu edición a este archivo (que usualmente se encuentra aquí: C:\Windows\System32\drivers\etc\hosts), abre una consola de comandos y confirma que tu configuración es efectiva con ping:
C:\>ping gis.domain.com
Haciendo ping a gis.domain.com [10.0.0.10] con 32 bytes de datos:
Respuesta desde <Dirección IP de machine1>: bytes=32 tiempo=22ms TTL=124
…
El resultado del comando ping debería ser la dirección IP en tu archivo hosts, el valor marcador resaltado arriba para mayor claridad.
Probar en un Navegador en la Máquina del Servidor Web
Ahora, abre un navegador web en machine1.domain.local y ejecuta nuevamente tu "chequeo de confianza del sistema", esta vez dirigiéndote al sistema por su CNAME (https://gis.domain.com/portal/home/).
Si tu sistema funciona correctamente así, revierte el cambio en el archivo hosts y pide a los administradores F5 que completen su trabajo de configuración.
Instrucciones para Administradores F5
Desde la perspectiva BIG-IP, esta es una configuración simple. El sistema ArcGIS Enterprise tiene varios componentes. Pero, desde el punto de vista del proxy inverso, hay un único nodo servidor web backend escuchando en HTTPS/443. El único elemento de configuración que puede ser diferente a otros sistemas es que ArcGIS Enterprise requiere que el proxy inverso incluya un encabezado X-Forwarded-Host.
A nivel general, tu configuración proxy terminará todo el tráfico HTTPS al CNAME gis.domain.com y re-iniciará HTTPS al único nodo backend, machine1.domain.local. El servidor web en esta dirección soporta dos "contextos", uno para cada componente principal del sistema ArcGIS Enterprise (Portal for ArcGIS y ArcGIS Server): /portal y /server.
Como se describe en la introducción de este artículo, asumimos que tienes tres redes asociadas con tu proxy BIG-IP: una red cliente, una red servidor y tu red administrativa.
Este artículo asume que eres un experto en administración BIG-IP y solo necesitas indicaciones sobre los pasos para configurar este servidor virtual y pool backend en el orden óptimo.
Paso Uno: Proxy al Servidor Web
El CNAME para este sistema debería haberse establecido contigo o haberte sido comunicado. También debería proporcionarse un certificado TLS coincidente para ese CNAME. La autoridad certificadora debe ser una confiable por los clientes de este sistema.
Instalar el Certificado TLS
Instala el certificado TLS para el Servidor Virtual en BIG-IP (por ejemplo, Sujeto gis.domain.com)
Sistema > Gestión de Certificados > Gestión de Certificados de Tráfico > Lista de Certificados SSL > Importar Certificado SSL
Crear Perfil SSL Cliente
Crea un perfil cliente para terminar conexiones TLS cliente sobre el certificado para el nombre gis.domain.com.
Tráfico Local > Perfiles > SSL > Cliente > Crear
Crear un Pool con un Monitor Simple
Crea un Pool backend para el servidor web (por ejemplo, https://machine1.domain.local/ ) con un Monitor Simple para determinar si el recurso nodo está "activo" o "caído".
Tráfico Local > Pools > Lista de Pools > Crear
<\/span><\/H3> <\/P>Crear un Perfil de Servicios HTTP (Agregar el encabezado X-Forwarded-Host)<\/H3>El encabezado X-Forwarded-Host permite que ArcGIS Enterprise conozca el valor del encabezado Host que llegó a BIG-IP. El sistema ArcGIS Enterprise verificará este valor contra su configuración para asegurar que los clientes lo hayan dirigido de manera apropiada. Si el encabezado X-Forwarded-Host no está presente, o contiene un valor incorrecto, ArcGIS Enterprise emitirá una redirección HTTP para señalar cómo cree que debe ser dirigido. Esto puede resultar en bucles de redirección. En caso de que ArcGIS Enterprise detecte un bucle de redirección, lo romperá y devolverá un error.<\/P>Se puede incluir un encabezado X-Forwarded-Host con una iRule:<\/P>when HTTP_REQUEST {
HTTP::header insert X-Forwarded-Host [HTTP::host]
}<\/PRE> <\/P>Esta directiva toma el valor del encabezado Host de la solicitud entrante y lo establece como el valor del encabezado X-Forwarded-Host para el pool predeterminado.<\/P>Crear el Servidor Virtual<\/H3>Tráfico Local > Servidores Virtuales > Crear<\/P>Seleccione "Estándar" para Tipo de Servidor Virtual. Especifique su Perfil SSL (Cliente) que creó anteriormente con su certificado SSL. Al especificar un perfil de Servidor, el objetivo de la configuración es lograr un túnel TLS hacia el backend. Esto se puede lograr con la configuración predeterminada "serverssl" dentro de BIG-IP. Configure "Traducción de Dirección de Origen" en Auto Map.<\/P>
<\/span><\/P> En la pestaña Recursos, seleccione su pool que creó antes.<\/P>
<\/span><\/P> <\/P>Paso Dos: Validar el Proxy hacia ArcGIS Enterprise<\/H2>Hay dos pasos para validar la efectividad de esta configuración. <\/P>Validar Confianza y Encabezados<\/H3>Asumiendo que la página showHeaders.aspx fue desplegada en el servidor web backend, use un navegador web para navegar a https:\/\/gis.domain.com\/showHeaders.aspx<\/A>. El navegador debería estar libre de advertencias de confianza del certificado. El cuerpo de la respuesta de la página debería demostrar la efectividad del aspecto del encabezado X-Forwarded-Host en su configuración.<\/P> 
<\/span><\/P> <\/P>En este punto, con el flujo del encabezado confirmado hacia el backend, ya no hay necesidad de la herramienta showHeaders.aspx. Si su sistema está destinado para PRODUCCIÓN, o cualquier entorno donde la información expuesta no debería ser expuesta, la herramienta debe ser eliminada.<\/P>
Pensamientos Finales<\/>Después de haber completado las instrucciones hasta ahora, debería tener un sistema ArcGIS Enterprise completamente funcional accesible a través del proxy inverso BIG-IP de F5. Felicitaciones. <\/>Este artículo ofrece los siguientes pensamientos finales.<\/>Pruebas<\/>Estas instrucciones estipularon "verificaciones de confianza del sistema" y validaciones durante todo el proceso de despliegue/configuración. Estas medidas tenían como objetivo determinar si era razonable continuar al siguiente paso en las instrucciones. Estas medidas no prueban que el sistema sea aceptable. Al final, asumimos que todo el sistema funciona. En otras palabras, estas pruebas establecen que el sistema tiene coherencia funcional.<\/>Pasear el sistema para pruebas de aceptación es el siguiente paso apropiado. El objetivo de las pruebas de aceptación es medir el sistema desplegado contra los objetivos comerciales que debe soportar.<\/>Chequeo de Salud<\/>El Monitoreo Simple incluido en las instrucciones para los administradores F5 permite que BIG-IP deje de reenviar solicitudes al sistema ArcGIS Enterprise si el nodo (es decir, machine1.domain.local) está caído o inaccesible. Para un sistema como este, con solo un miembro del Pool backend, esto (un Monitor Simple) es todo lo recomendado para chequeo de salud.<\/>En principio, BIG-IP puede configurarse con chequeos de salud fuera de banda que le pidan al software ArcGIS Enterprise confirmar su salud o validar que solicitudes HTTPS específicas tengan éxito con cargas útiles particulares en la respuesta. Por ejemplo, el componente Portal for ArcGIS de ArcGIS Enterprise expone este endpoint: https://developers.arcgis.com/rest/enterprise-administration/portal/health-check-portal.htm. & nbsp;En un sistema de nodo único, la respuesta a un problema en chequeo de salud esencialmente elimina todo acceso al sistema.& nbsp; La ventaja es que el proxy inverso puede proporcionar un error genérico a los clientes indicando que el sistema está caído.& nbsp; La desventaja es que un problema temporal, parcial o una mala interpretación a través del chequeo elimina todo acceso al sistema cuando aún podría ser utilizable para muchos casos de uso.& nbsp; La probabilidad de falsos negativos (hallazgos no saludables) asociados con chequeos formales/complejos puede resultar en menor confiabilidad del sistema para los usuarios finales en comparación con los falsos positivos (hallazgos saludables) asociados con monitoreo simple del nodo.& nbsp; En otras palabras, para un sistema de nodo único la complejidad es enemiga de la confiabilidad; manténgase con un Monitor Simple.<\/>Créditos<\/>Este artículo fue producido basado en el trabajo de Roger Schlogel, consultor con Servicios Profesionales de Esri.<\/>& nbsp;<\/>& nbsp;<\
