Documentation de référence sur les propriétés des hôtes virtuels

Spécifie le nom de l'hôte virtuel. Vous utilisez ce nom pour faire référence à l'hôte virtuel lors de la configuration d'un proxy d'API.

Les caractères que vous pouvez utiliser dans l'attribut "name" sont limités à : A-Z0-9._\-$%.

Spécifie le numéro de port utilisé par l'hôte virtuel. Assurez-vous que le port est ouvert sur le routeur Edge.

Si vous spécifiez un port dans un élément hostalias, le numéro de port spécifié par <Port> doit correspondre.

Pour Cloud : vous devez spécifier le port 443 lorsque vous créez un hôte virtuel. Si elle est omise, le port est défini par défaut sur 443. Si vous disposez d'un hôte virtuel existant qui utilise un port autre que le port 443, vous ne pouvez pas modifier le port.

Pour les versions 4.16.01 à 4.17.05 de Private Cloud : lorsque vous créez un hôte virtuel, vous spécifiez le port du routeur utilisé par l'hôte virtuel. Par exemple, le port 9001. Par défaut, le routeur s'exécute en tant qu'utilisateur "apigee", qui n'a pas accès aux ports privilégiés, généralement les ports 1024 et inférieurs. Si vous souhaitez créer un hôte virtuel qui lie le routeur à un port protégé, vous devez configurer le routeur pour qu'il s'exécute en tant qu'utilisateur ayant accès à ces ports. Pour en savoir plus, consultez Configurer un hôte virtuel.

Pour les versions Private Cloud antérieures à 4.16.01 : un routeur ne peut écouter qu'une seule connexion HTTPS par hôte virtuel, sur un port spécifique, avec le certificat spécifié. Par conséquent, plusieurs hôtes virtuels ne peuvent pas utiliser le même numéro de port si la terminaison TLS se produit sur le routeur au port spécifié.

La valeur de BaseUrl doit inclure le protocole (par exemple, "http://" ou "https://").

Un client OCSP (Online Certificate Status Protocol) envoie une demande d'état à un répondeur OCSP pour déterminer si le certificat TLS est valide. La réponse indique si le certificat TLS est valide et n'a pas été révoqué.

Lorsqu'il est activé, l'agrafage OCSP permet à Edge, qui fait office de serveur TLS pour le protocole TLS unidirectionnel, d'interroger directement le répondeur OCSP et de mettre en cache la réponse. Edge renvoie ensuite cette réponse au client TLS ou l'agrafe dans le cadre de l'établissement de la liaison TLS. Pour en savoir plus, consultez Activer l'agrafage OCSP sur votre serveur.

Le protocole TLS doit être activé pour activer l'agrafage OCSP. Définissez la valeur sur on pour l'activer. La valeur par défaut est off.

Nom DNS visible publiquement de l'hôte virtuel sur le routeur, incluant éventuellement le numéro de port. La combinaison du nom de l'alias d'hôte et du numéro de port de l'hôte virtuel doit être unique pour tous les hôtes virtuels de l'installation Edge. Cela signifie que plusieurs hôtes virtuels peuvent utiliser le même numéro de port s'ils ont des alias d'hôte différents.

Vous devez créer une entrée DNS et un enregistrement CNAME correspondant à l'alias d'hôte. L'alias d'hôte doit correspondre à la chaîne que le client transmet dans l'en-tête Host.

Le numéro de port dans HostAlias est facultatif. Si vous spécifiez le port dans l'alias d'hôte, vous devez également spécifier le même port à l'aide de l'élément <Port>. Vous pouvez également spécifier deux éléments HostAlias, l'un avec le numéro de port et l'autre sans.

Vous pouvez avoir plusieurs définitions HostAlias dans la même définition d'hôte virtuel, correspondant à plusieurs entrées DNS pour l'hôte virtuel, mais pas pour plusieurs ports. Si vous souhaitez utiliser plusieurs ports, créez plusieurs définitions d'hôte virtuel avec des ports différents.

Vous pouvez inclure le caractère générique "*" dans l'alias d'hôte. Le caractère générique "*" ne peut être utilisé qu'au début de l'alias d'hôte (avant le premier ".") et ne peut pas être combiné avec d'autres caractères. Exemple : *.example.com. Le certificat TLS de l'hôte virtuel doit comporter un caractère générique correspondant dans le nom commun du certificat. Exemple :*.example.com L'utilisation d'un caractère générique dans un alias d'hôte virtuel permet aux proxys d'API de gérer les appels adressés à plusieurs sous-domaines tels que alpha.example.com, beta.example.com ou live.example.com. L'utilisation d'un alias générique vous permet également d'utiliser moins d'hôtes virtuels par environnement pour respecter les limites du produit, car un hôte virtuel avec un caractère générique ne compte que pour un seul hôte virtuel.

