Referencia de la propiedad del host virtual

Especifica el nombre del host virtual. Usarás ese nombre para hacer referencia al host virtual cuando configures un proxy de API.

Los caracteres que se pueden utilizar en el atributo de nombre se restringen a los siguientes caracteres: A-Z 0-9._\-$%.

Especifica el número de puerto que usa el host virtual. Asegúrate de que el puerto esté abierto en el router perimetral.

Si especificas un puerto en un elemento hostalias, el número de puerto que especifica <Port> debe coincidir con él.

Para Cloud: Debes especificar el puerto 443 cuando creas un host virtual. Si se omite, de forma predeterminada, el puerto se establece en 443. Si tienes un host virtual existente que usa un puerto que no sea el 443, no podrás cambiarlo.

Para las versiones de nube privada 4.16.01 a 4.17.05: Cuando creas un host virtual, especificas el puerto del router que usa el host virtual. Por ejemplo, el puerto 9001. De forma predeterminada, el router se ejecuta como el usuario “apigee”, que no tiene acceso a puertos con privilegios, por lo general, en los puertos 1024 y inferiores. Si deseas crear un host virtual que vincule el router a un puerto protegido, debes configurar el router para que se ejecute como un usuario con acceso a esos puertos. Consulta Configura un host virtual para obtener más información.

Para las versiones de nube privada anteriores a la versión 4.16.01: Un router solo puede escuchar una conexión HTTPS por host virtual, en un puerto específico, con el certificado especificado. Por lo tanto, varios hosts virtuales no pueden usar el mismo número de puerto si se produce la finalización de TLS en el router en el puerto especificado.

El valor de BaseUrl debe incluir el protocolo (es decir, "http://" o "https://").

Un cliente OCSP (Online Certificate Status Protocol) envía una solicitud de estado a una respuesta de OCSP para determinar si el certificado TLS es válido. La respuesta indica si el certificado TLS es válido y no está revocado.

Cuando se habilita, el grabado de OCSP permite que Edge, que actúa como el servidor de TLS para TLS unidireccional, consulte directamente al usuario que responde OCSP y almacene la respuesta en caché. Luego, Edge mostrará esta respuesta al cliente de TLS, o la engrapa, como parte del protocolo de enlace TLS. Consulta Habilita el Stapling OCSP en tu servidor para obtener más información.

Se debe habilitar TLS para habilitar el grabado de OCSP. Configúralo en on para habilitarlo. El valor predeterminado es off.

El nombre de DNS visible públicamente del host virtual en el router, que incluye el número de puerto de forma opcional. La combinación del nombre del alias de host y el número de puerto del host virtual debe ser única para todos los hosts virtuales de la instalación perimetral. Esto significa que varios hosts virtuales pueden usar el mismo número de puerto si tienen diferentes alias de host.

Debes crear una entrada DNS y un registro CNAME que coincidan con el alias del host, y el alias del host debe coincidir con la string que pasa el cliente en el encabezado Host.

El número de puerto en HostAlias es opcional. Si especificas el puerto como parte del alias del host, también debes especificar el mismo puerto mediante el elemento <Port>. O bien, puedes especificar dos elementos HostAlias, uno con el número de puerto y otro sin él.

Puedes tener varias definiciones de HostAlias en la misma definición de host virtual, que correspondan a varias entradas de DNS para el host virtual, pero no a varios puertos. Si deseas tener varios puertos, crea varias definiciones de host virtual con diferentes puertos.

Puedes incluir el carácter comodín “*” en el alias del host. El carácter comodín “*” solo puede estar al comienzo (antes del primer “.”) del alias del host y no se puede mezclar con otros caracteres. Por ejemplo: *.example.com. El certificado TLS para el host virtual debe tener un comodín coincidente en el nombre CN del certificado. Por ejemplo, *.example.com El uso de un comodín en un alias de host virtual permite que los proxies de API controlen las llamadas dirigidas a varios subdominios, como alpha.example.com, beta.example.com o live.example.com. El uso de un alias de comodín también te ayuda a usar menos hosts virtuales por entorno para mantenerte dentro de los límites del producto, ya que un host virtual con un comodín cuenta como solo un host virtual.

Para Cloud: Si tienes un host virtual existente que usa un puerto distinto del 443, no puedes agregar ni quitar un alias de host.

