Referência da propriedade do host virtual

Especifica o nome do host virtual. Use esse nome para fazer referência ao host virtual ao configurar um proxy de API.

Os caracteres que podem ser usados no atributo de nome são restritos a: A-Z0-9._\-$%.

Especifica o número da porta usado pelo host virtual. Verifique se a porta está aberta no roteador de borda.

Se você especificar uma porta em um elemento hostalias, o número de porta especificado por <Port> precisa corresponder a ele.

Para a Nuvem: é necessário especificar a porta 443 ao criar um host virtual. Se omitido, a porta será definida como 443 por padrão. Se você tiver um host virtual que usa uma porta diferente da 443, não será possível mudar a porta.

Para as versões 4.16.01 a 4.17.05 da nuvem privada:ao criar um host virtual, você especifica a porta do roteador usada por ele. Por exemplo, a porta 9001. Por padrão, o roteador é executado como o usuário "apigee", que não tem acesso a portas privilegiadas, normalmente a partir da 1024. Se você quiser criar um host virtual que associe o roteador a uma porta protegida, configure o roteador para ser executado como um usuário com acesso a essas portas. Consulte Como configurar um host virtual para mais informações.

Para versões da nuvem privada anteriores à 4.16.01:um roteador pode detectar apenas uma conexão HTTPS por host virtual, em uma porta específica, com o certificado especificado. Portanto, vários hosts virtuais não podem usar o mesmo número de porta se a terminação TLS ocorrer no roteador na porta especificada.

O valor de BaseUrl precisa incluir o protocolo (por exemplo, "http://" ou "https://").

Um cliente OCSP (Online Certificate Status Protocol) envia uma solicitação de status para um respondente OCSP para determinar se o certificado TLS é válido. A resposta indica se o certificado TLS é válido e não foi revogado.

Quando ativada, a agrupamento de OCSP permite que o Edge, atuando como o servidor TLS para TLS unidirecional, consulte o atendente do OCSP diretamente e armazene em cache a resposta. Depois, o Edge retorna essa resposta para o cliente TLS ou a usa como parte do handshake de TLS. Consulte Ativar a vinculação OCSP no seu servidor para saber mais.

O TLS precisa estar ativado para ativar a vinculação OCSP. Defina como on para ativar. O valor padrão é off.

O nome DNS visível publicamente do host virtual no roteador, incluindo opcionalmente o número da porta. A combinação do nome do alias do host e do número da porta do host virtual precisa ser exclusiva para todos os hosts virtuais na instalação do Edge. Isso significa que vários hosts virtuais podem usar o mesmo número de porta se tiverem aliases de host diferentes.

É necessário criar uma entrada DNS e um registro CNAME que correspondam ao alias do host, e o alias do host precisa corresponder à string que o cliente transmite no cabeçalho Host.

O número da porta em HostAlias é opcional. Se você especificar a porta como parte do alias do host, também precisará especificar a mesma porta usando o elemento <Port>. Se preferir, especifique dois elementos HostAlias, um com o número da porta e outro sem.

É possível ter várias definições de HostAlias na mesma definição de host virtual, correspondendo a várias entradas de DNS para o host virtual, mas não para várias portas. Se você quiser várias portas, crie várias definições de host virtual com portas diferentes.

É possível incluir o caractere curinga "*" no alias de host. O caractere curinga "*" só pode estar no início (antes do primeiro ".") do alias do host e não pode ser misturado com outros caracteres. Por exemplo: *.example.com O certificado TLS do host virtual precisa ter um curinga correspondente no nome CN do certificado. Por exemplo, *.example.com. O uso de um caractere curinga em um alias de host virtual permite que os proxies de API processem chamadas endereçadas a vários subdomínios, como alpha.example.com, beta.example.com ou live.example.com. O uso de um alias curinga também ajuda a usar menos hosts virtuais por ambiente para ficar dentro dos limites do produto, já que um host virtual com um curinga conta como apenas um host virtual.