Pour Cloud : si vous disposez d'un hôte virtuel existant qui utilise un port autre que le port 443, vous ne pouvez pas ajouter ni supprimer d'alias d'hôte.

Pour le cloud privé : si vous définissez l'alias d'hôte à l'aide des adresses IP de vos routeurs et non des entrées DNS, ajoutez un alias d'hôte distinct pour chaque routeur, en spécifiant l'adresse IP de chaque routeur et le port de l'hôte virtuel.

Spécifie les interfaces réseau auxquelles vous souhaitez que port soit lié. Si vous omettez cet élément, le port est lié à toutes les interfaces.

Par exemple, pour spécifier de lier le port uniquement à en0 :

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

Déterminez les interfaces disponibles sur votre système en exécutant la commande "ifconfig -a".

Configurez la façon dont le routeur réagit pour cet hôte virtuel lorsque le processeur de messages tombe en panne.

Vous pouvez spécifier plusieurs valeurs à l'aide de <RetryOption>. Les valeurs valides sont les suivantes :

Si vous spécifiez plusieurs valeurs, le routeur les combine à l'aide d'un OR logique.

Exemple :

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

Si vous utilisez un ELB en mode TCP pass-thru pour gérer les requêtes adressées aux routeurs Edge, le routeur traite l'adresse IP de l'ELB comme adresse IP du client au lieu de l'adresse IP réelle du client. Si le routeur nécessite l'adresse IP réelle du client, activez proxy_protocol sur l'ELB afin qu'il transmette l'adresse IP du client dans le paquet TCP. Sur le routeur, vous devez également définir <ListenOption> sur proxy_protocol sur l'hôte virtuel. Étant donné que l'ELB est en mode direct TCP, vous mettez généralement fin à TLS sur le routeur. Par conséquent, vous ne configurez généralement l'hôte virtuel pour qu'il utilise proxy_protocol que lorsque vous le configurez également pour qu'il utilise TLS.

La valeur par défaut de <ListenOption> est une chaîne vide.

Exemple :

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

Pour annuler la définition de <ListenOption> ultérieurement, mettez à jour l'hôte virtuel et omettez le tag <ListenOptions> de la mise à jour.

Active le protocole TLS/SSL unidirectionnel. Vous devez avoir défini un keystore contenant le certificat et la clé privée.

Pour Cloud : vous devez disposer d'un certificat signé par une entité de confiance, telle que Symantec ou VeriSign. Vous ne pouvez pas utiliser de certificat autosigné ni de certificats feuilles signés par une autorité de certification autosignée.

