Referência da propriedade do host virtual

Especifica o nome do host virtual. Você usa esse nome para referenciar o host virtual ao configurar um proxy de API.

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

Especifica o número da porta usada 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 da porta especificado por <Port> precisa corresponder a ela.

Para o Cloud: especifique 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 use uma porta diferente de 443, não será possível mudar a porta.

Para versões da nuvem privada de 4.16.01 a 4.17.05:ao criar um host virtual, especifique a porta do roteador usada por ele. Por exemplo, porta 9001. Por padrão, o Router é executado como o usuário "apigee", que não tem acesso a portas privilegiadas, normalmente as portas 1024 e abaixo. Se você quiser criar um host virtual que vincule 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 do Private Cloud anteriores a 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 o término de 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 a um respondedor OCSP para determinar se o certificado TLS é válido. A resposta indica se o certificado TLS é válido e não foi revogado.

Quando ativado, o OCSP stapling permite que o Edge, atuando como o servidor TLS para TLS unidirecional, consulte diretamente o atendente de OCSP e armazene a resposta em cache. Em seguida, o Edge retorna essa resposta ao cliente TLS ou a fixa como parte do handshake de TLS. Consulte Ativar o OCSP Stapling no seu servidor para mais informações.

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

O nome DNS publicamente visível do host virtual no roteador, que pode incluir o número da porta. A combinação de nome do alias de host e número da porta para o 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.

Você precisa criar uma entrada DNS e um registro CNAME que correspondam ao alias de host, e o alias de 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 de host, também precisará especificar a mesma porta usando o elemento <Port>. Ou você pode especificar 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 de 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. Usar um caractere curinga em um alias de host virtual permite que proxies de API processem chamadas direcionadas a vários subdomínios, como alpha.example.com, beta.example.com ou live.example.com. Usar 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 caractere curinga conta como apenas um host virtual.

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

Para nuvem privada:se você estiver definindo o alias de host usando os endereços IP dos seus roteadores, e não entradas 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 que você quer que port seja vinculada. Se você omitir esse elemento, a porta será vinculada a todas as interfaces.

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

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

Execute o comando "ifconfig -a" para determinar as interfaces disponíveis no seu sistema.

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

É possível especificar vários 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 do cliente real. Se o roteador exigir o IP real 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, geralmente você 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 remover <ListenOption> depois, atualize o host virtual e omita a tag <ListenOptions> da atualização.

Ativa o 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 a Symantec ou a VeriSign. Não é possível usar um certificado autoassinado ou certificados folha assinados por uma CA autoassinada.

Para o Cloud: se o host virtual atual estiver configurado para usar uma porta diferente de 443, não será possível mudar a configuração do 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 usar uma referência para especificar o nome do keystore. Assim, você pode mudar o keystore 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 usar uma referência para especificar o nome do truststore. Assim, você pode mudar o truststore sem precisar reiniciar os roteadores. Consulte Opções para configurar o TLS para mais informações.

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

Essa opção é válida ao configurar o TLS para servidores 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.

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

Especifica as cifras 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 o Edge para nuvem privada versão 4.15.07 e anteriores.

Especifica os protocolos compatíveis com o 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 primeiro criar um keystore.

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

Consulte Definir um host virtual que usa o certificado e a chave de teste sem custo financeiro da Apigee.

Permite que o Edge capture informações de conexão TLS. 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 detalhes.

Permite a captura de detalhes do certificado do cliente capturados pelo Edge em 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 detalhes.

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 atinja o tempo limite antes que o processador de mensagens tenha tempo para retornar uma resposta. O tempo limite padrão de destino 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 que contém o cabeçalho Keep-Alive. O roteador mantém a conexão aberta até que a duração expire.

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

Define as cifras compatíveis com o host virtual, substituindo as cifras 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 informações 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 compatíveis com o 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 para os mesmos protocolos. Ou seja, os hosts virtuais que compartilham a mesma porta precisam ser compatíveis com os mesmos protocolos.

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

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

Ativa (on) ou desativa (off) 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 enviá-lo ao processador de mensagens. Se houver um erro, o roteador poderá tentar outro processador de mensagens.

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