Para o Cloud: se você tiver um host virtual que usa uma porta diferente da 443, não será possível adicionar ou remover um alias de host.

Para a nuvem particular:se você estiver definindo o alias de host usando os endereços IP dos roteadores, e não as entradas de DNS, adicione um alias de host separado para cada roteador, especificando o endereço IP de cada roteador e a porta do host virtual.

Especifica as interfaces de rede a que você quer vincular port. Se você omitir esse elemento, a porta será vinculada em todas as interfaces.

Por exemplo, para especificar a vinculação da porta apenas a en0:

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

Determine as interfaces disponíveis no sistema executando o comando "ifconfig -a".

Configure como o roteador reage para esse host virtual quando o processador de mensagens fica inativo.

É possível especificar diversos valores usando <RetryOption>. Os valores válidos incluem:

Se você especificar vários valores, o roteador usará um OR lógico para combiná-los.

Exemplo:

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

Se você usar um ELB no modo de passagem TCP para processar solicitações aos Roteadores de borda, o roteador vai tratar o endereço IP do ELB como o IP do cliente em vez do IP real do cliente. Se o roteador exigir o IP verdadeiro do cliente, ative proxy_protocol no ELB para que ele transmita o IP do cliente no pacote TCP. No roteador, também é necessário definir o <ListenOption> no host virtual como proxy_protocol. Como o ELB está no modo de passagem TCP, você normalmente encerra o TLS no roteador. Portanto, geralmente, você só configura o host virtual para usar proxy_protocol quando também o configura para usar TLS.

O valor padrão de <ListenOption> é uma string vazia.

Exemplo:

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

Para redefinir <ListenOption> mais tarde, atualize o host virtual e omita a tag <ListenOptions> da atualização.

Ativa TLS/SSL unidirecional. Você precisa ter definido um keystore que contenha o certificado e a chave privada.

Para o Cloud: você precisa ter um certificado assinado por uma entidade confiável, como Symantec ou VeriSign. Não é possível usar um certificado autoassinado ou certificados de folha assinados por uma AC autoassinada.

Para o Cloud: se o host virtual atual estiver configurado para usar uma porta diferente da 443, não será possível mudar a configuração de TLS. Isso significa que não é possível mudar a configuração de TLS de ativada para desativada ou vice-versa.

O nome do keystore no Edge.

A Apigee recomenda que você use uma referência para especificar o nome do keystore. Assim, é possível alterá-lo sem precisar reiniciar os roteadores. Consulte Opções para configurar o TLS para mais informações.

O nome do repositório de confiança no Edge que contém o certificado ou a cadeia de certificados usada para TLS bidirecional. Obrigatório se <ClientAuthEnabled> for verdadeiro.

A Apigee recomenda que você use uma referência para especificar o nome do truststore para que você possa mudar o truststore sem precisar reiniciar os roteadores. Consulte Opções para configurar o TLS para mais informações.

Se verdadeiro, especifica que os erros de certificado TLS serão ignorados. Isso é semelhante à opção "-k" para cURL.

Essa opção é válida ao configurar o TLS para servidores de destino e endpoints de destino, além de configurar hosts virtuais que usam TLS bidirecional.

Quando usado com um endpoint de destino/servidor de destino, se o sistema de back-end usar SNI e retornar um certificado com um nome distinto (DN, na sigla em inglês) de assunto que não corresponda ao nome do host, não será possível ignorar o erro e a conexão falha.

Apenas para o Edge para nuvem privada versão 4.15.07 e anteriores.

Especifica as criptografias compatíveis com o host virtual. Se nenhuma criptografia for especificada, todas as criptografias disponíveis para a JVM serão permitidas.

Para restringir as criptografias, adicione os seguintes elementos:

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

Somente para a versão 4.15.07 e anteriores do Edge para nuvem privada.