Pour Cloud : si votre hôte virtuel existant est configuré pour utiliser un port autre que 443, vous ne pouvez pas modifier le paramètre TLS. Cela signifie que vous ne pouvez pas modifier le paramètre TLS (l'activer ou le désactiver).

Nom du keystore sur Edge.

Apigee vous recommande d'utiliser une référence pour spécifier le nom du keystore afin de pouvoir le modifier sans avoir à redémarrer les routeurs. Pour en savoir plus, consultez Options de configuration de TLS.

Nom du truststore sur Edge contenant le certificat ou la chaîne de certificats utilisés pour le protocole TLS bidirectionnel. Obligatoire si <ClientAuthEnabled> est défini sur "true".

Apigee vous recommande d'utiliser une référence pour spécifier le nom du truststore afin de pouvoir le modifier sans avoir à redémarrer les routeurs. Pour en savoir plus, consultez Options de configuration de TLS.

Si la valeur est "true", les erreurs de certificat TLS sont ignorées. Cela ressemble à l'option "-k" de cURL.

Cette option est valide lors de la configuration de TLS pour les serveurs cibles et les points de terminaison cibles, ainsi que lors de la configuration d'hôtes virtuels utilisant le TLS bidirectionnel.

Lorsqu'il est utilisé avec un point de terminaison cible ou un serveur cible, si le système backend utilise SNI et renvoie un certificat dont le nom distinctif (DN) de l'objet ne correspond pas au nom d'hôte, il est impossible d'ignorer l'erreur et la connexion échoue.

Pour Edge pour le cloud privé version 4.15.07 et versions antérieures uniquement.

Spécifie les algorithmes de chiffrement compatibles avec l'hôte virtuel. Si aucun algorithme n'est spécifié, tous les algorithmes de chiffrement disponibles pour la JVM sont autorisés.

Pour limiter les algorithmes de chiffrement, ajoutez les éléments suivants :

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

Pour Edge pour le cloud privé version 4.15.07 et versions antérieures uniquement.

Spécifie les protocoles acceptés par l'hôte virtuel. Si aucun protocole n'est spécifié, tous les protocoles disponibles pour la JVM seront autorisés.

Pour restreindre les protocoles, ajoutez les éléments suivants :

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

Si vous disposez d'un compte Edge pour le cloud payant, et que vous ne disposez pas encore d'un certificat et d'une clé TLS, vous pouvez créer un hôte virtuel utilisant un certificat et une clé freetrial Apigee. Cela signifie que vous pouvez créer l'hôte virtuel sans créer de keystore au préalable.

Le certificat d'essai sans frais Apigee est défini pour un domaine *.apigee.net. Par conséquent, le <HostAlias> de l'hôte virtuel doit également être au format *.apigee.net.

Consultez Définir un hôte virtuel qui utilise le certificat et la clé d'essai sans frais d'Apigee.

Permet à Edge de capturer les informations de connexion TLS. Ces informations sont ensuite disponibles en tant que variables de flux dans un proxy d'API. Pour en savoir plus, consultez Accéder aux informations de connexion TLS dans un proxy d'API.

Permet de capturer les détails du certificat client capturés par Edge dans le protocole TLS bidirectionnel. Ces informations sont ensuite disponibles en tant que variables de flux dans un proxy d'API. Pour en savoir plus, consultez Accéder aux informations de connexion TLS dans un proxy d'API.

Définit la durée du délai d'inactivité, en secondes, entre les processeurs de messages et le routeur. Le routeur abandonne la connexion et renvoie une réponse HTTP 504 s'il ne reçoit pas de réponse du processeur de messages avant l'expiration de cette durée.

La valeur de proxy_read_timeout doit être supérieure à la valeur du délai d'inactivité cible utilisée par le processeur de messages. Cela garantit que le routeur n'expire pas avant que le processeur de messages ait eu le temps de renvoyer une réponse. Le délai avant expiration de la cible par défaut pour le processeur de messages est de 55 secondes (55 000 millisecondes), comme défini par le jeton conf_http_HTTPTransport.io.timeout.millis pour le processeur de messages.

Définit la durée du délai d'inactivité, en secondes, entre le client et le routeur lorsque le client envoie une requête contenant l'en-tête Keep-Alive. Le routeur maintient la connexion ouverte jusqu'à expiration de la durée.

Le routeur ne fermera pas la connexion s'il attend actuellement une réponse du processeur de messages. Le délai commence uniquement après que le routeur a renvoyé la réponse au client.

Définit les codes secrets acceptés par l'hôte virtuel, en remplaçant les codes secrets par défaut définis sur le routeur.

Spécifiez une liste de codes de chiffrement délimitée par des deux-points, au format suivant :

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

Pour en savoir plus sur la syntaxe et les valeurs autorisées par ce jeton, consultez https://www.openssl.org/docs/man1.0.2/man1/ciphers.html. Notez que ce jeton utilise les noms de chiffrement OpenSSL, tels que AES128-SHA256, et non les noms de chiffrement Java/JSSE, tels que TLS_RSA_WITH_AES_128_CBC_SHA256.

!MD5 :

!DH+3DES:

!kEDH

Disponible uniquement pour Edge pour le cloud privé.

Définit les protocoles TLS compatibles avec l'hôte virtuel, sous la forme d'une liste délimitée par des espaces, en remplaçant les protocoles par défaut définis sur le routeur.

Remarque : Si deux hôtes virtuels partagent le même port, ils doivent définir ssl_protocols sur les mêmes protocoles. En d'autres termes, les hôtes virtuels partageant le même port doivent être compatibles avec exactement les mêmes protocoles.

Spécifiez une liste de protocoles TLS délimités par un espace, au format suivant :

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

Active (on) ou désactive (off) la mise en mémoire tampon du corps de la requête. Lorsque la mise en mémoire tampon est activée, le routeur met en mémoire tampon l'intégralité du corps de la requête avant de l'envoyer au processeur de messages. En cas d'erreur, le routeur peut réessayer avec un autre processeur de messages.

Si cette option est désactivée, la mise en mémoire tampon est désactivée et le corps de la requête est envoyé immédiatement au processeur de messages dès sa réception. En cas d'erreur, le routeur ne relance pas la requête auprès d'un autre processeur de messages.