Para la nube privada: Si configuras el alias de host mediante las direcciones IP de tus routers en lugar de entradas de DNS, agrega un alias de host independiente para cada router y especifica la dirección IP de cada router y puerto del host virtual.

Especifica las interfaces de red a las que deseas vincular port. Si omites este elemento, el puerto estará vinculado en todas las interfaces.

Por ejemplo, para especificar que se vincule el puerto solo a en0, haz lo siguiente:

<Interfaces>
  <Interface>en0</Interface>
</Interfaces>

Determina las interfaces disponibles en tu sistema ejecutando el comando “ifconfig -a”.

Configura la manera en que el router reacciona a este host virtual cuando el Message Processor deja de funcionar.

Puedes especificar varios valores mediante <RetryOption>. Entre los valores válidos, se incluyen los siguientes:

Si especificas varios valores, el router utiliza un operador lógico OR para combinarlos.

Por ejemplo:

<RetryOptions>
  <RetryOption>http_599</RetryOption>
  <RetryOption>error</RetryOption>
  <RetryOption>timeout</RetryOption>
  <RetryOption>invalid_header</RetryOption>
</RetryOptions>

Si usas un ELB en el modo de paso de TCP para controlar las solicitudes a los routers perimetrales, el router trata la dirección IP del ELB como la IP de cliente, en lugar de la IP de cliente real. Si el router requiere la verdadera IP de cliente, habilita proxy_protocol en el ELB para que pase la IP de cliente en el paquete de TCP. En el router, también debes configurar <ListenOption> en el host virtual como proxy_protocol. Debido a que el ELB está en modo de transferencia de TCP, por lo general, finaliza TLS en el router. Por lo tanto, por lo general, solo debes configurar el host virtual para que use proxy_protocol cuando también lo configuras para que use TLS.

El valor predeterminado para <ListenOption> es una string vacía.

Por ejemplo:

<ListenOptions>
  <ListenOption>proxy_protocol</ListenOption>
</ListenOptions>

Para anular la configuración de <ListenOption> más adelante, actualiza el host virtual y omite la etiqueta <ListenOptions> de la actualización.

Habilita TLS/SSL unidireccional. Debes definir un almacén de claves que contenga el certificado y la clave privada.

En Cloud: Debe tener un certificado firmado por una entidad de confianza, como Symantec o VeriSign. No puedes usar un certificado autofirmado ni certificados de hoja firmados por una CA autofirmada.

Para Cloud: Si tu host virtual existente está configurado para usar un puerto que no sea el 443, no podrás cambiar la configuración de TLS. Esto significa que no puedes cambiar la configuración de TLS de habilitada a inhabilitada, o de inhabilitada a habilitada.

Es el nombre del almacén de claves en Edge.

Apigee recomienda que uses una referencia para especificar el nombre del almacén de claves a fin de que puedas cambiarlo sin tener que reiniciar los routers. Consulta Opciones para configurar TLS a fin de obtener más información.

El nombre del almacén de confianza en Edge que contiene el certificado o la cadena de certificados que se usa para la TLS bidireccional. Es obligatorio si <ClientAuthEnabled> es verdadero.

Apigee recomienda que uses una referencia para especificar el nombre del almacén de confianza a fin de que puedas cambiarlo sin tener que reiniciar los routers. Consulta Opciones para configurar TLS a fin de obtener más información.

Si es verdadero, especifica que se deben ignorar los errores del certificado TLS. Esto es similar a la opción “-k” para cURL.

Esta opción es válida cuando se configura TLS para servidores de destino y extremos de destino y cuando se configuran hosts virtuales que usan TLS bidireccional.

Cuando se usa con un extremo o servidor de destino, si el sistema de backend usa SNI y muestra un certificado con un nombre distinguido (DN) de tema que no coincide con el nombre de host, no hay forma de ignorar el error y la conexión falla.

Solo para la versión 4.15.07 y anteriores de Edge para la nube privada.

Especifica los algoritmos de cifrado compatibles con el host virtual. Si no se especifican algoritmos de cifrado, se permitirán todos los cifrados disponibles para la JVM.

Para restringir los cifrados, agrega los siguientes elementos:

<Ciphers>
  <Cipher>TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA</Cipher>
  <Cipher>TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256</Cipher>
</Ciphers>

Solo para la versión 4.15.07 y anteriores de Edge para la nube privada.