Especifica os protocolos aceitos pelo host virtual. Se nenhum protocolo for especificado, todos os protocolos disponíveis para a JVM serão permitidos.

Para restringir protocolos, adicione os seguintes elementos:

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

Se você tiver uma conta paga do Edge para Cloud e ainda não tiver um certificado e uma chave TLS, crie um host virtual que use o certificado e a chave de avaliação sem custo financeiro da Apigee. Isso significa que você pode criar o host virtual sem criar um keystore primeiro.

O certificado de teste sem custo financeiro da Apigee foi definido para um domínio de *.apigee.net. Portanto, o <HostAlias> do host virtual também precisa estar no formato *.apigee.net.

Consulte Como definir um host virtual que usa o certificado e a chave de avaliação sem custo financeiro da Apigee.

Permite a captura de informações de conexão TLS pelo Edge. Essas informações ficam disponíveis como variáveis de fluxo em um proxy de API. Consulte Como acessar informações de conexão TLS em um proxy de API para mais informações.

Permite a captura de detalhes do certificado do cliente capturados pelo Edge no TLS bidirecional. Essas informações ficam disponíveis como variáveis de fluxo em um proxy de API. Consulte Como acessar informações de conexão TLS em um proxy de API para mais informações.

Define a duração do tempo limite, em segundos, entre os processadores de mensagens e o roteador. O roteador descarta a conexão e retorna uma resposta HTTP 504 se não receber uma resposta do processador de mensagens antes que esse período expire.

O valor de proxy_read_timeout precisa ser maior que o valor de tempo limite de destino usado pelo processador de mensagens. Isso garante que o roteador não tenha um tempo limite antes que o processador de mensagens tenha tempo para retornar uma resposta. O tempo limite de destino padrão para o processador de mensagens é de 55 segundos, 55.000 milissegundos, conforme definido pelo token conf_http_HTTPTransport.io.timeout.millis para o processador de mensagens.

Define a duração do tempo limite, em segundos, entre o cliente e o roteador quando o cliente faz uma solicitação contendo o cabeçalho Keep-Alive. O roteador mantém a conexão aberta até que a duração expire.

O roteador não fechará a conexão se estiver aguardando uma resposta do processador de mensagens. O tempo limite só começa depois que o roteador retorna a resposta ao cliente.

Define as criptografias aceitas pelo host virtual, substituindo as criptografias padrão definidas no roteador.

Especifique uma lista de criptografias delimitadas por dois pontos, no formato:

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

Para saber mais sobre a sintaxe e os valores permitidos por esse token, consulte https://www.openssl.org/docs/man1.0.2/man1/ciphers.html. Esse token usa os nomes de criptografia do OpenSSL, como AES128-SHA256, e não os nomes de criptografia do Java/JSSE, como TLS_RSA_WITH_AES_128_CBC_SHA256.

!MD5:

!DH+3DES:

!kEDH

Disponível apenas para o Edge para nuvem privada.

Define os protocolos TLS aceitos pelo host virtual como uma lista delimitada por espaços, substituindo os protocolos padrão definidos no roteador.

Observação: se dois hosts virtuais compartilharem a mesma porta, eles precisarão definir ssl_protocols com os mesmos protocolos. Ou seja, os hosts virtuais que compartilham a mesma porta precisam oferecer suporte aos mesmos protocolos.

Especifique uma lista de protocolos TLS delimitada por espaços no formato:

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

Ativa (ativado) ou desativa (desativado) o buffer do corpo da solicitação. Quando o buffer está ativado, o roteador armazena em buffer todo o corpo da solicitação antes de enviar para o processador de mensagens. Em caso de erro, o roteador pode tentar usar outro processador de mensagens novamente.

Se estiver desativado, o buffer será desativado e o corpo da solicitação será enviado ao processador de mensagens assim que for recebido. Se houver um erro, o roteador não vai tentar novamente a solicitação para outro processador de mensagens.