Especifica los protocolos compatibles con el host virtual. Si no se especifican protocolos, se permitirán todos los protocolos disponibles para la JVM.

Para restringir protocolos, agrega los siguientes elementos:

<Protocols>
  <Protocol>TLSv1</Protocol>
  <Protocol>TLSv1.2</Protocol>
  <Protocol>SSLv2Hello</Protocol>
</Protocols>

Si tienes una cuenta pagada de Edge para Cloud y aún no tienes un certificado y una clave de TLS, puedes crear un host virtual que use el certificado y la clave de la prueba gratuita de Apigee. Eso significa que puedes crear el host virtual sin crear primero un almacén de claves.

El certificado de prueba gratuita de Apigee se define para un dominio de *.apigee.net. Por lo tanto, el <HostAlias> del host virtual también debe tener el formato *.apigee.net.

Consulta Define un host virtual que use el certificado y la clave de la prueba gratuita de Apigee.

Habilita la captura de información de conexión TLS por parte de Edge. Luego, esta información está disponible como variables de flujo en un proxy de API. Consulta Accede a la información de conexión de TLS en un proxy de API para obtener más información.

Habilita la captura de los detalles del certificado de cliente capturados por Edge en TLS bidireccional. Luego, esta información está disponible como variables de flujo en un proxy de API. Consulta Accede a la información de conexión de TLS en un proxy de API para obtener más información.

Establece la duración del tiempo de espera, en segundos, entre los procesadores de mensajes y el router. El router descarta la conexión y muestra una respuesta HTTP 504 si no recibe una respuesta del procesador de mensajes antes de que venza el período.

El valor de proxy_read_timeout debe ser mayor que el valor de tiempo de espera objetivo que usa Message Processor. Esto garantiza que el router no agote el tiempo de espera antes de que el procesador de mensajes haya tenido tiempo de mostrar una respuesta. El tiempo de espera objetivo predeterminado para Message Processor es de 55 segundos y 55, 000 milisegundos, según lo definido por el token conf_http_HTTPTransport.io.timeout.millis para Message Processor.

Establece la duración del tiempo de espera, en segundos, entre el cliente y el router cuando el cliente realiza una solicitud que contiene el encabezado Keep-Alive. El router mantiene la conexión abierta hasta que vence el plazo.

El router no cerrará la conexión si está esperando una respuesta de Message Processor. El tiempo de espera comienza solo después de que el router muestra la respuesta al cliente.

Establece los algoritmos de cifrado que admite el host virtual y anula los cifrados predeterminados establecidos en el router.

Especifica una lista de cifrados delimitados por dos puntos, con el siguiente formato:

<Property name="ssl_ciphers">HIGH:!aNULL:!MD5:!DH+3DES:!kEDH;</Property>

Para obtener información sobre la sintaxis y los valores que permite este token, consulta https://www.openssl.org/docs/man1.0.2/man1/crypts.html. Ten en cuenta que este token usa los nombres de cifrado OpenSSL, como AES128-SHA256, y no los nombres de algoritmo de cifrado Java/JSSE, como TLS_RSA_WITH_AES_128_CBC_SHA256.

MD5:

!DH+3DES:

!kEDH

Disponible solo en Edge para la nube privada.

Configura los protocolos TLS compatibles con el host virtual, como una lista delimitada por espacios, y anula los protocolos predeterminados establecidos en el router.

Nota: Si dos hosts virtuales comparten el mismo puerto, deben configurar ssl_protocols en los mismos protocolos. Es decir, los hosts virtuales que comparten el mismo puerto deben admitir los mismos protocolos.

Especifica una lista de protocolos TLS delimitada por espacios, con el siguiente formato:

<Property name="ssl_protocols">TLSv1 TLSv1.2</Property>

Habilita (activa) o inhabilita (desactiva) el almacenamiento en búfer del cuerpo de la solicitud. Cuando el almacenamiento en búfer está activado, el router almacena en búfer todo el cuerpo de la solicitud antes de enviarla al Message Processor. Si se produce un error, el router puede reintentar con otro Message Processor.

Si está desactivado, se inhabilita el almacenamiento en búfer y el cuerpo de la solicitud se envía al Message Processor inmediatamente después de que se recibe. Si se produce un error, el router no vuelve a intentar la solicitud a otro Message Processor.